nicht angemeldet
_POST: MBCS
Moin,
kann mir bitte einer verraten, wie man MBCS bei den POST-Daten mitsenden kann?
( http://de.wikipedia.org/wiki/Multibyte_Character_Set )
Wäre sehr nett.
Danke und schönen Samstag noch.
-
Hello,
kann mir bitte einer verraten, wie man MBCS bei den POST-Daten mitsenden kann?
( http://de.wikipedia.org/wiki/Multibyte_Character_Set )gar nicht so einfach die Frage, wenn man sie auf GET erweitert.
Die einzige Stelle, in der ich die Information vermuten würde, wäre in einem HeaderACCEPT_CHARSET
Der Inhalt des Accept-Charset:-Headers der aktuellen Anforderung, so vorhanden. Z. B. 'iso-8859-1,*,utf-8'.
Wenn ich aber in einem PHP-Script schaue, wo der denn ankommt, kann ich nichts finden.
weder mit getallheaders() noch mit print_r($_SERVER) komme ich da auf die Lösung...Das hieße ja, dass man davon ausgeht, dass alle Clients alle Codierungen können?
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
-
Hi Tom,
dachte eigentlich vielmehr an solche Kürzel wie &%20; oder &#x...; etc. Gibt es da nicht was eigenes nur für MBCS?
Thx-
Hallo Alex,
dachte eigentlich vielmehr an solche Kürzel wie &%20; oder &#x...; etc. Gibt es da nicht was eigenes nur für MBCS?
Was verstehst du unter "was eigenes für MBCS" bzw. wo hast du Probleme?
Die Form &%20 ist mir nicht bekannt. Wahrscheinlich meinst du die Kodierung innerhalb von URLs (und dem Request-Body von HTTP-POST-Request, falls dieser als application/x-www-form-urlencoded formatiert): Diese bestehen aus dem Prozentzeichen gefolgt von dem Wert des Byte-Wert des Zeichens in der vom Client verwendeten Kodierung in hexadezimaler Schreibweise. D.h. ö wird beispielsweise unter ISO-8859-1 zu %F6.
Wird ein Multibyte-Zeichensatz verwendet, so werden Multibyte-Zeichen mit mehreren Escape-Sequenzen, für jedes Byte des Zeichens eine, maskiert: ö wird bei der Verwendung von UTF-8 beispielsweise zu %C3%B6.
Wird die Antwort hingegen als multipart/form-data gesendet, so ist es nicht nötig, nicht alpha-numerische Zeichen derartig zu maskieren.
Da der Browser diese Maskierung automatisch erledigt, und ein vernünftiges Interface zur serverseitigen Verarbeitung von Formulardaten diese in der demaskierten Form zu Verfügung stellt, wenn alles so funktioniert, wie es sollte, solltest du davon normalerweise also gar nichts mitkriegen.
Ein Problem gibt es aber, wenn der Besucher Zeichen eingegeben hat, die im verwendeten Zeichensatz nicht vorhanden sind. Viele Browser kodieren diese Angaben dann als SGML-Zeichenreferenzen, wobei dies dann aber auch vom verarbeitenden Programm auf dem Server erkannt werden muss. Dabei ist es egal, welcher Zeichensatz verwendet wird, da bei numerischen SGML-Zeicheneferenzen immer die Position im Universal Character Set (Unicode) angegeben wird.
Wird beispielsweise der Zeichensatz ISO-8859-1 verwendet und der Besucher hat bei der Frage nach seinem Namen aber Πυθαγόρας eingegeben, so sendet der Browser dann die Zeichenfolge Πυθαγόρας an den Server.
Kennt der Server aber auch nur ISO-8859-1 und will die Daten wieder ausgeben, passiert's: Der Server maskiert die Daten vor der Ausgabe (& wird durch & ersetzt, < durch < ...). D.h. der Server wandelt die Zeichenfolge Πυθαγόρας in &#928;&#965;&#952;&#945;&#947;&#972;&#961;&#945;&#962; um.
Dadurch bekommt der Besucher nun nicht das, was er eingegeben hat, nämlich Πυθαγόρας, zu sehen, sondern Πυθαγόρας
Damit das nicht passiert, muss der Server bzw. das Programm, das die Formulardaten verarbeitet SGML-Zeichenreferenzen erkennen und darauf acht geben, dass das Ampersand & in solchen Kombinationen nicht als & maskiert wird.
Diese Probleme lassen sich aber sehr leicht dadurch umgehen, dass alle Seiten (bzw. vor allem die Seite, die das Formular enthält) als UTF-8 ausgeliefert werden. Soweit mir bekannt, senden eigentlich alle Browser dann auch die Antwort als UTF-8, womit die Notwendigkeit zur Maskierung von nicht im Zeichensatz enthaltenen Zeichen wegfällt, da alle Zeichen, die in HTML darstellbar sind, auch in UTF-8 darstellbar sind.
Schöne Grüße,
Johannes
-
Moin!
Ein Problem gibt es aber, wenn der Besucher Zeichen eingegeben hat, die im verwendeten Zeichensatz nicht vorhanden sind.
Dieser Fall und die daraus durch real existierende Browser folgenden Konsequenzen sind so dramatisch, dass dieser Fall unter ALLEN UMSTÄNDEN zu vermeiden ist. In der Regel führt es dazu, dass die Daten nicht wiederherstellbar zerstört werden!
Viele Browser kodieren diese Angaben dann als SGML-Zeichenreferenzen, wobei dies dann aber auch vom verarbeitenden Programm auf dem Server erkannt werden muss. Dabei ist es egal, welcher Zeichensatz verwendet wird, da bei numerischen SGML-Zeicheneferenzen immer die Position im Universal Character Set (Unicode) angegeben wird.
Nein, "viele" Browser würde ich nicht sagen.
Die allgemeine Konsequenz bei der Nutzung einer zu den zu sendenden Zeichen inkompatiblen Codierung ist, dass die Zeichen unwiederherstellbar zerstört werden. Das tun ALLE Browser. Je nach Modell in unterschiedlicher Weise. Manche zerstören die Zeichen durch NCRs, manche durch Fragezeichen. Manche durch Wechsel der Zeichencodierung, ohne das irgendwie mitzuteilen.
Wird beispielsweise der Zeichensatz ISO-8859-1 verwendet und der Besucher hat bei der Frage nach seinem Namen aber Πυθαγόρας eingegeben, so sendet der Browser dann die Zeichenfolge Πυθαγόρας an den Server.
Oder ??????????.
Damit das nicht passiert, muss der Server bzw. das Programm, das die Formulardaten verarbeitet SGML-Zeichenreferenzen erkennen und darauf acht geben, dass das Ampersand & in solchen Kombinationen nicht als & maskiert wird.
Es ist unmöglich, das zu erkennen. Mein typisches Beispiel dafür ist folgender Text:
"Π wird codiert als Π."
Das griechische Pi wird in eine NCR umgewandelt, am Server kommt an:
"Π wird codiert als Π."
Das kann man nicht mehr in die ursprünglich gemeinte Form zurückcodieren, weil der Browser das originale &-Zeichen ja nicht zu & umformt.
Egal wie man es dreht: Die ursprünglich eingegebenen Zeichen sind nicht wiederherstellbar.
Diese Probleme lassen sich aber sehr leicht dadurch umgehen, dass alle Seiten (bzw. vor allem die Seite, die das Formular enthält) als UTF-8 ausgeliefert werden. Soweit mir bekannt, senden eigentlich alle Browser dann auch die Antwort als UTF-8, womit die Notwendigkeit zur Maskierung von nicht im Zeichensatz enthaltenen Zeichen wegfällt, da alle Zeichen, die in HTML darstellbar sind, auch in UTF-8 darstellbar sind.
Das ist die zwingende Konsequenz - die angesichts der schon mehrere Jahre andauernden Unterstützung für Unicode in allen beteiligten Komponenten auch ziemlich problemlos umsetzbar ist.
- Sven Rautenberg
--
"Love your nation - respect the others."
-
-
-
Hallo Tom,
Wenn ich aber in einem PHP-Script schaue, wo der denn ankommt, kann ich nichts finden.
weder mit getallheaders() noch mit print_r($_SERVER) komme ich da auf die Lösung...kann ich nicht nachvollziehen, $_SERVER['HTTP_ACCEPT_CHARSET'] existiert, ebenso wie der Schlüssel Accept-Charset im vom apache_request_headers() zurückgegebenem Array.
Das hieße ja, dass man davon ausgeht, dass alle Clients alle Codierungen können?
Genau, wenn kein Accept-Charset-Header gesendet wird, gelte alle Kodierungen als Akzeptabel:
"If no Accept-Charset header is present, the default is that any character set is acceptable." (RFC 2616)
Schöne Grüße,
Johannes
-
Hello,
kann ich nicht nachvollziehen, $_SERVER['HTTP_ACCEPT_CHARSET'] existiert, ebenso wie der Schlüssel Accept-Charset im vom apache_request_headers() zurückgegebenem Array.
Das hieße ja, dass man davon ausgeht, dass alle Clients alle Codierungen können?
Genau, wenn kein Accept-Charset-Header gesendet wird, gelte alle Kodierungen als Akzeptabel:
"If no Accept-Charset header is present, the default is that any character set is acceptable." (RFC 2616)
Welche Browser hast Due denn benutzt dafür?
Weder Firefox noch IE 6.0 SP1 haben die Angaben gesendent.
Ich habe eben nochmal den guten alten Netscape 7.1 getestet:
[Host] => testserver
[User-Agent] => Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
[Accept] => text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
[Accept-Language] => en-us,en;q=0.5
[Accept-Encoding] => gzip,deflate
[Accept-Charset] => ISO-8859-1,utf-8;q=0.7,*;q=0.7 <-----
[Keep-Alive] => 300
[Connection] => keep-aliveund
[HTTP_ACCEPT_CHARSET] => ISO-8859-1,utf-8;q=0.7,*;q=0.7
siehe da: der sendet die Infos.
Mehr Browser habe ich zur Zeit nicht verfügbar.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
-
Hallo Tom,
Welche Browser hast Due denn benutzt dafür?
Opera.
Schöne Grüße,
Johannes
-
-
-
-
Moin!
kann mir bitte einer verraten, wie man MBCS bei den POST-Daten mitsenden kann?
( http://de.wikipedia.org/wiki/Multibyte_Character_Set )Wenn der Empfänger-Server nicht darauf eingerichtet ist, hast du keine Chance.
Ansonsten verwendest du einfach das Kodierungsschema, welches erwartet wird.
Anzumerken wäre: Opera sendet tatsächlich die verwendete Codierung im Request mit, alle anderen Browser tun das leider nicht. Aber da die einzige universelle Codierungsform UTF-8, auf die man sich sowieso ausschließlich konzentrieren sollte, keine besonderen Probleme bereitet, wenn man sie am Server erwartet, sollte das nur ein unwichtiges Randdetail sein.
Die ausufernde Diskussion über ACCEPT_CHARSET zielt übrigens in die falsche Datenrichtung.
- Sven Rautenberg
--
"Love your nation - respect the others."