Umlaute werden vom PHP-Script "geschrottet"

[Maax^]

Hi,
ich habe ein Problem und würde mich sehr freuen wenn jemand mir bei dessen Beseitigung mit einem Tipp helfen könnte.

Und zwar bin ich von Debian nach Suse umgestiegen und habe in diesem Zusammenhang meine Textdateien von ISO-8859-1 nach UTF-8 konvertiert.
Das betraf auch die PHP-Scripts meiner Website und damit auch das Gästebuchscript.

Seither wurden die Umlaute durch unleserliche Zeichen ersetzt.

Also habe ich die alte Gästebuchdatei testweise umbenannt - doch auch in der vom Script dann neu erstellten Datei findet sich nur etwas `a la "Grüße" statt Grüße.
"file DATEINAME" (per SSH) gibt "DATEINAME: UTF-8 Unicode text, with CR, LF line terminators" aus.

Leider konnte ich trotz langer Suche im Internet (die ich mehrmals für einige Tage aufgab) keine Lösung findne - vielleicht suche ich aber auch einfach falsch.
Kennt jemand zufällig das Problem oder sogar die Lösung?

Danke
Maax^

[Der Martin]

Hallo,

Und zwar bin ich von Debian nach Suse umgestiegen und habe in diesem Zusammenhang meine Textdateien von ISO-8859-1 nach UTF-8 konvertiert.
Seither wurden die Umlaute durch unleserliche Zeichen ersetzt.
[...] "Grüße" statt Grüße.

dann liefert dein Server die Seiten immer noch mit der Zeichencodierung ISO-8859-1 im HTTP-Header aus. Das solltest du ändern.

Entweder in der globalen Serverkonfiguration, wenn du darauf Zugriff hast.
Oder lokal über eine .htaccess-Datei.
Oder individuell in jedem PHP-Script, indem du den entsprechenden Header selbst sendest. Wobei das bei statischen Seiten nicht hilft.

So long,
 Martin

[Maax^]

Hallo Martin,
danke für deine super schnelle Antwort.

dann liefert dein Server die Seiten immer noch mit der Zeichencodierung ISO-8859-1 im HTTP-Header aus. Das solltest du ändern.

Ich glaube nicht - das Gästebuchscript enthält auch Umlaute die nicht aus der Datei kommen - und die werden richtig dargestellt.
Die Fehler entstehen nur bei den Inhalten die in der Datei (mit den Gästebucheinträgen) gespeichert werden - dort sind die Umlaute auch schon nicht lesbar.

Oder individuell in jedem PHP-Script, indem du den entsprechenden Header selbst sendest. Wobei das bei statischen Seiten nicht hilft.

Das tue ich.

Danke
Maax^

[wahsaga]

hi,

dann liefert dein Server die Seiten immer noch mit der Zeichencodierung ISO-8859-1 im HTTP-Header aus. Das solltest du ändern.

Ich glaube nicht - das Gästebuchscript enthält auch Umlaute die nicht aus der Datei kommen - und die werden richtig dargestellt.

_Ich_ glaube nicht, dass du das Gästebuch-Script ebenfalls als UTF-8 gespeichert hast ...

gruß,
wahsaga

[Maax^]

Hi,
danke für die Antwort.

dann liefert dein Server die Seiten immer noch mit der Zeichencodierung ISO-8859-1 im HTTP-Header aus. Das solltest du ändern.

Ich glaube nicht - das Gästebuchscript enthält auch Umlaute die nicht aus der Datei kommen - und die werden richtig dargestellt.

_Ich_ glaube nicht, dass du das Gästebuch-Script ebenfalls als UTF-8 gespeichert hast ...

Ich habe das noch mal überprüft - wie gesagt, die Umlaute im Script werden ja auch richtig dargestellt.
Das Problem scheint damit zusammenzuhängen das alles, was über Formulare kommt (und damit auch der Inhalt der Datei in der die Formulareingaben gespeichert werden) "kaputte" Umlaute enthällt.
Habe gerade auch Daten aus dem Kontaktformular per Email bekommen - auch dort sind die Umlaute durch "Schrott" ersetzt.

Könnte es wirklich sein, dass die Formulardaten vom Browser als ISO-8859-1 abgeschickt werden obwohl sie auf einer UTF-8 Seite eingegeben werden?

Danke
Maax^

[wahsaga]

hi,

Könnte es wirklich sein, dass die Formulardaten vom Browser als ISO-8859-1 abgeschickt werden obwohl sie auf einer UTF-8 Seite eingegeben werden?

Schon denkbar - accept-charset im Formular würde ich immer mit angeben.

gruß,
wahsaga

[Maax^]

Hi,
danke für den Tipp.

Das Problem ist nun schon kleiner - allerdings habe ich die endgültige Lösung trotz erneuter Recherche nicht finden können.

Und zwar sind die Umlaute in der Datei nun ok - aber htmlentities() macht aus den Umlauten trotzdem nach wie vor Schrott.
Gibt es eine Möglichkeit htmlentities() mitzuteilen, dass man mit UTF-8 arbeitet?

Grüße
Maax^

[wahsaga]

hi,

Und zwar sind die Umlaute in der Datei nun ok - aber htmlentities() macht aus den Umlauten trotzdem nach wie vor Schrott.

Wozu bitte willst du htmlentities verwenden, wenn du UTF-8 nutzt? Mit UTF-8 kannst du doch alle Zeichen "direkt" abbilden.

Zum Umwandeln der HTML-eigenen Zeichen gibt es htmlspecialchars.

gruß,
wahsaga

[Maax^]

Hi,
danke für die Antwort.

Und zwar sind die Umlaute in der Datei nun ok - aber htmlentities() macht aus den Umlauten trotzdem nach wie vor Schrott.

Wozu bitte willst du htmlentities verwenden, wenn du UTF-8 nutzt? Mit UTF-8 kannst du doch alle Zeichen "direkt" abbilden.

Zum Umwandeln der HTML-eigenen Zeichen gibt es htmlspecialchars.

Aus Nostalgie?
Ok - vielen Dank für den Tipp - genau das war das Problem.
Ich habe einfach nicht daran gedacht weil ich htmlentities() damals als ich das Script geschrieben habe brauchte...

Dann muss ich jetzt nur noch einen Stapel Einträge ändern die das Script  demoliert hat...

Vielen Dank!

Maax^

[wahsaga]

hi,

Zum Umwandeln der HTML-eigenen Zeichen gibt es htmlspecialchars.

Ich habe einfach nicht daran gedacht weil ich htmlentities() damals als ich das Script geschrieben habe brauchte...

htmlentities ist hier "gefährlich", weil PHP eigentlich noch kein UTF-8 "kann".
Es gibt zwar ein paar mbstring-Funktionen als (u.a.) UTF-8-tauglichen Ersatz für "normale" Stringfunktionen - aber die restlichen Stringfunktionen betrachten auch Zeichen, die in UTF-8 mit mehreren Bytes dargestellt werden, als eben so viele "mehrere" Zeichen.

Wenn jetzt ein ä in UTF-8 den beiden (hexadezimalen) Bytewerten E4 00 entspricht (als ASCII dargestellt ä) - dann nimmt sich htmlentities jedes von den beiden einzeln vor, und versucht es als HTML-Entity umzuschreiben - logisch, dass dabei Kappes rauskommt.

htmlspecialchars hat dieses Problem nicht - aber auch nur deshalb, weil es maximal die Zeichen <, >, " und ' bearbeitet - und die werden auch in UTF-8 alle mit nur einem Byte dargestellt.

gruß,
wahsaga

[dedlfix]

echo $begrüßung;

htmlentities ist hier "gefährlich", weil PHP eigentlich noch kein UTF-8 "kann".
htmlspecialchars hat dieses Problem nicht - aber auch nur deshalb, weil es maximal die Zeichen <, >, " und ' bearbeitet - und die werden auch in UTF-8 alle mit nur einem Byte dargestellt.

Beide Funktionen haben einen Parameter namens charset, der den übergebenen String diesem entsprechend interpretiert.

echo "$verabschiedung $name";

[dedlfix]

echo $begrüßung;

htmlspecialchars hat dieses Problem nicht - aber auch nur deshalb, weil es maximal die Zeichen <, >, " und ' bearbeitet - und die werden auch in UTF-8 alle mit nur einem Byte dargestellt.

Die Byte-Werte dieser Zeichen kommen in den Kodierungen ISO-8859-xx und UTF-8 nur einmal vor. Deshalb kann es da keine Missverständnisse geben. Aber einige im asiatischen Raum gebräuchliche Kodierungen verwenden diese Byte-Werte ein zweites Mal. Da ist es wichtig, den charset-Parameter richtig anzugeben.

echo "$verabschiedung $name";

[Maax^]

Hi,
danke für die Infos.
Nun - ich denke in meinem speziellen sollte das kein Problem sein. Trotzdem danke - ich werde es im Hinterkopf behalten. (Mal sehen wo da noch Platz ist :-) ).
Grüße
Maax^

[wahsaga]

hi,

Die Byte-Werte dieser Zeichen kommen in den Kodierungen ISO-8859-xx und UTF-8 nur einmal vor. Deshalb kann es da keine Missverständnisse geben. Aber einige im asiatischen Raum gebräuchliche Kodierungen verwenden diese Byte-Werte ein zweites Mal. Da ist es wichtig, den charset-Parameter richtig anzugeben.

Was für Kodierungen?
UTF-8 kannst du wohl nicht meinen, denn da herrscht ja "Eindeutigkeit".
Wenn ich also weiss, dass ich nur UTF-8 verarbeite, und keine "Kodierung made in China", könnte ich mir die charset-Angabe da also wieder sparen, oder?

(Du hast natürlich recht, es wäre vermutlich besser, sie immer anzugeben.)

gruß,
wahsaga

[Maax^]

Hi,

Was für Kodierungen?
UTF-8 kannst du wohl nicht meinen, denn da herrscht ja "Eindeutigkeit".

meinte er nicht dass es eindeutig sein muss was der Content für eine Kodierung hat?

Grüße
Maax^

[dedlfix]

echo $begrüßung;

Die Byte-Werte dieser Zeichen kommen in den Kodierungen ISO-8859-xx und UTF-8 nur einmal vor. Deshalb kann es da keine Missverständnisse geben. Aber einige im asiatischen Raum gebräuchliche Kodierungen verwenden diese Byte-Werte ein zweites Mal. Da ist es wichtig, den charset-Parameter richtig anzugeben.

Da es hier ja nur um die Zeichen &"'<> geht, muss ich mich vermutlich revidieren. Bei meiner jetzigen Nachrecherche fand ich nur Shift_JIS und GBK (bzw. 936), das Werte im Bereich x40-x7F doppelt belegt. Alle anderen Kodierungen nutzten nur den Bereich ab x80 aufwärts.
Neulich beschäftigte ich mich mit dem Unterschied zwischen mysql_escape_string und mysql_real_escape_string - letzteres interessiert sich für das charset der Verbindung, ersteres nicht - und den Fehlern, die bei Verwendung von mysql_escape_string auftreten können, und hatte mir nur gemerkt, dass ein Unterschied bei ISO-8859 und UTF-8 nicht vorhanden ist. Bei Shift_JIS und GBK bekommt man Probleme mit dem \ (x5C), da der innerhalb der x40-x7F liegt

Was für Kodierungen?
UTF-8 kannst du wohl nicht meinen, denn da herrscht ja "Eindeutigkeit".

Nein, das schloss ich ja bereits aus.

Wenn ich also weiss, dass ich nur UTF-8 verarbeite, und keine "Kodierung made in China", könnte ich mir die charset-Angabe da also wieder sparen, oder?

Sie ist bei htmlspecialchars() (nach meinem jetzigen Kenntnisstand) verzichtbar. Bei htmlentities() dagegen nicht, aber das will man ja zugunsten von UTF-8 gar nicht einsetzen.

echo "$verabschiedung $name";

[Maax^]

Hi,
danke für die Antwort.

Perfekt - nun sind wage Vermutung durch Gewissheit ersetzt. Vielen Dank!

Grüße
Maax^