Mojibuster

WordPress und Datenbank-Export: ä ö ü statt ä ö ü

Nach einem Umzug, Update oder Datenbank-Export steht in Beiträgen plötzlich ä statt ä? Die Daten sind fast immer noch da – sie werden nur mit der falschen Kodierung gelesen. Mojibuster repariert den Export, danach behebst du die Ursache in der Datenbank.

Funktioniert mit Text und diesen Dateien:

  • CSV
  • TXT
  • JSON
  • XML
  • SRT
  • VTT
  • TSV
  • MD
  • HTML
  • SQL
  • LOG

Zum Beispiel Excel-Exporte, Datenbank-Dumps, Untertitel oder Website-Code.

Reparieren

  1. Datei ablegen oder Text einfügen
  2. Wird automatisch repariert
  3. Kopieren oder herunterladen
oder Datei einfach hierher ziehen

So sieht das Problem aus

Eine Zeile aus einem SQL-Dump nach dem Umzug

Vorher

INSERT INTO wp_posts (post_title) VALUES ('Größere Übersicht für Käufer');

Nachher

INSERT INTO wp_posts (post_title) VALUES ('Größere Übersicht für Käufer');

Woher kommt das?

WordPress speichert Texte als UTF-8. Viele ältere Installationen haben ihre Tabellen aber als latin1 angelegt oder sich mit latin1 verbunden. Solange Schreiben und Lesen denselben Fehler machen, fällt das nicht auf. Beim Umzug auf einen neuen Server, beim Export mit phpMyAdmin oder nach einem Wechsel der Verbindungskodierung wird aus jedem Umlaut plötzlich zwei Zeichen.

  • In wp-config.php steht DB_CHARSET auf latin1 oder ein anderer Wert als die Tabellen.
  • Der Dump wurde mit latin1 exportiert und mit utf8mb4 importiert – oder umgekehrt.
  • Ein Plugin oder Import-Skript hat bereits kaputten Text noch einmal umgewandelt. Dann entsteht doppelt kodierter Text wie ä.

Den Export reparieren

  1. Erstelle eine Sicherung der Datenbank – bevor du irgendetwas änderst.
  2. Exportiere die betroffenen Tabellen als .sql-Datei, zum Beispiel mit phpMyAdmin oder mysqldump --default-character-set=utf8mb4.
  3. Zieh die Datei in das Feld oben. Mojibuster repariert nur die kaputten Stellen und zeigt dir jede Änderung.
  4. Lade die reparierte Datei herunter und importiere sie mit utf8mb4 in eine frisch angelegte Test-Datenbank.
  5. Prüfe die Seite. Passt alles, spielst du den Import in die echte Datenbank ein.

Der Dump wird dabei nicht hochgeladen – wichtig, weil er oft Nutzerkonten, E-Mail-Adressen und Kommentare enthält. Mehr dazu auf der Seite für Unternehmen & Datenschutzbeauftragte.

Vorsicht bei serialisierten Daten

WordPress speichert Einstellungen in wp_options und wp_postmeta teils als serialisierte PHP-Werte, etwa s:5:"Käse";. Die Zahl ist die Länge in Bytes. Wird aus ä wieder ä, stimmt sie nicht mehr, und WordPress verwirft den Wert. Repariere deshalb vor allem Inhaltstabellen wie wp_posts, wp_comments und wp_terms. Für Optionen ist wp search-replace aus WP-CLI besser geeignet, weil es die Längen anpasst.

Die Ursache in MySQL beheben

  • Stelle Tabellen und Verbindung auf utf8mb4 um und setze in wp-config.php define('DB_CHARSET', 'utf8mb4');.
  • Stehen UTF-8-Bytes in einer latin1-Spalte, wandle sie nicht direkt um – das würde sie ein zweites Mal kodieren. Der übliche Weg führt über einen Binärtyp: erst MODIFY … LONGBLOB, dann MODIFY … LONGTEXT CHARACTER SET utf8mb4.
  • Teste jede Umstellung zuerst an einer Kopie der Datenbank.

Häufige Fragen

Kann ich eine ganze WordPress-Datenbank auf einmal reparieren?

Ja, auch große SQL-Dumps. Beachte aber serialisierte Daten in wp_options und wp_postmeta – sie repariert WP-CLI besser.

Werden korrekte Umlaute im Dump verändert?

Nein. Mojibuster repariert nur Zeichenfolgen, die eindeutig kaputt sind. Korrekter Text bleibt, wie er ist.

Was ist der Unterschied zwischen utf8 und utf8mb4?

utf8 speichert in MySQL nur Zeichen bis drei Bytes, Emojis fehlen dann. utf8mb4 ist echtes UTF-8 und die richtige Wahl für WordPress.

Geht das auch mit anderen Systemen als WordPress?

Ja. Das Problem und die Lösung sind bei Joomla, Shopware, TYPO3 oder eigenen Anwendungen mit MySQL oder MariaDB dieselben.

Weitere Anleitungen