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…
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.
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. 😉