Schei? encoding – MySQL vs. Charsets

Encoding ist ja schon was feines – und vorallem etwas, dass offenbar überall Probleme macht. Alleine um einen Überblick über den heutigen Tag zu geben:

Eventim begrüßt mich mit

Lieber eventim.de-Kunde,

Sie haben sich für den[….]

ein Telekom-Mitarbeiter verabschiedet sich als

J?rgen L[…]

(Ja, die Formatierung ist original aus der Outlook-Mail)

und im gerade eingetroffenen Chatlog sehe ich auch nur ü’s

Aber auch mich hats Heute erwischt: MySQL und Umlaute waren schon immer eine schlechte Idee. Beim Umzug auf den neuen Server wieder der alte K(r)ampf: Sonderzeichen die sich bemühen wirklich sonderbar zu sein. Egal welcher Exportcharset, egal welcher Importcharset – egal ob Konsole oder phpMyAdmin, sinnvolle Sonderzeichen waren der Datenbank nicht zu entlocken. Abhilfe schaffte die Software MySQLDumper, welche mir im SysCP-Chat empfohlen wurde. Dort die UTF8-Datenbank als latin1 exportieren und auf dem neuen Server das selbe File in phpMyAdmin als UTF8 importiert – logisch, oder? Da passt daer MySQL-Ikea-Vergleich der aktuellen Datenschleuder irgendwie…

2 Gedanken zu „Schei? encoding – MySQL vs. Charsets“

  1. Kenn ich.
    CONVERT (CONVERT blub USING BINARY) USING UTF-8
    (oder so ähnlich) hilft da, aber das muss man so erst mal zusammenkriegen ;). das USING BINARY sagt halt übernimm es ASIS und nenn es binary, damit vergisst der Server das eigentliche Encoding, und das USING UTF-8 schreibt das neue Encoding dran, und geht davon aus, dass die binärdaten das haben.

  2. Was habt ihr denn für MySQL-Versionen am laufen?
    Bei mir ging’s bisher immer problemlos. UTF8-MySQL Tabellen auf andere Server problemlos mit phpMyAdmin & gleicher MySQL Version eingespielt. o.O
    Aber wenn mal nicht, dann weiß ich ja nun bescheid, was Abhilfe schafft. 😉

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert