Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Query String Delimiter: & vs ; 5

Status
Not open for further replies.

Kirsle

Programmer
Jan 21, 2006
1,179
0
0
US
I wrote this blog entry about this here:
Below is the summary:

I started using ; as a delimiter for query strings instead of & for the following reasons:

* The W3C HTML validator doesn't like having a & by itself for HTML 4.01
* YaBB Forum uses a ; which is where I got the idea to begin with
* The Perl CGI module supports it just as well as with &
* Writing out "&" with each link in place of a simply "&" is ugly.

Code:
How the HTML Validator highlights the error:
<a href="/?p=blog[red]&i[/red]d=36">

I hadn't had any problem with it, but I recently discovered that Google messes it up. When linking to a page that used ; as a delimiter, the ; is URI encoded as %3B, which in turn confuses CGI.pm because it's looking for either a ; or an & to separate query string parameters, and therefore might think there's only one parameter with a very long value (the entire remainder of the query string)... etc.

My back-end HTML templates didn't properly write links out in the first place, instead writing them like

Code:
<a href="$link:blog;id=36">

and the Perl would dynamically rewrite that as a proper link before it's presented to the user (this way I could easily switch to a mod_rewrite approach or other page naming scheme in the future without having to modify all of my pages). So it was trivial to adjust it to use a full proper "&amp;" format for the links...

Code:
<a href="/?p=blog&amp;id=36">

And then for the existing broken Google links, I added a hack to check for the URI-escaped %3B in the query string, replace those with literal ;'s and send an HTTP 301 redirect to the proper location.

I'm curious as to how other web developers tackle this solution? Do you just write "&amp;" inside all the links, or do you use a Perl or PHP "front" like me that fixes your laziness before the browser gets it?

Cuvou.com | My personal homepage
Code:
perl -e '$|=$i=1;print" oo\n<|>\n_|_";x:sleep$|;print"\b",$i++%2?"/":"_";goto x;'
 
Writing out "&amp;" with each link in place of a simply "&" is ugly.

'Ugly' for who? Most people don't give the code behind a web page a second thought, so 99% of people will never see it anyway. Those that do view the source are probably going to be web developers anyway, and most I know would find it more odd if you didn't fix validation errors.

Certainly the browser isn't going to care... I can see IE and Fx talking over a pint now: "Oh look, another lazy web developer... I'd better break the rendering of this page"

I don't see why it's such an issue, given most, if not all, server-side languages offer some sort of HTML escaping routines.

Fair enough if you strive for validation and miss a few out, but to say you're not going to escape any because it's 'ugly' is just pure laziness.

Dan



Coedit Limited - Delivering standards compliant, accessible web solutions

Dan's Page [blue]@[/blue] Code Couch:
Code Couch Tech Snippets & Info:
 
'Ugly' for the person writing or maintaining the code. Writing a ton of escape sequences makes the code uglier to look at and maintain, sort of like when writing an HTML tutorial and needing to use &lt; and &gt; all the time.

Code:
&lt;table&gt;
&lt;tr&gt;
&lt;td colspan="2"&lt;
&lt;b&gt;&lt;u&gt;Table Title&lt;/u&gt;&lt;/b&gt;
&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Some Data&lt;/td&gt;&lt;td&gt;More Data&lt;/td&gt;
&lt;/tr&gt;
&lt;/table&gt;

Granted, it's not quite as extreme as this example since you only need to escape the &, but...

Code:
<embed src="[URL unfurl="true"]http://www.youtube.com/v/xkqT_0zF__8&amp;hl=en&amp;fs=1&amp;rel=0&amp;border=1"[/URL] width="500" height="405"></embed>

The escape sequences make it harder to read. When typing up the link the first time around it's easier to write it with the &amp; in one straight shot, but coming back later and maintaining it requires looking at it for a couple seconds to identify where the parameters are separated at and find out which parts of the text are part of an &*; escape sequence and which parts of the text are "literal." Whereas if a single & separates the parameters, it's easy to quickly distinguish that because it takes less time to tell letters apart from symbols like &... whereas &amp; is both letters and symbols but is treated as a single entity.

The youtube example brings up another point: it seems to be de facto that links have a single & to separate their arguments, and most things on the Internet along with youtube give you cut-and-paste code that is like this instead of using &amp;.

For me personally this isn't a big deal one way or the other, since my links are all dynamically translated before going to the browser so that I can swap the linking scheme (to use mod_rewrite for instance) without having to go back to all my pages, so I can write them how I want and know that it will be standards-compliant before it reaches the browser. I just was curious how people who write HTML the old-fashioned way handle these things (i.e. those who write HTML straight, for a static site, without using a content management system or content generator or any other such thing). Preferably I'd want some opinions from those who write HTML in a plain text editor, since some WYSIWYG editors might make the task of typing dynamic URLs more painless.

Cuvou.com | My personal homepage
Code:
perl -e '$|=$i=1;print" oo\n<|>\n_|_";x:sleep$|;print"\b",$i++%2?"/":"_";goto x;'
 
Preferably I'd want some opinions from those who write HTML in a plain text editor

I can't speak for any of the other posters, but I've been writing all my HTML in non-WYSIWYG text editors since I began web development over 10 years ago. I've not used Dreamweaver or Frontpage (or anything else of that ilk) once in that time.

Guess what? It's still not hard to do.

Sure - I've forgetfully typed in & and then spotted the typos when validating the pages... but I just would not omit making my pages validate because it's just not that difficult to do.

I don't understand why you think it is difficult, and probably never will, because IMHO, it really isn't.

Dan



Coedit Limited - Delivering standards compliant, accessible web solutions

Dan's Page [blue]@[/blue] Code Couch:
Code Couch Tech Snippets & Info:
 
I can't speak for any of the other posters, but I've been writing all my HTML in non-WYSIWYG text editors since I began web development over 10 years ago. I've not used Dreamweaver or Frontpage (or anything else of that ilk) once in that time

Same here, I still use Homesite 5 for all my work (aside from .NET, for which I use Visual Studio). I remember downloading Homesite 3.x around 1997/8 and have never looked back since.

Going back to the topic at hand...I've always used &amp; for ampersands (used &#38; for years because the old Netscape Navigator browsers only recognized the HEX versions for some special chars). Now it's just second nature...

I too forget some, but once I run the page through a validator, it requires a couple of fixes and then it's good to go.

TIP: trying googling the answer before posting, you'll find that more times than not someone else somewhere has had the same request and posted an answer online.
----
I have recently been semi-converted to ensuring all my code (well most of it) works in both javascript and non-javascript enabled browsers
 
Alright, thanks for the responses!

I've been out of the habit of using & for query strings since before I started caring that my pages were HTML 4.01 Strict (been using ;'s all along, until I discovered Google messes it up). So I set out to see how everyone else deals with them, and now I know!

:)

Cuvou.com | My personal homepage
Code:
perl -e '$|=$i=1;print" oo\n<|>\n_|_";x:sleep$|;print"\b",$i++%2?"/":"_";goto x;'
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top