MySQL: nach Umstellung auf Gentoo ist alles UTF-8-kodiert

[Candid Dauth]

Heißa, alle,

auf meinem Server war ursprünglich ein Debian (testing) installiert, mit MySQL 4.1 drauf. Nun habe ich ein Gentoo draufgetan, ebenfalls mit MySQL 4.1, und soweit funktioniert das auch. Das Problem ist aber, dass in den beiden MySQL-PHP-Programmen, die ich benutze, Flyspray und Woltlab Burning Board, nun alle Dinge, die vorher unter Debian in die Datenbank eingetragen wurden, UTF-8 kodiert zurückkommen. In PHPMyAdmin hingegen werden sie ganz normal angezeigt.

Ich muss anmerken, dass ich mich nun wirklich überhaupt nicht mit MySQL auskenne, und es war wohl ein Fehler, das alte /var/lib/mysql von Debian einfach unter Gentoo weiterzuverwenden.

Was ich nun komisch finde an der ganzen Sache, ist, dass bei einem MySQL-Dump die ganzen Umlaute korrekt Latin-1-kodiert in der Dump-Datei drinstehen. Wenn ich den Dump aber wieder zurück in die MySQL-Datenbank schicke, tritt das Problem wieder auf. In den Raw-Dateien in /var/lib/mysql übrigens stehen die ganzen Dinger ebenfalls UTF-8-kodiert drinnen, keine Ahnung, vielleicht ist das ja normalerweise nicht so.

Außerdem wurde ich darauf hingewiesen, dass es unter Gentoo für MySQL ein USE-Flag „latin1“ gibt, ich habe das mal aktiviert, aber das hat auch nichts geändert.

In meiner my.cnf stehen im Moment alle Charsets auf latin1 (wegen des USE-Flags), vorher standen sie alle auf utf8, das hat aber nichts geändert.

Hat jemand eine Idee, was ich gegen dieses Problem unternehmen könnte?

Gautera!
Grüße aus Biberach Riss,
Candid Dauth

[Candid Dauth]

Heißa, Candid,

das Problem scheint sich gerade selbst gelöst zu haben. Nachdem ich meinen eigenen Rechner neugestartet habe, funktioniert es nämlich, und ich kann mir beim besten Willen nicht erklären, warum. An dem Dump kann es nicht gelegen haben, da es jetzt in allen Datenbanken funktioniert, ich den Dump aber nur auf eine Datenbank ausgeführt habe.
Wahrscheinlich wurde MySQL nach dem Neukompilieren mit latin1 nicht richtig neugestartet, oder so etwas in der Art.

Gautera!
Grüße aus Biberach Riss,
Candid Dauth

[dedlfix]

echo $begrüßung;

Seit Version 4.1 sollte man das Thema Zeichensatz nicht dann auf die leichte Schulter nehmen, wenn einem seine Daten lieb und teuer sind. Im Handbuch beschäftigt sich ein ganzes Hauptkapitel damit: Character Set Support

auf meinem Server war ursprünglich ein Debian (testing) installiert, mit MySQL 4.1 drauf. Nun habe ich ein Gentoo draufgetan, ebenfalls mit MySQL 4.1, und soweit funktioniert das auch.
Ich muss anmerken, dass ich mich nun wirklich überhaupt nicht mit MySQL auskenne, und es war wohl ein Fehler, das alte /var/lib/mysql von Debian einfach unter Gentoo weiterzuverwenden.

Das sollte kein Problem darstellen, es sei denn, "alt" bezieht sich auf eine Version vor 4.1. Sie sind auch dann "alt", wenn die Datenbanken/Tabellen mal unter 4.0 erstellt wurden und unter 4.1 weiterverwendet werden, ohne dass man irgendwann einmal explizit eine Zeichensatz/Sortierungsangabe eingestellt hat. In den alten Dateien fehlen zu den Datenbanken, Tabellen und Feldern (jeweils einzeln) die Angaben, welcher Zeichensatz und welche Kollation verwendet werden soll. Das Error-Log müsste die fehlende Angabe bei jedem Zugriff beanstanden.

Die Angabe der Kollation ist weniger bedeutend. Wichtig ist die Angabe zum Zeichensatz, denn hier tritt Datenverlust auf, wenn die Datenbanken, Tabellen und Felder keine Zeichensatzinformation enthalten und der Default-Zeichensatz der Servers ein anderer als der der Daten ist.

Wenn man bisher latin1-kodierte Daten hat, und dabei bleiben möchte, reicht es, die Kollation zu verändern, um die Zeichensatz-Information in den Tabellendateien einzutragen. Steht beispielsweise latin1_swedish_ci (Schwedisch ist die Default-Sortierung unter MySQL) als Zeichensatz/Kollation bei Stringtyp-Feldern kann man das auf latin1_german1_ci umstellen. (ALTER TABLE ... irgendwas. phpMyAdmin zeigt das passende Statement ja an.)

Das Problem ist aber, dass in den beiden MySQL-PHP-Programmen, die ich benutze, Flyspray und Woltlab Burning Board, nun alle Dinge, die vorher unter Debian in die Datenbank eingetragen wurden, UTF-8 kodiert zurückkommen. In PHPMyAdmin hingegen werden sie ganz normal angezeigt.

Für die Kommunikation von umd zum Client sind die Einstellungen character_set_client, character_set_connection und character_set_results interessant. Sie entsprechen der Server-Default-Einstellung character_set_server. (Ein explizites Einstellen dieser drei Werte in der my.cnf gelang mir nicht. Waren diese Werte vorhanden startete MySQL 4.1.19 nicht.)
Der Server nimmt nun bei jeder Client-Kommunikation an, dieser spreche {character_set_client} und möchte die Anwortdaten in {character_set_results} haben. Wenn die beteiligten Tabellen und Felder einen anderen Zeichensatz eingestellt haben übersetzt MySQL von und zum Client so gut es geht (nicht in Zeichensatz x enthaltene Zeichen lassen sich damit nicht darstellen. Ersatzschreibweisen à la &0123; gibt es an der Stelle nicht.)

Spricht der Client anders als der Server es erwartet und umgekehrt, ist die Wahrscheinlichkeit Datenmüll zu bekommen recht hoch. Der Client sollte, wenn er feststellt, dass der Server Version 4.1 und höher hat, dem Server explizit mitteilen, welchen Zeichensatz er zu verwenden gedenkt. SET NAMES ...
(Beim Abfragen der Version bitte bedenken, dass Client-API und Server unterschiedliche Versionsnummern haben können und man die richtige Funktion zum Abfragen der Versionsnummer verwendet. phpinfo() beispielsweise gibt nur die Client-API-Version an, da es sich nicht zum Server connecten kann, um diesen zu befragen. Woher soll es auch wissen, zu welchem Server man in seinem Script eine Verbindung aufzubauen gedenkt.)

In PHPMyAdmin hingegen werden sie ganz normal angezeigt.

Ja, die phpMyAdmin-Autoren haben die Problematik erkannt und die Anwendung so geschrieben, dass es bei der Kommunikation mit dem Server zu keinen Zeichensatz-Unklarheiten kommt.

Was ich nun komisch finde an der ganzen Sache, ist, dass bei einem MySQL-Dump die ganzen Umlaute korrekt Latin-1-kodiert in der Dump-Datei drinstehen. Wenn ich den Dump aber wieder zurück in die MySQL-Datenbank schicke, tritt das Problem wieder auf. In den Raw-Dateien in /var/lib/mysql übrigens stehen die ganzen Dinger ebenfalls UTF-8-kodiert drinnen, keine Ahnung, vielleicht ist das ja normalerweise nicht so.

Auch die MySQL-eigenen Anwendungen können nicht zaubern. Der Zeichensatz, in dem Daten vorliegen, lässt sich prinzipiell nicht eindeutig ermitteln.
Die Fragen, die sich der Anwender vor der Benutzung von diesen und anderen Tools stellen sollte sind aus meiner Sicht:

Welchen Zeichensatz erwartet das Tool?
Nach welchem Zeichensatz sind meine Daten kodiert?
Wie muss ich dem Tool Abweichungen von seinen Zeichensatz-Erwartungen mitteilen?

Für diese MySQL-eigenen Anwendungen lassen sich die abweichende Default-Werte ebenfalls in der my.cnf einstellen.

Außerdem wurde ich darauf hingewiesen, dass es unter Gentoo für MySQL ein USE-Flag „latin1“ gibt, ich habe das mal aktiviert, aber das hat auch nichts geändert.
In meiner my.cnf stehen im Moment alle Charsets auf latin1 (wegen des USE-Flags), vorher standen sie alle auf utf8, das hat aber nichts geändert.

Das USE-Flag macht nichts weiter, als die my.cnf so umzustellen, dass die Default-Kodierung des Servers latin1 ist.

echo "$verabschiedung $name";