Zeichensatz-Problem

[dedlfix]

Hi!

Immerhin hatte ich ja auch schonmal das Propblem, dass mir PMA die Zeichen in meinem Dump schon beim Einspielen umkodiert und dann noch Collationen angezeigt hat, die ich in MySQL gar nicht konfigueriert hatte.

Der PMA zeigt eine ganze Menge Variablen und andere Dinge vom MySQL-Server an, das ist eine seiner Aufgaben. Darunter sind auch viele Default-Werte zu sehen, die man (logischerweise) nicht selbst eingestellt hat. Sie sind aber vorhanden, auch wenn man sich ihrer nicht bewusst ist.

Beim Arbeiten mit dem PMA kommt beim Thema Kodierungen noch zwei weitere Ebenen hinzu. Außerdem kann er bei Dumps auch noch Umkodierungen vornehmen. Die eine Ebene ist die Kommunikation zwischen PMA und dem Browser. Das läuft in der Regel problemlos über UTF-8. Die andere ist die Kommunikation zwischen ihm und MySQL.

Es ist schon eine Weile her, als ich ihn genauer untersuchte, aber meine Beobachtungen sollte noch gelten. Beim Arbeiten mit Tabellen handelt der PMA mit dem MySQL-Server immer UTF-8 für Lesevorgänge aus (setzt also effektiv den Session-Wert für character_set_results auf utf8). Beim Schreiben handelt er den auf der Startseite bei "MySQL connection collation" (deutsch: "Zeichensatz / Kollation der MySQL-Verbindung") eingestellten Wert aus (betrifft die Session-Werte für character_set_client und character_set_connection). Die eingegebenen Daten schickt er in dieser Kodierung zum Server. Wenn man also Latin1 eingestellt hat und Nicht-Latin1-Zeichen sendet, kann der PMA nur "?" (0x3F) zum Server senden. In dem Fall tritt der Verlust schon im PMA auf. Hat man hingegen utf8 eingestellt und gibt ein Nicht-Latin1-Zeichen für ein Feld ein, das "nur" auf Latin1 steht, dann findet der Verlust im MySQL-Server statt. Dabei kommt auch wieder ein "?" raus, weil es kein (besseres) Zeichen für "Zeichen nicht repräsentierbar" in Latin1 gibt. Am besten lässt man diese Einstellung auf utf8(_general_ci) stehen, auch wenn man selbst nur Latin1 für seine Felder verwendet.

Beim Dump mit dem PMA gilt, dass der Export immer UTF-8-kodiert ist. Es sei denn, man hat die iconv-Extension in PHP eingebunden und dem PMA als RecondingEngine 'iconv' konfiguriert (und AllowAnywhereRecording auf true gestellt). Dann kann man die Kodierung wählen und der PMA nimmt die Umkodierung aus den gelesenen UTF-8-kodierten Daten vor. Beim Import kann man stets eine Zeichenkodierung angeben. Mit AllowAnywhereRecording=true und iconv als RecondingEngine nimmt der PMA die Umkodierung vor. Mit AllowAnywhereRecording=false stellt er nur SET NAMES auf den gewählten Wert. AllowAnywhereRecording beeinflusst auch, welche Kodierungen beim Import zur Auswahl stehen.

Ansonsten hats mich nur ein bischen gewundert, denn normalerweise ist ein Handle, egal ob Filehandle, socket oder DB-Handle nur ein Stück Draht wo am Ende das rauskommt, was am Anfang reingesteckt wurde.

Handles sind nicht das Problem, sondern, wie ich auch in der ersten Antwort schon schrieb:

• Zwischen zwei Systemen muss Klarheit über die zu verwendende Kodierung herrschen.

Nicht der Draht ist ausschlaggebend, sondern dass Sender und Empfänger die gleiche Sprache sprechen. Das erreicht man, indem stillschweigend vom Gleichen ausgegangen wird oder indem explizit festgelegt wird, was man übertragen will.

Lo!