ansaurus

Question

Answer 1

A:

Actually in my version of Firefox (3.5 on Linux), if I type "#%C3%BC" as a hash in the URL, the URL itself actually transforms to unicode with "#ü". But you have appeared to answered your own question -- in Firefox, the browser transforms entity escape codes in the URL, while in IE, it does not.

My advice is actually this: Instead of putting "#%C3%BC" in the URL at all, just use full unicode in your hashes and URLs. Is that an option? It should work fine in any modern browser.

Ken 2009-11-09 20:31:58

No, it's not :(. Your Firefox (and mine too) is just pretending to use an `ü` character. In HTTP it always uses the percent-encoding. Move your mouse over that link: http://test/%C3%BC. The Firefox status bar shows an `ü` for some reason. But if you use an HTTP sniffer, you will find out, that it's submitting `%C3%BC`.And basically, because I'm using that one in a HTTP redirect, I can not directly use unicode characters anyway.

Michael 2009-11-09 20:38:37

Are you sure that doesn't depend on the encoding being ASCII v a unicode encoding?

Ken 2009-11-09 20:56:30

AFAIK there is no way to transfer unicode characters in HTTP without special preparation like the percent-encoding (because HTTP does not allow characters outside the ASCII range).

Michael 2009-11-09 22:03:35

Answer 2

A:

You can use decodeURIComponent, it will return #ü in all cases:

decodeURIComponent('#%C3%BC'); // #ü
decodeURIComponent('#ü'); // #ü

Try it out here.

CMS 2009-11-09 20:37:59

Not a solution because:`decodeURIComponent('%2540'); // %40 (IE)`but`decodeURIComponent('%40'); // @ (FF)`

Michael 2009-11-09 20:52:06

Not really sure about what you mean, %2540 is the `%` character encoded (`%25`) and the non encoded `40` string, `decodeURIComponent('%40');` is @ in IE or Firefox... http://jsbin.com/esafe

CMS 2009-11-09 21:09:37

Let's assume I wanted to use the hash for a search function and someone wants to search for `%40` (but not for `@`). Depending on his browser, I will get `#%2540` (IE) or `#%40` (FF) as `location.hash`. If I decode it then, I get different results in the different browsers.

Michael 2009-11-09 22:00:31

Answer 3

+1 A:

Answering to my own question, my current solution is to parse window.location.href instead of using window.location.hash, because the former is always (i.e. in every browser) url-encoded. Therefore the decodeURIComponent function CMS proposed can always be used safely. YUI does the same, therefore it can't be that wrong...

Michael 2009-11-09 23:03:50

Answer 4

+4 A:

Unfortunately, this is a bug in Firefox as it decodes location.hash an extra time when it is accessed. For example, try this in Firefox:

location.hash = "#%30";
location.hash === "#0"; // This is wrong, it should be "#%30"

The only cross-browser solution is to just use (location.href.split("#")[1] || "") instead for getting the hash. Setting the hash using location.hash seems to work correctly for all browsers that support location.hash though.

Eli Grey 2009-11-10 00:15:05

Yep, that seems to be the most reasonable solution.

Michael 2009-11-10 06:28:28

ansaurus

tags:

views:

answers:

Encoding of window.location.hash

related questions