Form GET UTF-8 und der IE
0 0 0 0 0 
dedlfix
0
Form GET UTF-8 und der IE
Bin gerade etwas verwundert. Für eine Anwendung nutzte ich zum Teil Formulare mit method="get". Darin befinden sich Eingabefelder wo auch alle Arten von Sonderzeichen drin vorkommen können.
Ich habe alles auf UTF-8 laufen und dem entsprechend auch ein
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
im Header.
In meiner Verarbeitung setze ich dann die Eingabefelder mit einem:
utf8_decode
Das funktioniert auch soweit ganz gut, hur halt nicht bei Formularen die ich aus dem IE mit GET abschicke.
POST funktioniert überall bestens (auch im IE), GET funktioniert auf allen Browsern bis auf den IE auch. Nur der IE schickt die Daten scheinbar nicht als UTF-8 weg wenn es GET ist.
Jemand ne Idee woran es liegen kann bzw. wie ich es einfach beheben kann?
-
Hi,
bei GET solltest du dann ja sehen wie der Browser das encoded in die URL schreibt.
Wie sieht die URL aus?
~dave
-
Wie sieht die URL aus?
Falsch:
/ajax/common/search_itm.php?sort=&sel_ser=&sel_id=&sel_des=St\xfcck&sel_act=&sel_rtyp=&sel_bud=001&form_name=req_pos&field_name=itm_new&callback_func=add_pos_mult_itmRichtig:
/ajax/common/search_itm.php?sort=&sel_ser=&sel_id=&sel_des=St%C3%BCck&sel_act=&sel_rtyp=&sel_bud=001&form_name=req_pos&field_name=itm_new&callback_func=add_pos_mult_itmUnd jetzt ist mir auch noch aufgefallen das es nicht IMMER der Fall ist, kann aber aktuell noch den Unterschied nicht finden. Bin sicher es ist was trivial blödes und ich bin aktuell hochgradig betriebsblind.
-
So, Zumindest einen Zusammenhang habe ich gefunden. JavaScript scheint der Übeltäter zu sein. Es läuft immer dann falsch wenn Das GET durch Javascript auf dem IE erfolgt.
-
Gefunden:
http://www.buildblog.de/2009/05/01/ajax-und-umlaute-das-ewig-wahrende-utf-8-problem-und-seine-losung/
-
Tach!
http://www.buildblog.de/2009/05/01/ajax-und-umlaute-das-ewig-wahrende-utf-8-problem-und-seine-losung/
Dieser Artikel ist mit Vorsicht zu genießen (wie so ziemlich vieles, was man so im Netz findet, Menschen machen nun mal Fehler).
Nur ein paar Anmerkungen:
"Wenn doch laut landläufiger Meinung UTF-8 die Lösung aller Zeichensatzprobleme ist, warum wird es dann nicht überall als Standard verwendet. Ganz nach dem Motto: Wenn ich nichts angebe meine ich UTF-8. Es könnte alles so einfach sein."
Nee, Kompatibilität zum bisherigen Vorgehen ist in der Regel höher bewertet als ein radikaler Paradigmenwechsel, selbst wenn dieser manche Probleme deutlich verringern würde.
"Während die Meta-Angabe des Zeichensatzes beim Firefox für eine richtige Interpretation von nicht Ascii Zeichen sorgt, passiert beim InternetExplorer gar nichts. Die Meta-Angabe hat für den IE keine Bedeutung. Entscheidend ist, was im Response-Header des Servers steht."
Die charset-Angabe im meta-Element hat nichts zu sagen, wenn eine solche Angabe im HTTP-Header auftaucht. So sagt es der Standard. Wenn der FF sich nicht daran halten tät, wäre das sein Fehler. Mir ist auch nicht bekannt, dass sich der FF hier falsch verhielte. Und einen Unterschied im Verhalten des IE9 kann ich auch nicht beobachten. (Für das Jahr 2009, aus dem der Artikel stammt, sollte es auch keine gravierenden Abweichungen gegeben haben.)
"In den Meisten Tutorials findet man dazu den Hinweis, dass die escape(String) Funktion zu verwenden sei. Das ist leider falsch. Der Grund dafür ist darin zu suchen, das escape(String) in Abhängigkeit vom Browser unterschiedliche Ergebnisse liefert. So war der InternetExplorer in meinen Tests beispielsweise nicht dazu zu bewegen, die übergebenen Parameter UTF-8 zu kodieren. Verwendet wurde, trotz der Angabe des Zeichensatzes in den Meta-Tags der Standardzeichensatz des Betriebssystems (Im Falle von Windows CPC1252). Das bedeutet, dass die Methode zum kodieren von Parametern, wofür sie eigentlich vorgesehen war, völlig ungeeignet ist."
Die Schlussfolgerung ist richtig, die Beobachtung ist aber falsch. Es ist nicht festgelegt, welche Zeichenkodierung escape() zu verwenden hat. Es ist nur definiert, dass die ersten 255 Zeichen (ohne Aussage, welche das seien) %xx-kodiert werden, alle anderen %uxxxx. Vermutlich bezieht man sich hier auf den Zeichensatz von HTML, der ja (zwar nicht immer aber schon lange) Unicode ist, beziehungsweise auf die CodePoints der Zeichen. escape() kann also gar keine UTF-8-Kodierung liefern. Stattdessen liefert es ein Gemisch aus ISO-8859-1 und einem Teil von UTF-16, beziehungsweise ein- und zweistelligen CodePoints. - Auch hier sehe ich keinen Unterschied zwischen den Browsern. Selbst das MSDN beschreibt escape() wie im Standard festgelegt und schreibt auch nichts zu Abweichungen im IE6 (falls der Autor diesen verwendet hat).
escape() liefert jedenfalls auch im FF nur dann URL-kodierte UTF-8-Sequenzen, wenn man als Dokumentkodierung ISO sagt, stattdessen aber UTF-8 verwendet - der Fehler also beim Dokumentersteller/Programmierer liegt.
Vermutlich hat der Autor nicht genau genug getestet oder beobachtet und so einige Lücken in der Matrix Test-Szenario vs. Browser.
"Abhilfe schafft hier die Methode encodeURIComponent(String). [...] Wir müssen den Content-Type also noch wie folgt ändern: application/x-www-form-urlencoded;charset=UTF-8"
Ja, encodeURIComponent() liefert eine URL-kodierung der UTF-8-Bytes von allen Zeichen (außer lateinischen Buchstaben, Ziffern und noch ein paar anderer Zeichen). So ist es definiert, und nur wo UTF-8 drauf steht, sollte man auch UTF-8 erwarten können. Dass man auch noch diese Content-Type-Angabe für Ajax-Requests angeben müsse, halte ich für nicht richtig, kann/will das jetzt aber nicht nachprüfen. encodeURIComponent() jedenfalls arbeitet garantiert nicht mal so und mal so in Abhängigkeit von irgendwelchen Ajax-Parametern.
dedlfix.
-
-
So, Zumindest einen Zusammenhang habe ich gefunden. JavaScript scheint der Übeltäter zu sein. Es läuft immer dann falsch wenn Das GET durch Javascript auf dem IE erfolgt.
Ohne den JavaScript-Code zusehen, kann dir aber keiner ohne die entsprechende Glaskugel weiterhelfen.
MfG
bubble
-
-
-