Mojibuster

Umlaute in MySQL und phpMyAdmin reparieren

In phpMyAdmin, im SQL-Dump oder in deiner Anwendung stehen ä oder ? statt ä? Meist passen Tabelle, Verbindung und Import nicht zusammen. Mojibuster repariert Exporte direkt im Browser – danach stellst du MySQL dauerhaft richtig ein.

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

Drei Stellen, an denen MySQL eine Kodierung braucht

  • Spalte bzw. Tabelle: in welchem Zeichensatz die Daten gespeichert sind, etwa utf8mb4 oder latin1.
  • Verbindung: in welchem Zeichensatz Client und Server miteinander reden – gesetzt mit SET NAMES utf8mb4 oder in den Verbindungsdaten.
  • Datei: in welcher Kodierung ein Import gelesen oder ein Export geschrieben wird – in phpMyAdmin unter Zeichencodierung der Datei.

Passen die drei nicht zusammen, gehen Zeichen kaputt. Der häufigste Fall: UTF-8-Text wurde über eine latin1-Verbindung in eine latin1-Spalte geschrieben. In der Anwendung sieht alles richtig aus, in phpMyAdmin und im Export erscheint ä.

Eine Zeile aus einem CSV-Export von phpMyAdmin

Vorher

"1";"Jürgen Müller";"Bäckerstraße 12";"Düsseldorf"

Nachher

"1";"Jürgen Müller";"Bäckerstraße 12";"Düsseldorf"

Zeichensätze prüfen

  • SHOW VARIABLES LIKE 'character_set%'; zeigt die Einstellungen von Server und Verbindung.
  • SHOW CREATE TABLE kunden; zeigt den Zeichensatz der Tabelle und ihrer Spalten.
  • SELECT name, HEX(name) FROM kunden LIMIT 5; zeigt die echten Bytes: In einer utf8mb4-Spalte ist C3A4 ein ä, C383C2A4 dagegen ein schon kaputtes ä.

Export oder Dump reparieren

  1. Exportiere die Tabelle in phpMyAdmin als SQL oder CSV – oder mit mysqldump --default-character-set=utf8mb4.
  2. Zieh die Datei in das Feld oben. Mojibuster repariert nur die kaputten Stellen, korrekte Umlaute bleiben unverändert.
  3. Prüfe unter Was wurde geändert? die reparierten Stellen und lade die Datei herunter.
  4. Importiere sie in eine Tabelle mit utf8mb4 und wähle im Import-Dialog als Zeichencodierung utf-8.
  5. Teste zuerst an einer Kopie, bevor du die echte Tabelle ersetzt.

Der Export verlässt dabei deinen Rechner nicht – wichtig bei Kundendaten. Arbeitest du mit WordPress, beachte die Hinweise zu serialisierten Daten auf der Seite WordPress & Datenbank.

Die Ursache beheben

  • Lege neue Tabellen mit DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci an.
  • Stelle die Verbindung deiner Anwendung auf utf8mb4, in PHP etwa mit charset=utf8mb4 im PDO-DSN.
  • Stehen UTF-8-Bytes in einer latin1-Spalte, wandle sie nicht direkt mit CONVERT TO um – das kodiert sie ein zweites Mal und erzeugt doppelt kodierten Text. Der sichere Weg führt über einen Binärtyp: erst MODIFY name VARBINARY(255), dann MODIFY name VARCHAR(255) CHARACTER SET utf8mb4.
  • Ersetzt MySQL Umlaute durch ?, kann die Spalte oder Verbindung diese Zeichen nicht darstellen. Was schon so gespeichert ist, ist verloren – mehr unter Fragezeichen statt Umlaute.

Häufige Fragen

Warum sieht in meiner Anwendung alles richtig aus, aber in phpMyAdmin nicht?

Weil Anwendung und Datenbank denselben Fehler zweimal machen: Die Anwendung schreibt UTF-8 über eine latin1-Verbindung und liest es genauso zurück. phpMyAdmin verbindet sich korrekt und zeigt deshalb, was wirklich gespeichert ist.

Welche Kollation soll ich nehmen?

utf8mb4_unicode_ci passt für die meisten Anwendungen, ab MySQL 8 ist utf8mb4_0900_ai_ci Standard. Wichtiger ist der Zeichensatz utf8mb4 – nicht utf8, das in MySQL keine Emojis speichern kann.

Funktioniert das auch mit MariaDB?

Ja. MariaDB verhält sich bei Zeichensätzen wie MySQL, die Befehle sind dieselben.

Wie groß darf der Dump sein?

Bis 100 MB pro Datei. Größere Datenbanken exportierst du am besten tabellenweise.

Weitere Anleitungen