dedlfix: UTF-8 und Windows

Beitrag lesen

Tach!

So langsam dringt Licht durchs Dickicht. Wobei @Raketenrecodierer das schon im zweiten Satz so gesagt hat: Die Angaben in der DB bezeichnen nicht die Codierungen des Inhalts, sondern die Art, wie mit dem Inhalt umgegangen werden soll: bei Sortierreihenfolgen und Ähnlichem.

Jein. Genauer gesagt besteht eine Kollationsangabe aus drei Teilen: Kodierung, Kollation und Case Sensitivity. Die Kodierung gibt wirklich an, wie die Daten gespeichert sind. Die anderen beiden sind die genannten Verarbeitungshinweise zum Vergleichen und Sortieren.

Und davon abweichend gibt es die eigentliche Codierung des Inhalts (unerheblich, wie diese realisiert ist, solange sie nur die verlustfreie Konvertierung ermöglicht), wobei deren Ein- und Ausgabe bestimmt werden kann, aber eben nicht so, wie von mir fälschlich vermutet. Anstelle des gewünschten - und vermeintlich eingestelten "utf-8" gilt weiterhin der default "latin1". Letzteres laut Handbuch, das ich auf der Suche nach einem Menu für die Konfiguration dann endlich gefunden habe.

Nein, wenn die Daten tatsächlich generell in latin1 (aka Win-1252) gespeichert wären, gäbe es Verlust, wenn man versuchen würde, die restlichen Unicode-Zeichen zu speichern. Die Kodierung eines Feldes entspricht stattdessen schon der jeweils dort angegebenen. Zusätzlich dazu gibt es weitere Kodierungen - wovon die wichtigste diejenige ist, die auf der Client-Verbindung verwendet wird - und MySQL konvertiert gegebenenfalls hin und her.

Dass verlustfrei konvertiert werden kann (oder es am besten gar nicht werden muss), dafür musst du sorgen. Also immer UTF-8 verwenden und das auch so angeben. Wobei man noch prüfen muss, ob der "Dialekt" utf8mb4 benötigt wird.

Den default jetzt für die ganze DB zu ändern, ist aber nicht die Lösung. Denn mit der Umstellung würde das laufende System vermutlich Probleme bekommen.

Nein, eigentlich nicht, denn die Default-Werte wurden kopiert. Die Felder bleiben in ihrer derzeitigen Kodierung. Nur Neuanlagen bekommen die neue Kodierung, wenn nichts angegeben wurde.

Also lautet die Lösung:

SET NAMES 'utf8';

als erster Befehl nach Herstellung der Verbindung zur DB in allen neuen Skripten, während die alten nach wie vor ohne Umstellung funktionieren.

Im Prinzip ja, und es gibt keinen praktischen Nachteil, aber nimm doch lieber die dafür vorgesehenen ..._set_charset-Funktionen, statt ein Statement abzusetzen.

dedlfix.