A Complexity In URL Encoding

perm url with updates: http://xahlee.org/js/url_encoding.html

A Complexity In URL Encoding

Xah Lee, 2009-06-02, 2010-02-01

[2010-02-03 addendum: this article is incorrect. Actually, it is simple to check if the url is a cgi script, by looking for “?”. If so, any “&” before the “?” should be “%26”, and after should be “&”]

Discovered a subtle issue with automating url encoding. In url, if you have the ampersand “&” char, and if this url is to be inside a html doc as a link, then, there's no automated procedure that determines correctly whether the char should be encoded as “%26” or “&”.

If the char is used as part of the file name or path, then it should be encoded as “%26”, but if it is used as a separator for CGI parameters, then it should be encoded as “&”.

The ampersand char is a reserved char in Percent encoding. Therefore it must be percent encoded if it is used for normal file path names. So, when it is NOT used as part of path names, but used as CGI parameter separaters, with GET method of HTTP request, then it must be left as it is. Now, in html, the ampersand char must be encoded as html entities “&” when adjacent chars are not space (basically). So, it becomes “&”.

Of course i knew the above, but my realization is that, the purpose of the char used in url cannot be syntactically determined with 100% accuracy.

This is interesting to me because i work in html and using emacs, and i have written personal elisp code that automatically turns a url into a link. The situation is that, this lisp code cannot do that with 100% accuracy in theory.

Of course, in practice, all this matters shit. Just use “&” plainly and it all works all browsers.

Popular posts from this blog

11 Years of Writing About Emacs

does md5 creates more randomness?

Google Code shutting down, future of ErgoEmacs