Michael
Tut window.location.hash die codierte oder decodierte Darstellung des URL-Teils enthalten?
Wenn ich dieselbe URL öffne (http://localhost/something/#%C3%BC wo %C3%BCwird übersetzt in ü) in Firefox 3.5 und Internet Explorer 8 erhalte ich unterschiedliche Werte für document.location.hash:
#%C3%BC#üGibt es eine Möglichkeit, eine Variante in beiden Browsern zu erhalten?
Leider ist dies ein Fehler in Firefox, da er dekodiert location.hash ein zusätzliches Mal, wenn darauf zugegriffen wird. Probieren Sie zum Beispiel Folgendes in Firefox aus:
location.hash = "#%30";
location.hash === "#0"; // This is wrong, it should be "#%30"
Die einzige Cross-Browser-Lösung ist einfach zu verwenden (location.href.split("#")[1] || "") stattdessen um den Hash zu bekommen. Setzen des Hashs mit location.hash scheint für alle Browser, die dies unterstützen, korrekt zu funktionieren location.hash obwohl.
Ja, das scheint die vernünftigste Lösung zu sein.
– Michael
10. November 2009 um 6:28 Uhr
Dieser Test kehrt zurück false unter Firefox 10.0.1 mindestens. Ich bin mir nicht sicher, wann es geändert wurde, aber wenn Sie ältere Versionen unterstützen möchten, ist dies natürlich immer noch der beste Rat.
– Hippiepfad
14. März 2012 um 18:43 Uhr
Was ist, wenn der Hash-Teil selbst ein # enthält? In diesem Fall funktioniert die Split-Methode nicht.
– Christoph
29. August 2012 um 2:39 Uhr
danke für deine lösung! Denken Sie nur daran, dass die Ausgabe von location.hash ein führendes “#” hat, aber location.href.split nicht.
– Tapper
2. Januar 2013 um 9:34 Uhr
@Christophe: Ein mögliches ‘#’ im Hash selbst sollte als ‘%23’ codiert werden. Um ganz sicher zu sein, können Sie natürlich verwenden location.href.split('#').splice(1).join('#'). In diesem Fall muss nicht einmal hinzugefügt werden || "" weil das Ergebnis ein leerer String ist, wenn überhaupt kein Hash vorhanden ist.
– Pekka Klärck
13. Februar 2014 um 15:54 Uhr
Als Antwort auf meine eigene Frage besteht meine aktuelle Lösung darin, zu analysieren window.location.href statt zu verwenden window.location.hash, weil ersteres immer (also in jedem Browser) URL-kodiert ist. Deshalb, die decodeURIComponent Funktion CMS vorgeschlagen, können immer sicher verwendet werden. YUI macht das gleiche, also kann es nicht so falsch sein …
Christian C. Salvado
Sie können verwenden decodeURIComponentes wird zurückkehren #ü auf alle Fälle:
decodeURIComponent('#%C3%BC'); // #ü
decodeURIComponent('#ü'); // #ü
Versuch es hier.
Keine Lösung, weil: decodeURIComponent('%2540'); // %40 (IE) aber decodeURIComponent('%40'); // @ (FF)
– Michael
9. November 2009 um 20:52 Uhr
Nicht wirklich sicher, was Sie meinen, %2540 ist die % zeichenkodiert (%25) und die nicht codierten 40 Schnur, decodeURIComponent('%40'); ist @ in IE oder Firefox… jsbin.com/esafe
– Christian C. Salvado
9. November 2009 um 21:09 Uhr
Nehmen wir an, ich wollte den Hash für eine Suchfunktion verwenden und jemand möchte danach suchen %40 (aber nicht für @). Je nach Browser bekomme ich #%2540 (IE) bzw #%40 (FF) wie location.hash. Wenn ich es dann entschlüssele, erhalte ich in den verschiedenen Browsern unterschiedliche Ergebnisse.
– Michael
9. November 2009 um 22:00 Uhr
Tatsächlich in meiner Version von Firefox (3.5 unter Linux), wenn ich “#%C3%BC” als Hash in die URL eingebe, tatsächlich die URL selbst transformiert in Unicode mit “#ü”. Aber Sie haben anscheinend Ihre eigene Frage beantwortet – in Firefox wandelt der Browser Entitäts-Escape-Codes in der URL um, während dies in IE nicht der Fall ist.
Mein Rat ist eigentlich folgender: Anstatt überhaupt “#%C3%BC” in die URL einzufügen, verwenden Sie einfach vollständigen Unicode in Ihren Hashes und URLs. Ist das eine Option? Es sollte in jedem modernen Browser funktionieren.
