nicht angemeldet
Die gute alte Zeichenkodierung
Hallo Forum,
ich habe es mal wieder mit einem Fehler bei der Zeichenkodierung zu tun. Nun komme ich aber nicht darauf, wo genau er liegt. Es geht um eine bestehende XHTML/PHP/MySQL-Anwendung. Über Formulare werden Texte editiert, die per PHP in einer MySQL-DB gespeichert und dort ausgelesen werden.
Sonderzeichen werden ...
Im Browser richtig dargestellt. Laut Seiteninformation (Firefox) ist die Zeichenkodierung UTF8, was mit der Angabe im <head> übereinstimmt. Unter PMA sind die Sonderzeichen aber kaputt. Der Dump mit meinem Editor (Panic Coda) ist UTF 8 und auch da sind die Sonderzeichen kaputt.
Lässt sich mit den Infos sagen, wo das Problem
besteht?
danke für Tipps und
beste grüsse,
heinetz
-
Hello,
Lässt sich mit den Infos sagen, wo das Problem
besteht?Hast Du nach der Eröffnung der Datenbankverbindung auch den Transfer-Typ für die Codierung angegeben?
mysqli_set_charset()
http://de3.php.net/manual/en/mysqli.set-charset.php
Ich hatte das gleiche Problem :-)
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
hi,
Hast Du nach der Eröffnung der Datenbankverbindung auch den Transfer-Typ für die Codierung angegeben?
Bei den Anwendungen, die ich selbst geschrieben habe, hatte ich am Ende immer einigermassen verstanden, was alles beachtet werden muss, um utf8-kodierte daten zwischen xhtml, php und der mysql auszutauschen. Ich erinnere mich auch dunkel daran, dass es wichtig war, den Zeichensatz für die Verbindung zwischen mysql und php festzulegen. Jetzt stehe ich vor einer Anwendung, bei der es offenbar einen Fehler gibt, die ich aber selbst nicht geschrieben habe und versuche zu interpretieren, was das Problem ist.
gruss,
heinetz-
… ich habe also noch ein wenig weiter versucht zu interpretieren. Im Dump steht bspw. folgendes Wort:
Spritzfüller
Korrigieren kann ich es auf folgende Weise:
Mein Editor bietet mir zum Thema Zeichenkodierung zwei (genau genommen 3) Möglichkeiten. Die erste ist, dass er mir anzeigt mit welcher Kodierung ein Dokument abgespeichert ist. Die zweite, dass ich das ändern und bspw. ein iso-8859 in ein utf-8 konvertieren kann, die dritte ist, statt zu konvertieren, erstmal nur das iso-8859 als utf-8 zu interpretieren.
Das ist sehr aufschlussreich, denn interpretiere ich das Wort als utf-8 wird es korrekt dargestellt.
In meinem Dokument steht, wenn ich das richtig verstehe ein utf-8-kodierter String, der nicht als utf-8 interpretiert wird.
Im Dump steht ausserdem DEFAULT CHARSET=latin1, im Browser aber utf-8. Ohne etwas über den Transfer-Typ herausgefunden zu haben, würde ich das so interpretieren, dass bei der Anwendung lediglich das Frontend irgendwann mal auf utf-8 umgestellt worden ist und utf-8-kodierte Daten irgendwie in der latin1-DB speichert.
Ganz pervers ist aber folgender Text, den ich in dem Dump und im Frontend gefunden habe:
für kleine Reparatur- und Durchschliffstellen. Überschweißbar!
Hier fehlt mir die Phantasie ;) Der Text steht in ein und dem selben Formular- bzw. DB-Feld. Wie kriegt man das hin?
gruss,
heinetz-
Tach!
… ich habe also noch ein wenig weiter versucht zu interpretieren. Im Dump steht bspw. folgendes Wort:
SpritzfüllerDas ist UTF-8 interpretiert als ISO-8859-1. Es kann aber auch UTF-8 sein, das als ISO-8859-1 gelesen und nochmal nach UTF-8 umkodiert wurde und nun als UTF-8 gelesen wird. Bei Fehlern kann man solche kruden Szenarien nicht ausschließen. Das beste ist, sich solchen Dinge nicht im von irgendwem interpretierten Zustand anzusehen sondern die Bytes. Unter PHP kann man sehr gut urlencode() missbrauchen, um sich die Bytes der Nicht-ASCII-Zeichen anzusehen. Ein Hexeditor tut es aber auch.
Mein Editor bietet mir zum Thema Zeichenkodierung zwei (genau genommen 3) Möglichkeiten. Die erste ist, dass er mir anzeigt mit welcher Kodierung ein Dokument abgespeichert ist.
Das ist theoretisch unmöglich. Hier kann er nur anhand bestimmter Indizien raten. Mit mehr oder weniger Erfolg.
[...] denn interpretiere ich das Wort als utf-8 wird es korrekt dargestellt.
Nun, dann wird es wohl so kodiert sein.
In meinem Dokument steht, wenn ich das richtig verstehe ein utf-8-kodierter String, der nicht als utf-8 interpretiert wird.
Von wlchem System wird er falsch interpretiert? Und was wurde diesem System gesagt, sei die vorliegende Kodierung?
Im Dump steht ausserdem DEFAULT CHARSET=latin1, im Browser aber utf-8.
Wenn man dem Dump-Programm nicht sagt, in welcher Kodierung es die ausgelesenen Daten speichern soll, nimmt es irgendeinen Default-Wert.
Ohne etwas über den Transfer-Typ herausgefunden zu haben, würde ich das so interpretieren, dass bei der Anwendung lediglich das Frontend irgendwann mal auf utf-8 umgestellt worden ist und utf-8-kodierte Daten irgendwie in der latin1-DB speichert.
Transfer-Typ ist im HTTP-Umfeld etwas anderes. Die charset-Angabe im Content-Type ist hier maßgeblich.
Ganz pervers ist aber folgender Text, den ich in dem Dump und im Frontend gefunden habe:
für kleine Reparatur- und Durchschliffstellen. Überschweißbar!Kodierungsmix/-müll. Kommt davon, wenn man das Zusammenspiel zwischen den Systemen nicht ordentlich aufgesetzt hat.
Hier fehlt mir die Phantasie ;) Der Text steht in ein und dem selben Formular- bzw. DB-Feld. Wie kriegt man das hin?
Händisch korrigieren. Es sei denn, du entdeckst ein Muster, das sich ohne Ausnahmen durch alle Daten zieht, dann kannst du das durch Suchen und Ersetzen oder ähnlichem korrigieren.
dedlfix.
-
ich hab gesucht und gefunden:
es war schlicht kaputtes XHTML und der Browser hat deshalb die Meta-Angabe zum Zeichensatz ignoriert und selbst etwas hereininterpretiert. Aufgefallen ist mir das, weil sich die Ausgabe in verschiedenen Browsern unterschied.
danke für die geduldige Hilfe und
gruss,
heinetz
-
-
-
-
-
Tach!
ich habe es mal wieder mit einem Fehler bei der Zeichenkodierung zu tun. Nun komme ich aber nicht darauf, wo genau er liegt. Es geht um eine bestehende XHTML/PHP/MySQL-Anwendung. Über Formulare werden Texte editiert, die per PHP in einer MySQL-DB gespeichert und dort ausgelesen werden.
Siehe im Wiki: http://wiki.selfhtml.org/wiki/Themen:Zeichencodierung
Lässt sich mit den Infos sagen, wo das Problem besteht?
Bitte schau erstmal nach, ob du an Schnittstellen zwischen zwei Systemen die Zeichenkodierung eingestellt/ausgehandelt hast, so wie es dort beschrieben steht.
dedlfix.