Encoding of [removed].hash

前端 未结 4 1842
死守一世寂寞
死守一世寂寞 2020-12-13 02:22

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

When I open the same url (http://localhost/something/#%C3

相关标签:
4条回答
  • 2020-12-13 02:23

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

    0 讨论(0)
  • 2020-12-13 02:24

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

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

    Try it out here.

    0 讨论(0)
  • 2020-12-13 02:27

    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.

    0 讨论(0)
  • 2020-12-13 02:48

    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.

    0 讨论(0)
提交回复
热议问题