Browser-Kodierung erkennen und Formular-Werte wandeln

[andik2000]

Hallo Gemeinde,

ich habe das Problem, dass die Umlaute in Formulare von einer Website gelegentlich zerschossen sind.
Jetzt habe ich verschiedenen Tests gemacht und bin zu dem Schluss gekommen, dass es sehr wahrscheinlich an der Browser-Kodierung des Users liegt.

Die Website ist noch in ISO 8859-1 angelegt (und zu umfangreich das mal schnell auf UTF8 umzustellen).
Nun vermute ich, dass wenn ein User keine automatische Erkennung der Textkodierung im Brower aktiviert hat und diese fest auf UTF-8 steht, dass dann eben die Umlaute falsch übertragen werden.
Wenn ich immer mit utf8_decode() die Werte ändere, sind die aber auch teils falsch.

Meine Frage nun: Kann ich irgendwie abfragen, in welcher Kodierung Werte übergeben wurden und dann nur utf8-decode, wenn die Seite auch als UTF-8 aufgerufen wurde?

Grüße,
Andi

[h3ll]

Hallo Gemeinde,

ich habe das Problem, dass die Umlaute in Formulare von einer Website gelegentlich zerschossen sind.
Jetzt habe ich verschiedenen Tests gemacht und bin zu dem Schluss gekommen, dass es sehr wahrscheinlich an der Browser-Kodierung des Users liegt.

Die Website ist noch in ISO 8859-1 angelegt (und zu umfangreich das mal schnell auf UTF8 umzustellen).
Nun vermute ich, dass wenn ein User keine automatische Erkennung der Textkodierung im Brower aktiviert hat und diese fest auf UTF-8 steht, dass dann eben die Umlaute falsch übertragen werden.
Wenn ich immer mit utf8_decode() die Werte ändere, sind die aber auch teils falsch.

SELFHTML: HTML/XHTML / Formulare / Formulare definieren

Aber in der Regel ist das nicht notwendig. Vermutest du, dass die User eine andere Zeichenkodierung einstellen oder weißt du das? Eine falsch gewählte Kodierung kann übrigens auch an kaputtem HTML-Code liegen. Schon mal deinen HTML-Code mit dem W3C-Validator auf Fehler überprüft?

Meine Frage nun: Kann ich irgendwie abfragen, in welcher Kodierung Werte übergeben wurden

Nein, das ist nicht möglich. Man kann es höchstens erraten, was aber nicht zuverlässig funktioniert.

[andik2000]

Prima, accept-charset ist die Lösung!

Ich habe sonst keine andere Erklärung und konnte das Ergebnis auch durch umstellen der Textcodierung im Browser rekonstruieren.
Ich vermute, dass manche Browser mittlerweile fest auf UTF-8 gestellt sind.

Jetzt habe ich in einem Testformular accept-charset verwendet und siehe da - die Mail kommt sauber an, egal auf welche Kodierung ich den Browser stelle.
Nun hoffe ich mal, dass das auf der Live-Website jetzt auch das Problem lösen wird.

Danke, Andi

[h3ll]

Ich habe sonst keine andere Erklärung und konnte das Ergebnis auch durch umstellen der Textcodierung im Browser rekonstruieren.

Schon den HTML-Code auf Fehler überprüft? Welche Kodierung wird im HTTP-Header gesetzt?

Ich vermute, dass manche Browser mittlerweile fest auf UTF-8 gestellt sind.

Nein.

[andik2000]

Schon den HTML-Code auf Fehler überprüft? Welche Kodierung wird im HTTP-Header gesetzt?

Ja, ich habe alle Header-Angaben geprüft, was relativ einfach ist, da dieser nur einmalig in einem Template gesetzt wird - aber ich habe auch die Kodierung der Templates und PHP-Dateien geprüft, ob hier irgendwo im Weg mal eine Datei UTF-8 codiert ist, aber habe nichts gefunden.

Da von 100 Formularen nur 2-3 dabei sind, bei denen es Probleme mit den Umlauten gibt, vermute ich halt schon, dass es irgendwie an der Browser-Kodierung liegt.
Ich habe selbst hier in der Agentur mit 15 Rechnern festgestellt, dass bei dreien der Browser nicht auf "Standard" bzw. "automatische Erkennung" sondern auf UTF-8 oder "Western Europe ISO Latin 1" gestellt war. Und das bei Grafikern, die nie irgendetwas an den Einstellungen verändern. Bei nem Programmierer hätte ich das ja noch nachvollziehen können, dass da zum Testen mal was verstellt wurde.

Auf jeden Fall füllt das accept-charset hier auch wieder eine Wissenslücke und hoffe, dass dies das Problem dauerhaft löst.
Wir werden es in den nächsten Tagen wissen :-)

[h3ll]

Ja, ich habe alle Header-Angaben geprüft, was relativ einfach ist, da dieser nur einmalig in einem Template gesetzt wird - aber ich habe auch die Kodierung der Templates und PHP-Dateien geprüft, ob hier irgendwo im Weg mal eine Datei UTF-8 codiert ist, aber habe nichts gefunden.

Ich meinte nicht nur den Header, sondern das gesamte HTML-Dokument.

Außerdem hast du meine Frage zum HTTP-Header (nicht HTML-Header) nicht beantwortet.

Da von 100 Formularen nur 2-3 dabei sind, bei denen es Probleme mit den Umlauten gibt, vermute ich halt schon, dass es irgendwie an der Browser-Kodierung liegt.

Dann hätten aber alle das Problem und nicht nur du, oder?

Ich habe selbst hier in der Agentur mit 15 Rechnern festgestellt, dass bei dreien der Browser nicht auf "Standard" bzw. "automatische Erkennung" sondern auf UTF-8 oder "Western Europe ISO Latin 1" gestellt war. Und das bei Grafikern, die nie irgendetwas an den Einstellungen verändern.

Jaja... Die "ich hab nichts gemacht"-User. Wer kennt sie nicht? Von alleine verstellt sich das jedenfalls nicht.

Auf jeden Fall füllt das accept-charset hier auch wieder eine Wissenslücke und hoffe, dass dies das Problem dauerhaft löst.
Wir werden es in den nächsten Tagen wissen :-)

Naja, Accepted-Charset schadet sicher nicht. Aber wenn der Browser eine falsche Kodierung wählt, sind spätestens bei der Ausgabe wieder Zeichenprobleme vorprogrammiert. Von daher sollte man das Problem an der Wurzel packen und nicht die Folgen umgehen.

[andik2000]

Also das Umlaut-Problem berichten mir immer mal wieder drei Kunden, bei denen die Seiten noch in ISO 8859-1 sind.
Im einfachsten Fall haben wir wirklich eine ganz simple Seite mit nem Kontaktformular, wo dahinter die Werte per Mail an den Kunden verschickt werden. Der meldet sich alle halbe Jahre mal, dass er ne Mail mit komischen Zeichen bekommen hat.

Bei nem anderen Kunden laufen halt in der Woche ca. 100 Mails ein. Und da sind dann immer so 2-3 dabei, bei denen es die Umlaute zerhaut.
Wäre das häufiger der Fall, würde ich den Fehler auch an anderer Stelle vermuten - aber ich bin schon mehrfach sämtliche Seiten, Config-Files und Include-Files durchgegangen und habe die Kodierung geprüft.
Und auch egal in welchem Browser und Plattform ich selbst Test-Formulare abschicke, die kommen immer korrekt an.
Nun habe ich eben den Test gemacht, den Browser fest auf UTF-8 zu stellen - und siehe da, die Umlaute werden zerschossen.

Das ist es für mich nach all dem die naheliegendste Vermutung.
Wir werden ja sehen, ob nach der Umstellung mehr oder weniger Mails mit falschen Umlauten ankommen. Zurückstellen und weiter suchen kann man ja dann immer noch

[h3ll]

Also das Umlaut-Problem berichten mir immer mal wieder drei Kunden, bei denen die Seiten noch in ISO 8859-1 sind.
Im einfachsten Fall haben wir wirklich eine ganz simple Seite mit nem Kontaktformular, wo dahinter die Werte per Mail an den Kunden verschickt werden. Der meldet sich alle halbe Jahre mal, dass er ne Mail mit komischen Zeichen bekommen hat.

Bei nem anderen Kunden laufen halt in der Woche ca. 100 Mails ein. Und da sind dann immer so 2-3 dabei, bei denen es die Umlaute zerhaut.
Wäre das häufiger der Fall, würde ich den Fehler auch an anderer Stelle vermuten - aber ich bin schon mehrfach sämtliche Seiten, Config-Files und Include-Files durchgegangen und habe die Kodierung geprüft.
Und auch egal in welchem Browser und Plattform ich selbst Test-Formulare abschicke, die kommen immer korrekt an.
Nun habe ich eben den Test gemacht, den Browser fest auf UTF-8 zu stellen - und siehe da, die Umlaute werden zerschossen.

Warum machst du nicht einfach das, was ich gesagt habe?

[andik2000]

W3c Validator findet Fehler, die sich aber alle auf schließende Klammern beziehen - /> statt >.
Als Encoding wird ISO 8895-1 erkannt.
Ich habe auch mal in Firebug und HTTP-Fox den Header angeschaut, hier wird aber keine Information zum Encoding genannt.
Einzig "Transfer-Encoding: chunked" wird angezegt.

[h3ll]

Ich habe auch mal in Firebug und HTTP-Fox den Header angeschaut, hier wird aber keine Information zum Encoding genannt.

Kann ich kaum glauben. Aber selbst wenn es so ist, ist es nicht korrekt. Sende beim HTTP-Header das richtige Encoding, dann weiß der Browser auch, was er nehmen muss ohne zu raten.

header('Content-Type: text/html; charset=ISO-8859-1'); 

Einzig "Transfer-Encoding: chunked" wird angezegt.

Das ist sicher nicht der ganze Header.

[andik2000]

Ach stimmt, so könnte man das ja fix angeben. Teste ich auch mal aus.

Im Anhang mal, wie der Header im Firebug anhezeigt wird. Das ist 1:1 auch im Http-Fox so.

[h3ll]

Der fehlt tatsächlich das Encoding im Header. Sollte man immer angeben.

Was ich aber auch sehe: PHP 5.2.5. Dir ist klar, dass der Server ein Sicherheitsrisiko darstellt, da für diese uralte, tote PHP-Version schon seit Ewigkeiten keine Sicherheits-Update mehr erschienen sind?

[andik2000]

Ja, zum Glück sind wir aber nicht fürs Hosting zuständig, das betreut eine andere Agentur

[h3ll]

Ja, zum Glück sind wir aber nicht fürs Hosting zuständig, das betreut eine andere Agentur

Seid aber trotzdem davon betroffen. Es liegen ja eure Daten und eure Software am Server, oder?

[andik2000]

Da hast du recht. Habe schon den Hoster informiert, ob da schon ne aktuelle Version vorliegt. Oft kann man das ja sogar übers Konfig-Tool schon direkt umstellen.