Für die Umstellung meiner WordPress Datenbank von Latin1 auf UTF-8 habe ich den Weg des bearbeiteten SQL-Dumpes gewählt. Es ist keine Einklick-Lösung. Zwar gibt es auch einige entsprechende Plugins, doch liest man da teilweise widersprüchliches über den Erfolg der Konvertierung und so hab ich auch eine direktere Kontrolle.
Kurz gesagt:
- Datenbanksicherung (SQL-Dump) erstellen
- SQL-Dump im Editor öffnen und CHARSET=latin1 mit utf8 ersetzen
- Sonderzeichen wie ÄäÖ ersetzen
- Bearbeiteten SQL-Dump speichern (utf-8) und wieder einspielen
- UTF-8 in der WordPresskonfig aktivieren
Bevor ihr anfangt an der Datenbank herumzuwerkeln, hebt eine Sicherung auf, um jederzeit wieder zu Eurem alten Datenbankstand zurückkehren zu können, denn ich übernehme natürlich keine Verantwortung, dass meine Anleitung der Weisheit letzter Schluss ist. Mit SQL-Dump meine ich eine Datenbanksicherung als SQL-Statements. So, nun aber ab zu meiner Herangehensweise:
1. Datenbanksicherung (SQL-Dump)er stellen
Eine Sicherung Eurer Datenbank erstellen, sei es per Terminalbefehl mysqldump oder Tools wie PHPMyAdmin oder was auch immer.
$ mysqldump DATENBANK -u USER --password=XXXX > dump.sql
2. dump.sql im Editor öffnen
Nun die erstellte Datenbanksicherung in einem Editor Eurer Wahl, welcher die Funktionalität des Suchen&Ersetzens und speichern als UTF-8 beherrscht, öffnen. Sollte der SQL-Dump zu groß sein, muss er notfalls in einzelne Teile für die Bearbeitung zerlegt werden. Vim kam mit einem ca. 10MB großen SQL-Dumpfile noch relativ gut klar.
3. Tabellen CHARSET auf UTF-8 setzen
Nun werden in allen zur WordPress gehörigen Tabellen in den CREATE Statements die Angabe von CHARSET=latin1 mit CHARSET=utf8 ersetzt. Für den Editor vim würde der Aufruf so lauten:
:%s/CHARSET=latin1/CHARSET=utf8/g
4. Sonderzeichen und Umlaute in UTF-8 umwandeln
Der Weg des Ersetzens über die Datenbanksicherung hat nur einen kleinen Nachteil, das nun alle Sonderzeichen noch ebenfalls ersetzt werden müssen. Bei mir hielt es sich in Grenzen und betraf fast nur ÄäÖöÜöß und ein paar Ausnahmen wie éèá. Ich war mit ca. 10 Ersetzungsaufrufen durch. Was man jetzt noch übersehen hat, kann man auch später noch ersetzen oder sucht noch gezielter nach noch nicht konvertierten Sonderzeichen. Im Vim hab ich den bekannten Aufruf pro Zeichen wieder verwendet, wobei ?? den nicht korrekt dargestellen Zeichensatzcode enthalten soll:
:%s/??/Ä/g
Mein erster Versuch des direkten Konvertierens der dump.sql funktionierte mit iconv nicht so recht, so dass mich der folgende Aufruf nicht ans Ziel brachte und ich wie eben erwähnt die Zeichen einzeln im Editor ersetzen lassen habe.
$ iconv -f latin1 -t utf-f dump.sql > dump_utf8.sql
War wohl ein zu Blauäugiges herangehen ohne das Charset der Shell zu beachten.
5. modifizierte Datenbanksicherung zurück spielen
Jetzt muss nur noch die angepasste Datenbanksicherung als UTF-8 gespeichert und wieder eingespielt werden:
$ mysql DATENBANK -u USER --password=XXXX < dump.sql
UTF-8 in der Konfigdatei von WordPress
Zum Schluss erfolgt noch die Anpassung der Konfigurationsdatei von WordPress:
define('DB_CHARSET', 'utf8');
Ein Aufruf Eures Blogs dürfte nun keine Veränderung zu vorher zeigen, aber die Datenbank speichert nun als UTF-8 statt Latin1
Eigentlich sollten es nur 5 kleine Anstriche werden, aber die Erklärungen blähen es größer auf als es eigentlich war.
Ok, damit steht fest, dass ich diese Konvertierung nicht machen werden.
Danke für die Anleitung.
Ja ich verstehe dich voll und ganz, die Anleitung würde mich auch abschrecken. Glücklicherweise hatte ich erst die Konvertierung zu UTF-8 vollzogen und danach die Anleitung geschrieben
Den Dump kann man sehr einfach mit Ultraedit ( gibt es als Evaluation
) nach utf-8 konvertieren und anschließend in Mysql importieren. Ich beschäftige mich auch gerade mit dem Thema und es sind doch ein paar Sonderzeichen mehr, als die Umlaute die man auf jeden Fall anfasssen muss.
Ja, die Umlaute waren oben nur beispielhaft genannt. Danke für den Tipp mit UltraEdit, für Windows Nutzer ist dies natürlich eine Erleichterung.
[…] anzuzeigen stand ich nach meinem Server-Crash vor einem Problem. Was tun? Sämtliche Blogs in mühevoller Kleinstarbeit über die Konsole zu dumpen, umwandeln, einspielen und dann hoffen das alles […]
[…] Der erste Schritt war die konvertierung der Datenbank von latin1 in utf8. Mit Hilfe des Artikels WordPress Datenbank Latin1 zu UTF-8 Konvertierung auf Tigions Blog und einer Liste der Umlaute latin1 und […]
[…] und Ersetzen-Plugin von Frank Bueltge). Einen wesentlichen Hinweis hab ich dann noch im Posting «Wordpress Datenbank Latin1 zu UTF-8 Konvertierung» gefunden, nämlich das in der wp-config.php die Zeile define(’DB_CHARSET’, […]
Das Konvertieren der Umlaute und des ‚ß‘ kann die Software Notepad++ mit einem Klick:
– sql-Datei im ANSI-Format öffnen oder kopieren und einfügen (unter Menüpunkt ‚Format‘ ist ANSI einstellbar)
– Dann Format auf ‚UTF8‘ klicken
Fertig.
Danke für den Hinweis pantoffelpunk, ich hatte damals nur eine Konsole auf dem Server mit vim zur Verfügung. Deine Variante ist da natürlich ungemein praktischer.
mit größeren Datenbanken ist der Notepad und der Ultraedit etwas unhandlich, wäre froh eine Konsole mit vim zu haben. Kann auch nicht sagen ob das vom Windows so auf einen Suse Server zu übertragen ist.
Notepad bietet wohl die Konvertierung in Unix UTF-8.
Habe php kennt einer eine php Konvertierungs Version oder eine php class. Habe mal versucht eine php class zu entwickeln aber das dauert wohl etwas länger.
@t-admin: Wenn du einen Suse Server hast, ist doch sicher vi oder sogar vim installiert oder ist es ein Windows Server?
Generell kannst du ja die Datenbanksicherung unter jedem Betriebssystem umwandeln, muss ja nicht direkt auf dem Server geschehen.
Ist ein Suse Server, aber derzeit habe ich keine Konsole. Vi oder vim wird wohl installiert sein. Einfacher wäre wohl die Umwandlung auf dem Server weil einfach der download und upload keine Zeit kostet. Zudem brauche ich nicht ein gzip auf dem Windows Rechner zu entpacken.
Ich werde mal schauen ob ich aus dem php heraus den vi oder vim starten kann.
@t-admin: Wenn es sich nur um einen Datenbank handelt, dürfte der Down- und Upload ja nicht weiter ins Gewicht fallen. Persönlich kann ich die OpenSource Software 7-Zip empfehlen, deckt man doch so eine breite Palette an Packformaten ab.
Wie gesagt, dass das Suchen und Ersetzen ist nur eine etwas aufwendigere Variante.
Waren die Daten, die in Deiner ursprünglichen latin1-Datenbank gespeichert waren, eigentlich definitiv latin1-kodiert, oder waren sie eigentlich bereits utf8-Daten?
Bei meiner Migration von MySql4.0 zu 5.0 hatte ich nämlich festgestellt, dass ich in der 4.0-Datenbank bereits utf8-kodierte WordPress-Daten gespeichert hatte. Ein Import dieses Dumps in eine 5.0-Datenbank (default auf utf8 gesetzt) bewirkte die bekannte „Sonderzeichenproblem“. Grund: die utf8-Daten wurden über eine latin1-Verbindung beim Import importiert. Dieses ließ sich mit einem zusätzlichen Statement „set names utf-8“ im Dump beheben, so dass anschließend die Daten korrekt und problemlos in die 5.0 DB importiert werden konnten.
Thorsten
Ich würde sagen ja, also dass sie latin1 waren. Für die Details ist es aber mittlerweile zu lange her.