Umlaute und MySQL

Von Boris, Fr, 1. Jan 2010 21:04

Still und heimlich hat dreisechzig.net im Sommer sein fünfjähriges Jubliläum gefeiert. Das hat hier jetzt eigentlich gar nichts zu suchen, außer daß dieses Blog “Opfer” einer Umstellung der internen Verwaltung von Character-Encodings bei WordPress wurde. Kurzum hat WordPress seit einigen Versionen “gemogelt” um die Umlaute weiterhin halbwegs korrekt im Browser zu zeigen (aber als Nebeneffekt waren RSS-Feeds so kaputt, daß Umlaute in Itunes beim Podcast falsch angezeigt wurden).

Jetzt wollte ich auf WordPress 2.9 upgraden, was allerdings auch einen Umzug auf MySQL5 bedeutet. Und das wiederum ist bei einem Shared Hoster (dreisechzig.net liegt auf 1&1 Servern) gar nicht mal so einfach. Statt die Datenbank “upzugraden” muß man sie exportieren, eine neue MySQL5 Datenbank anlegen und dort dann die Daten “importieren” (was kein Import sondern eine Folge von Kommandos ist, die die Datenbank neu anlegen). Natürlich kann man einen 20 MByte-Export nicht komplett importieren.

Noch viel schlimmer ist aber, daß die Character Encodings dabei völlig zerhauen werden, insbesondere wenn, wie bei mir, die Quelldaten schon halber Matsch sind mit dem sich WordPress nur so durchgewurstelt hat. Also habe ich geschlagene neun Stunden heute damit verbracht, die Daten zu exportieren, in diversen Text-Editoren die Umlaute zu retten, und dann Stück für Stück wieder zu importieren.

Und geklappt hat es nicht – alle Einträge ab 15. August rückwärts haben immer noch keine korrekten Umlaute und ich krieg ums Verrecken nicht raus, warum. Wahrscheinlich habe ich einen Teil der Dateien nicht mit dem korrekten Encoding gespeichert.

Unter anderem mußte ich nämlich händisch, ja händisch, alle war’s, You’re, isn’t und sei’s (und noch mehr) finden weil ein ‘ (wie es oft in den Texten zu finden war) das Ende des Strings bedeutet und damit natürlich das entsprechende SQL-Kommando invalide macht. Nein, man kann das nicht automatisieren (denn es gibt auch einige Verwendungen von ‘ mit einem Leerzeichen dahinter, die man nicht mit Regular Expressions abfangen kann).

Und weil das alles händisch war kann ich jetzt NICHT nochmal von vorne anfangen weil ich sonst nämlich waaaaaahnsinnig werde.

Sachdienliche Hinweise, wie ich SQL “REPLACE INTO ” Kommandos so umbaue, daß ich existierende Werte überschreiben kann, sind gerne gesehen – dann kann ich in meine händisch edierten SQL-Kommando-Dateien rein, nochmal das Encoding ändern und die Daten in der Datenbank ändern.

Ich beruhige jetzt meine Nerven mit Teil Zwei des privaten Jeff-Goldblum-Filmfestivals. Gestern gab es “Into the Night” heute ist “The Tall Guy” dran. Ob ich allerdings morgen “Earth Girls are Easy” durchstehe, weiß ich nicht.

19 Antworten für “Umlaute und MySQL”

  1. neonoxDE sagt:

    Also, wenn du noch das SQL Dump hast, wo ALLES mit kaputten Umlauten vorhanden ist, dann kann ich dir weiterhelfen.
    Wenn du allerdings nur noch ein Stand hast, mit teilweise repariert und teilweise kaputt, dann wirds hässlich.
    Im letzteren Falle könnte man alle Einträge durch eine (müsste man dann ausprobieren) Kombination aus utf8_encode/utf8_decode php Funktion jagen, vorausgesetzt das wirklich alle vor August vorhandene Einträge kaputt sind.

    • Ich habe das SQL Dump noch, welches dann aber in Teilfiles zerlegt werden muß, weil der 1&1 MySQL Admin nur 2 MByte große Files akzeptiert.

      • neonoxDE sagt:

        Ein weiteres Problem kann sein, wie die MySQL Verbindung eingestellt ist. Du kannst das Charset zur DB festlegen, das kann das Problem lösen.

        Ansonsten, für den Fall das wirklich einzelne Umlaute falsch sind, kann ich dir das reparieren – oder du reparierst es.

        Mein Tipp:
        Per PHP sich einzelne Einträge aus der DB holen und prüfen, wie sie angezeigt werden, dann den header setzen und gucken was passiert. Wenn immer noch falsch (wird der Fall sein), dann durch utf8_decode() senden, falls das nichts bringt, durch utf8_encode() senden. Und wenn du irgendwann weißt, wie es korrekt sein muss, dann mit htmlspecialchars zurück senden in die DB ABER nur, wenn nicht bereits Umlaute im Quellcode gewandelt wurden. Wenn das nämlich der Fall ist, musst du es voher entwandeln und dann wieder wandeln.

        Das ist alles schöööön tricky, aber wenn man weiß wies geht, gehts schnell beheben :-)

        Meine E-Mail Adresse hast du ja.

  2. jot sagt:

    Ich hatte auch schonmal Probleme mit einer uralt-MediaWiki-Version die noch mit veraltetem Encoding lief… diese Anleitung hat mir damals weitergeholfen:
    http://tlug.dnho.net/?q=node/276
    Alle Umlaute haben’s bei mir überlebt ;-)

  3. lx-s sagt:

    Die WordPress eigene Import / Export-Funktion ging nicht?
    Darüber ist es eigentlich sehr bequem Beiträge und kommentare wieder zu importieren.

    WordPress neuinstallieren (dauert ja keine 10 Minuten), dann die zuvor exportierte XML wieder importieren.

    Liegen denn die daten in der alten Datenbank noch vor?

    • Nope, da hier schon 20.000 Kommentare lagern geht das nicht, die Dateien werden zu groß. Aber die alte Datenbank habe ich noch.

      • lx-s sagt:

        Über das mysql.exe tool kann man sehr große Dumps auch direkt einspielen. Das geht besser als das händische splitten im phpMyAdmin.
        Das gleiche Problem hatte ich selbst mal bei meinem Forum, welches auch auf nem Shared-Hoster lag.
        Dazu muss man MySQL lokal installieren und kann das *.sql-Dump dann über die Kommandozeile remote einspielen.
        Die genaue Aufrufsyntax hab ich allerdings nichtmehr im Kopf, sollte sich aber leicht herausfinden lassen.

  4. XeroX sagt:

    Stell doch einfach den Content-Type bzw. Charset deiner Website auf ISO-8859-1. Geht im Header.

    Oder kannst du mal eine Zeile eines REPLACE INTO mit fehlerhaftem Charset posten ?

  5. sirlantis sagt:

    Das kommt mir leider zu bekannt vor. Hab das damals dann auch händisch gemacht – das Wochenende hätte ich mir schöner vorstellen können.

    Zu dem REPLACE INTO würde mir jetzt INSERT [INTO] … ON DUPLICATE KEY UPDATE ( http://dev.mysql.com/doc/refman/5.1/de/insert-on-duplicate.html ) einfallen, also einfach vor das Semikolon noch “ON DUPLICATE KEY UPDATE” setzen. Ich hoffe, dass das hilft.

  6. Sven sagt:

    Hast Du MySqlDumper mal ausprobiert? Damit kann man ganz bequem SQL-Daten sichern und auch wieder einspielen.

    • MontyBurns sagt:

      Dem kann ich mich nur anschließen. Nicht nur dass du dort die Möglichkeit hast beim Backup das Encoding der DB anzugeben und beim Zurückspielen entspr. zu ändern, du kannst damit vor allem jegliche Größen- oder Timeout-Beschränkungen von Hostern und deren Webservern umgehen.

      Ich sichere selbst damit regelmäßig ein mittelgroßes Forum (~110.000 Beiträge) und hab’ im Zuge des Wachsens des Forums auch schon einige DB- und Server-Wechsel/Upgrades problemlos damit durchgeführt. Ich möchte dieses geniale Tool nicht mehr missen.

      Monty

  7. hdgamer sagt:

    Also viel Rat hab ich nicht, aber ich kann dir Ultraedit ans Herz legen (ist denke ich beim 1&1 Softwarepaket dabei) – viele Dinge lassen sich damit besonders komfortabel erledigen (was nicht bedeutet, dass sie nicht immer noch nerven!!).

  8. Kaiser sagt:

    Hatte mal ein ähnliches Problem und habe das mit dem folgen WordPress Plugin gelöst. http://bueltge.de/wp-suchen-und-ersetzen-de-plugin/114/
    Damit konnte ich die falschen Umlaute mit den richtigen ersetzen und das direkt auf der Datenbank. Natürlich wird ein Backup derselbigen im Vorfeld empfohlen.

  9. Ned sagt:

    Hey Boris, mir erging es nach dem Update genau so, wie dir :) Auch meine 10 MB-Datenbank ließ sich nicht automatisch Updaten (1&1 sei Dank …) und ich hatte ebenfalls Sonderzeichenprobleme. Allerdings lässt sich die gesamte Datenbank einlesen, nachdem man sie in einen Editor importiert hat (dort evtl. noch die Sonderzeichen repariert) und anschließend manuell in das SQL-Feld (Befehle) kopiert. Vielleicht ist das für dich ja eine Option.

  10. mindVex sagt:

    Mit welchem Programm hast du denn importiert/exportiert? Meistens machen die damit Blödsinn. Hier kann ich Navicat empfehlen, da gibt’s eine “DataTransfer”-Option, mit der man einfach den Inhalt einer Datenbank kopieren kann, damit hatte ich noch nie Probleme und musste berufsbedingt schon oft Datenbanken mit völlig unterschiedlichen Zeichensätzen rumkopieren. Gibt’s auch als kostenlose Light-Version, weiß aber nicht, ob der “DataTransfer” da mit drin ist.

  11. So, jetzt sollten alle Umlaute am Platz sein. Wenn noch irgendwo was nicht stimmt, bitte einfach Kommentar anhängen oder mail an boris bei dreisechzig.net.

    Der Hauptschurke war im übrigen ein Tip-Fehler, für den ich mich prügeln könnte. In einer Config-Datei stand “UTF-8″ (literal) statt “utf8″ (der Config-Wert). Das brachte alles durcheinander. Als das gefunden war, mußten nur noch die vierzig neuesten Kommentare händisch geändert werden, der Rest paßte dann…

Panorama Theme by Themocracy