Zeichenkodierung nach Absenden eines Forms feststellen
0 1 0 0 
dedlfix
0 
Auge
0 accept-charset
0 0 dedlfix
Zeichenkodierung nach Absenden eines Forms feststellen
Fröhliche Weihnacht!
s. Thema. Besucher Hugo hat die Möglichkeit, am Browser eine Zeichenkodierung einzustellen. Falls das Hugo macht, bevor er ein Formular submittet, Frage: wie kann ich serverseitig feststellen, was Hugo eingestellt hat?
Bitte mal um Hinweise,
Horst Haselhuhn
-
Hi,
Besucher Hugo hat die Möglichkeit, am Browser eine Zeichenkodierung einzustellen. Falls das Hugo macht, bevor er ein Formular submittet, Frage: wie kann ich serverseitig feststellen, was Hugo eingestellt hat?
Wenn der Browser keine entsprechende Angabe liefert, dann gar nicht.
Dann kannst du höchstens zu raten versuchen.
Ein verstecktes Inputfeld mit einer Reihe von "Sonderzeichen", deren Darstellung in verschiedenen Zeichenkodierungen bekannt ist, kann dabei ggf. unterstützen.MfG ChrisB
--
“Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam]-
hi Chris,
Ein verstecktes Inputfeld mit einer Reihe von "Sonderzeichen", deren Darstellung in verschiedenen Zeichenkodierungen bekannt ist, kann dabei ggf. unterstützen.
Gute Idee, danke!!!
(Ein) Referenzzeichen sozusagen. Mal gucken, was sich da so machen lässt...
Viele Grüße,
Horst Steuernagl
-
-
Hallo,
s. Thema. Besucher Hugo hat die Möglichkeit, am Browser eine Zeichenkodierung einzustellen. Falls das Hugo macht, bevor er ein Formular submittet, Frage: wie kann ich serverseitig feststellen, was Hugo eingestellt hat?
naja:
<?php $string = "äää"; var_dump($string === utf8_encode(utf8_decode($string))); $string2 = "äää"; var_dump($string2 === utf8_encode(utf8_decode($string2)));wenn du den string utf8-decodierst und dann wieder encodierst und das selbe bei rauskommt war er utf8-kodiert?
Gruß
jobo
-
hi,
wenn du den string utf8-decodierst und dann wieder encodierst und das selbe bei rauskommt war er utf8-kodiert?
Das ist ne gute Testmethode. So ähnlich prüfe ich Eingaben von IP-Adressen, Datums und Uhrzeiten. Also, diese Hugos, die geben ja meistens nur M?ll ein ;-)
Viele Grüße,
Horst Gammelfleisch--
1,2,3, Weihnachtn ist vorbei!
-
-
s. Thema. Besucher Hugo hat die Möglichkeit, am Browser eine Zeichenkodierung einzustellen.
Wieso sollte ein Benutzer diese Einstellung ändern? Ein manueller Override der vom Browser festgestellten Zeichenkodierung wird in 99% der Fälle Unsinn erzeugen.
Falls das Hugo macht, bevor er ein Formular submittet, Frage: wie kann ich serverseitig feststellen, was Hugo eingestellt hat?
Die Kodierung eines Strings herauszubekommen ist nicht zuverlässig möglich. Wenn ich da Unsinn einstelle, wirst du selbst mit einem Prüfzeichen nicht zuverlässig in Erfahrung bringen können, welche Kodierung es ist.
Heutzutage stellt sich das Problem nicht mehr. Wenn du die Zeichenkodierung des Dokuments richtig angibst (HTTP-Header, meta-Angabe) und das Formular zudem mit einer accept-charset-Angabe versiehst, dann kannst du dir sicher sein, dass diese Kodierung für die Formulardaten verwendet wird.
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.
-
Hi!
Heutzutage stellt sich das Problem nicht mehr. Wenn du die Zeichenkodierung des Dokuments richtig angibst (HTTP-Header, meta-Angabe) und das Formular zudem mit einer accept-charset-Angabe versiehst, dann kannst du dir sicher sein, dass diese Kodierung für die Formulardaten verwendet wird.
Die accept-charset-Angabe kann man getrost vergessen. Sie funktioniert in keinem der wichtigen Browser in allen Fällen korrekt (probier mal was "exotisches" wie UTF-16). Doch selbst wenn man sich auf ISO-8859-1 und UTF-8 beschränkt, kann man sich auf diese Angabe nicht verlassen, denn der IE selbst in der 8er Version scheint sie komplett zu ignorieren.
Lo!
-
Hallo
Heutzutage stellt sich das Problem nicht mehr. Wenn du die Zeichenkodierung des Dokuments richtig angibst (HTTP-Header, meta-Angabe) und das Formular zudem mit einer accept-charset-Angabe versiehst, dann kannst du dir sicher sein, dass diese Kodierung für die Formulardaten verwendet wird.
Die accept-charset-Angabe kann man getrost vergessen. Sie funktioniert in keinem der wichtigen Browser in allen Fällen korrekt (probier mal was "exotisches" wie UTF-16). Doch selbst wenn man sich auf ISO-8859-1 und UTF-8 beschränkt, kann man sich auf diese Angabe nicht verlassen, denn der IE selbst in der 8er Version scheint sie komplett zu ignorieren.
Wo wir grad' bei dem Thema sind. Das Ignorieren ignorierend stellt sich mir die Frage, ob die Angabe von accept-charset für Formulare in irgendwelchen[1] Browsern irgendwelche "schädlichen" Nebenwirkungen haben kann.
[1] absichtlich normal geschrieben
Tschö, Auge
--
Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
Terry Pratchett, "Wachen! Wachen!"
Veranstaltungsdatenbank Vdb 0.3 -
Die accept-charset-Angabe kann man getrost vergessen. Sie funktioniert in keinem der wichtigen Browser in allen Fällen korrekt (probier mal was "exotisches" wie UTF-16). Doch selbst wenn man sich auf ISO-8859-1 und UTF-8 beschränkt, kann man sich auf diese Angabe nicht verlassen, denn der IE selbst in der 8er Version scheint sie komplett zu ignorieren.
Die Angabe ist durchaus sinnvoll, wenn man z.B. fremde Sites ansteuert, die Formulardaten in einer anderen Kodierung als die des aktuellen Dokuments erwarten. Browser wie Firefox, Chrome, Safari und Opera beachten sie. Dabei ist zwar nicht UTF-16 nutzbar (tatsächlich exotisch bei Webformularen), aber z.B. die gebräuchlichen Kodierungen der ISO-8859-Familie. Darüber hinaus habe ich Shift_JIS positiv getestet.
IE ignoriert accept-charset tatsächlich und wählt eine auf die Formulardaten passende Kodierung. Das ist die Kodierung des Dokuments und alternativ UTF-8, wenn die Zeichen im Formular mit jener Kodierung nicht ausgedrückt werden können. Ein UTF-8-Formular in einem Nicht-UTF-8-Dokument lässt sich daher einfach mit einem versteckten Nicht-Latin1-Zeichen erzwingen.
-
Die Angabe ist durchaus sinnvoll, wenn man z.B. fremde Sites ansteuert, die Formulardaten in einer anderen Kodierung als die des aktuellen Dokuments erwarten.
Mit Verlaub, es wäre geschickter solche Formulare in einem eigenen iframe mit ihrem eigenen HTTP Header oder Meta charset auszugeben.
Schliesslich lässt sich in einem iframe auch gleich die als Formular vorliegende API des Anbieters einbinden.
Habe ich etwas von API gesagt? Macht doch irgendwie Sinn.
Never forget to document the required Charset in your API.mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische
-
-
-
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-
Hi!
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.
Wie soll eine Anwendung unterscheiden, ob eine Zeichenfolge beabsichtigt oder fälschlicherweise ein NCR ergibt? Und wie soll allgemein ein Server auf ungewollte Eingaben reagieren? Er kann nicht wissen oder mit absoluter Sicherheit ermitteln, ob das was er da bekommt im Sinne des Betreibers ist oder nicht. Es ist übrigens die gleiche Problematik wie mit Spam. Man kann es nicht in allen Fällen automatisiert von Nutztext unterscheiden.
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.Alles was nicht ordentlich deklariert ist, führt zwangsläufig ins Chaos. Man kann vielleicht ein paar wenige bekannte Fehler korrigieren, aber nicht alles. Damit muss man leben können.
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.Ich wüsste grad nicht, was für Sicherheitslücken sich durch ergeben sollen. Schlimmstenfalls gibt es bei Mehrbytekodierungen ungültige Bytesequenzen, die in ein Ersatzzeichen ausgetauscht werden. Wenn man davon ausgeht, dass bei Einfügen in andere Kontexte die beabsichtigte Kodierung mit dem Ziel ausgehandelt wird und die Zeichen gemäß dieses Kontextes und der Kodierung behandelt werden, ergibt es zwar immer noch keinen unsinnigen Inhalt, aber derist wenigstens den umständen entsprechend korrekt maskiert.
Lo!
-
-