Encoding of [removed].hash

2020-02-07 16:53发布

问题:

Does window.location.hash contain the encoded or decoded representation of the url part?

When I open the same url (http://localhost/something/#%C3%BC where %C3%BCtranslates to ü) in Firefox 3.5 and Internet Explorer 8, I get different values for document.location.hash:

  • IE8: #%C3%BC
  • FF3.5:

Is there a way to get one variant in both browsers?

回答1:

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.



回答2:

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...



回答3:

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

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

Try it out here.



回答4:

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.