nicht angemeldet
Sonderzeichen werden verstümmelt
Hallo Forum,
aus irgendeinem Grunde werden Sonderzeichen bei der Übergabe per Javascript an ein PHP-Script verstümmelt. So wird z.B. das "ö" zu "ö"
(U+00C3 und U+00B6).
Kann mir jemand sagen, wie das kommt? Habe vor der Übergabe des Strings per JS decodeURI(ö) gemacht und hinterher wieder encodeURI(ö). Trotzdem kommt das ö nicht korrekt an.
Für Tipps wäre ich wirklich sehr dankbar, weil ich schon seit 3 Tagen den Fehler suche.
Mit freundlichen Grüßen
Rossini
-
Hallo,
aus irgendeinem Grunde werden Sonderzeichen bei der Übergabe per Javascript an ein PHP-Script verstümmelt. So wird z.B. das "ö" zu "ö"
(U+00C3 und U+00B6).ö ist ein UTF-8-kodiertes ö, wenn es fälschlicherweise als ISO-8859-1 dekodiert wird.
Die Zeichen werden also nicht verstümmelt, sondern wahrscheinlich einfach nur mit UTF-8 kodiert - dein Script arbeitet aber wahrscheinlich mit ISO-8859-1.
Kann mir jemand sagen, wie das kommt? Habe vor der Übergabe des Strings per JS decodeURI(ö) gemacht und hinterher wieder encodeURI(ö). Trotzdem kommt das ö nicht korrekt an.
encodeURI und decodeURI nehmen eine UTF-8-Kodierung vor. encodeURI("ö") ergibt also "%C3%B6". Wenn du das an ein PHP-Script sendest, bekommst du einen UTF-8-kodierten String. Es gibt unterschiedliche Lösungen: Entweder du stellst auch dein Script auf UTF-8 um oder du nimmst serverseitig wieder eine Rekodierung nach ISO-8859-1 vor (utf8_decode). Was sinnvoller ist, lässt sich im Einzelfall entscheiden. (Was ich nicht machen würde, ist mit escape() zu arbeiten, um eine ISO-8859-1-Kodierung zu erzwingen.)
Mathias
-
hallo Mathias,
Was ich nicht machen würde, ist mit escape() zu arbeiten, um eine ISO-8859-1-Kodierung zu erzwingen.
Deine schöne Erklärung könnte noch an Wert gewinnen, wenn du das begründest.
Grüße aus Berlin
Christoph S.
-
Hallo,
Was ich nicht machen würde, ist mit escape() zu arbeiten, um eine ISO-8859-1-Kodierung zu erzwingen.
Deine schöne Erklärung könnte noch an Wert gewinnen, wenn du das begründest.
Stimmt. Isch hab da schomma was vorbereitet:
http://forum.de.selfhtml.org/archiv/2007/2/t145916/#m946923Mathias
-
hi,
Isch hab da schomma was vorbereitet:
http://forum.de.selfhtml.org/archiv/2007/2/t145916/#m946923Ahja. Aber gut, daß wir darüber gesprochen haben ;-)
Grüße aus Berlin
Christoph S.
-
-
-
Hallo Mathias,
vielen, vielen Dank für deine schnelle und vor allem kompetente Hilfe!! utf8-decode war die Lösung. Jetzt klappt es einwandfrei.
Auf escape() war ich bei meinen recherchen auch gestoßen, habe das aber verworfen, weil selfhtml dazu sagt, das es über kurz oder lang durch de/encodeURI() ersetzt würde.
Vielen Dank nochmal für Deine Hilfe!
Gruß
Rossini -
Hallo molily.
(Was ich nicht machen würde, ist mit escape() zu arbeiten, um eine ISO-8859-1-Kodierung zu erzwingen.)
Ach, das ist der Grund warum diese Funktion angeblich „[…] in Zukunft durch encodeURI() ersetzt […]“ werden soll? Was es mit dieser Anmerkung auf sich hat, habe ich mich schon immer gefragt.
Einen schönen Freitag noch.
Gruß, Mathias
--
ie:% fl:| br:< va:) ls:& fo:) rl:( n4:~ ss:) de:] js:| mo:| zu:)
debian/rules-
Hallo,
Ach, das ist der Grund warum diese Funktion angeblich „[…] in Zukunft durch encodeURI() ersetzt […]“ werden soll? Was es mit dieser Anmerkung auf sich hat, habe ich mich schon immer gefragt.
Ja, das ist ziemlich schwammig ausgedrückt, ich habs mal in den Bugtracker eingetragen.
escape() ist ein Relikt aus Netscape Client Side JavaScript 1.3 vor der Anpassung an ECMAScript, escape() ist halt durch die Beschränkung auf Latin 1 nicht Unicode-kompatibel. encodeURI() ist wiederum offiziell ECMAScript-standardisiert. Im Netscape Core JavaScript 1.5 gibts kein escape() mehr, also stimmt es schon, dass encodeURI() von der Funktionalität her an die Stelle von escape() tritt.
Mathias
-
-