09.02.2009, 19:40 Uhr

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…

Tags: , ,

Kommentiere den Artikel oder setze einen Trackback

Bisher 2 Kommentare zum Artikel

  1. Kommentar von ketchupfreak88

    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. ;)

  2. Kommentar von allo

    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.

Kommentiere den Artikel



Kommentare zu diesem Artikel über RSS 2.0-Feed verfolgen