Sven Rautenberg: _POST: MBCS

Beitrag lesen

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