mySQL-Datenbank auf UTF-8 umstellen

Alte WordPress-Datenbanken aus der Zeit vor 2009 enthalten oftmals Texte mit der damals üblichen Latin-1-Kodierung nach ISO 8859-1. Im Zuge eines Updates kann es dann schon mal passieren, dass diese Texte fehlerhaft dargestellt werden. In der Regel sind es die Umlaute und evtl. andere Sonderzeichen, an deren Stelle urplötzlich skurile Zeichenkombinationen erscheinen. Im Internet finden sich diverse Tricks, mit denen WordPress auf Umwegen wieder zur ordnungsgemäßen Darstellung überredet werden kann. Bei mir haben viele davon nichts bewirkt, am Ende war es dieser Kniff, der doch noch Wirkung zeigte. So brauchte ich die Text-Kodierung in der Datenbank selbst erstmal nicht zu ändern, wovor mir als SQL-Laie auch ein wenig graute. Mir wurde aber beim Studium der Zusammenhänge recht deutlich, dass dieser Schritt irgendwann nötig werden würde. Also wollte ich es wenigstens probieren und nach 2-3 Irrwegen gelang es auch ziemlich mühelos … davon berichte ich hier:

Das Problem

Ob die Textfelder selbst Latin-1-kodiert sind, erkennt man nur beim direkten Blick in die Datenbank mit Hilfe eines SQL-Clients. Bei STRATO beispielsweise wählt man auf der Admin-Seite Datenbanken und Webspace > Datenbankverwaltung und kann von dort mittels PhpMyAdmin die Datenbank einsehen. Man sieht dort die voreingestellten Zeichensätze (=Kollationen) der einzelnen Tabellen und Felder, die nicht unbedingt identisch mit der tatsächlichen Kollation der Datenbankeinträge sind. Wenn beipielsweise der Inhalt des Feldes post_content in der Tabelle wp_posts so aussieht wie auf der Abbildung (Hieroglyphen statt der Umlaute), dann ist dieser Inhalt latin-1-kodiert, egal was dort unter Kollation eingetragen ist.

Lösungsansätze, die mich frustriert haben

Natürlich wollte ich bei meinen eher laienhaften Trial-and-Error-Versuchen die Inhalte von teufelsmoor.eu nicht gefährden. Also als Erstes Datenbank als SQL-Dump exportieren und zur Seite legen. Zum Üben schien mir dann eine lokale Installation geeignet, also habe ich mySQL auf meinem Mac installiert und insgesamt drei kostenfreie SQL-Frontends ausprobiert.

• TablePlus ließ sich problemlos installieren und mit mySQL verbinden. Der Import des SQL-Dumps war einfach, danach bin ich verzweifelt. Wenn ich mittels der GUI-Oberfläche den Feldtyp von post_content ändern wollte, bekam ich hartnäckig die Fehlermeldung, dies wäre für post_date nicht zulässig.
• Sequel Pro war ebenso einfach zu installieren, verweigerte aber jegliche Zusammenarbeit mit meinem mySQL unter Verweis auf eine fehlende password…-Datei. Habe ich nicht zum Laufen bekommen.
• Auch die Installation von Valentina Studio war kein Problem, es verband sich auch mühelos mit mySQL. Datenbank-Import fehlerfrei, aber dann ähnliches Problem wie mit TablePlus: Den Feldtyp konnte ich nicht ändern.

Letztlich hätte ich noch zwei drei weitere SQL-Clients ausprobieren können, zum Glück kam mir dann aber die goldrichtige Idee:

So lief’s bei mir

Bei der Suche nach SQL-Clients war mir natürlich wiederholt PhpMyAdmin untergekommen. Es arbeitet aber web-basiert und also fing ich schon an, über die zusätzliche Installation eines Webservers auf dem Mac nachzudenken. Gerade noch rechtzeitig fiel mir dann Strato ein und so ging es ziemlich einfach:

1. Neue Datenbank bei Strato anlegen
2. Dort den SQL-Dump importieren
3. Jede Tabelle einzeln nach Feldern durchsuchen, die latin1-kodiert sind
4. Feldtyp dieses Feld auf Blob ändern (Achtung: bisherigen Feldtyp merken!)
5. Feldtyp wieder ändern zum vorherigen Typ und als Kollation z.B. utf8mb4_general_ci auswählen (bei dieser Aktion schreibt mySQL die Texte dann automatisch UTF8-kodiert)
6. Wenn die betroffenen Felder konvertiert sind, ganze Tabelle auf UTF8 umstellen (unter Operationen>Tabellenaktionen>Kollation mit Häkchen bei „Alle Spaltenkollationen ändern“)
7. Wenn alle Tabellen derart bearbeitet sind: Datenbank als SQL-Dump exportieren und diesen dann in die Original-Datenbank importieren.

Klingt aufwändiger als es ist und lässt sich vollständig mit Hilfe der GUI bewerkstelligen, ich brauchte keinen einzigen SQL-Befehl einzugeben.