Beat: Zeichenkodierung nach Absenden eines Forms feststellen

Beitrag lesen

Wieso sollte ein Benutzer diese Einstellung ändern?

OK!

Ein manueller Override der vom Browser festgestellten Zeichenkodierung wird in 99% der Fälle Unsinn erzeugen.

Genauer spezifizieren. Ein vom User eingestelltes Charset kann wohl Unsinn im readonly-Context erzeugen, beeinflusst dennoch aber die Interpretation dessen, was der User in Formularen eingibt. Ein Server, der auf diesen Mutwillen nicht vorbereitet ist und annimmt, dass solche Daten unter dem gleichen Charset stehen wie die an den browser gesendeten. kann in der Folge Unsinn produzieren. Im Besten Falle wird er durch numerischen Entities überhäuft.

Es gibt durchaus problematische Anwendungen.
z.B. Maillist-Server -> Web-Frontend
Also Anwendungen, die letzlich Quellen, die unter verschiedensten Charsets abgesendet wurden, unter ein einziges Charset stellen müssen.

Natürlich gibt es den Fall, dass der Benutzer manuell die Zeichenkodierung umstellen kann (z.B. vom automatisch erkannten UTF-8 auf das "falsche" ISO-8859-1). Dann werden die Formulardaten je nach Browser gegebenenfalls als Latin-1 gesendet. Aber wieso sollte man das tun? Dann sind doch alle Nicht-ASCII-Zeichen auf der Seite kaputt und die Texte unlesbar. Für solche mutwillige Sabotage lohnt es sich doch nicht, eine Ausnahmebehandlung zu schreiben.

Ich finde "mutwillige Sabotage" einer Nachfrage würdig.
Jeder Software-Autor sollte sich die Frage stellen:
basiert meine Sicherheit auf der Annahme eines Charsets?
Bei HTML gibt's noch die zusätzliche Frage: Können Entities meine Sicherheitsvorkehrungen umgehen?

Wenn ein Encoding zu was auch immer im falschen Kontext vorgenommen wird, kann die Antwort JA lauten.

mfg Beat

--
><o(((°>           ><o(((°>
   <°)))o><                     ><o(((°>o
Der Valigator leibt diese Fische