dedlfix: strings in sonderzeichen?

Beitrag lesen

Hi!

Beim Client kommt dann nämlich nach wie vor "24 &#8486" an. Erste der Browser macht dann "Klartext" daraus, lässt also die HTML-Referenz im HTML-Kontext als "Ω" anzeigen.
In ISO 8859-1 gibt es auch kein Ohm-Zeichen, sodass es beim nächsten Request auch wieder [eine NCR werden] müsste.

Das ist nicht gesagt, denn es gibt keine Vorschrift, was bei mit der für das Senden zum Server verwendeten Kodierung nicht darstellbaren Zeichen passieren soll, die da ein Anwedender eingibt. Einige Browser machen NCRs draus, andere was anderes. Und diese NCRs sind weder zu unterscheiden von händisch eingegebenen NCRs noch werden die HTMLeigenen Zeichen als NCR oder Entity versendet. Man bekommt dann Mischmasch und weder reine Zeichen noch ordentliches HTML. Wenn man diesen Mischmasch wieder ausgeben will, bekommt man bei kontextgerechter Verwendung von htmlspecialchars() die NCRs angezeigt, weil sie nun als Ω an den Browser gehen. Oder man lässt die Maskierung und hat sich eine HTML-Injection-Lücke. Kurz: Das Verhalten der Browser ist kontraproduktiv - lieber UTF-8 durchgängig verwenden.

Wenn die Ressource allerdings in der Codierung UTF-8 ausgeliefert würde, der Client daher annehmen darf, dass auch der nächste Request in UTF-8 codiert gesendet werden darf, dann findet (in Eingabefeldern, wo auch sonst?) eine Ersetzung statt. Intern behandelt der Browser die Zeichen ohnehin in UTF-8-Codierung.

Wenn ich Browser wäre, würde ich lieber UTF-32/UCS-4 mit konstant 4 Byte pro Zeichen verwenden, da kann man besser zum Beispiel Positionen von Zeichen berechnen als bei UTF-8 mit der unterschiedlichen Anzahl an Bytes pro Zeichen. Aber egal - was der Browser intern macht, ist nicht weiter wichtig. Wichtig ist nur, dass er den kompletten Unicode-Zeichenvorrat verarbeiten kann.

Dass der Browser zum Kodieren des Formularrequests die Kodierung der Seite verwendet, in der das Formular steht, scheint von allen Browsern eingehalten zu werden [1]. Es gibt zwar das accept-charset-Attribut für das Formular, aber nicht alle noch relevanten Browser halten sich an einen dort angegebenen Wunsch. Zudem kann man da zwar mehrere Werte eintragen, der Browser sagt einem aber nicht, welchen er verwendet hat. Lieber weglassen, dann hat wenigstens die HTML-Spezifikation eine Darf-Aussage: The default value for this attribute is the reserved string "UNKNOWN". User agents may interpret this value as the character encoding that was used to transmit the document containing this FORM element.

Die Kodierung passiert jedenfalls nicht in den Eingabefeldern - als Browser-Benutzer sieht man davon nichts -, sondern irgendwo zwischen Auslösung des Formular-Submits und dem Absenden des Requests an den Server - ist aber auch nebensächlich.

[1] Aussage gemäß Sarrazin-Methode: Augenscheinliche Beobachtung und niemand hat es bisher widerlegt.

Lo!