Kodierungs-Konverter & Mojibake-Reparatur

Kurze Antworten

Was ist Mojibake?

// The mistake, in three lines of JavaScript
const bytes = new TextEncoder().encode('测试');   // UTF-8: E6 B5 8B E8 AF 95
new TextDecoder('gbk').decode(bytes);            // '娴嬭瘯'  ← mojibake
new TextDecoder('windows-1252').decode(bytes);   // '测试'  ← same bytes, other mistake

Was dieses Werkzeug leistet

Beispiele im Detail

娴嬭瘯

测试

测试

测试

B2 E2 CA D4

测试

鏁版嵁搴�

(nur teilweise)

So benutzen Sie dieses Werkzeug

1. 1

   Kaputten Text einfügen

   Direkt hineinkopieren — die Kodierung muss vorher nicht bekannt sein. Ein kurzer Ausschnitt genügt; ein Dutzend Zeichen legt die Kette meist schon fest.

2. 2

   Obersten Kandidaten und sein Badge lesen

   Exakt heißt, die Kette führt im Round-Trip exakt zu Ihrer Eingabe zurück. Teilweise heißt, sie tut es nicht — dann ist das Ergebnis nur ein Hinweis.

3. 3

   Kodierungskette prüfen

   Jeder Kandidat zeigt, in welcher Kodierung der Text wirklich geschrieben war und welche ihn falsch gelesen hat. Das sagt Ihnen, was stromaufwärts zu reparieren ist, nicht nur, was dastand.

4. 4

   Bei Bedarf die Bytes ansehen

   Der zweite Abschnitt zeigt beliebigen Text als Bytes in allen gängigen Kodierungen und dekodiert rohes Hex in die andere Richtung. Nützlich für Spaltenbreiten und Protokollrahmen.

Fehler, die es schlimmer machen

iconv -f UTF-8 -t GBK correct.txt > broken.txt

# Zuerst die aktuelle Kodierung bestätigen
file -I correct.txt   # charset=utf-8 → nichts zu konvertieren

ALTER TABLE t MODIFY c VARCHAR(255) CHARACTER SET utf8mb4;

-- Über einen Binärtyp gehen, damit die Bytes erhalten statt neu interpretiert werden
ALTER TABLE t MODIFY c VARBINARY(255);
ALTER TABLE t MODIFY c VARCHAR(255) CHARACTER SET utf8mb4;

// Einfach den ersten Kandidaten nehmen, egal was das Badge sagt
db.update(row.id, candidates[0].text);

// Nur zurückschreiben, was den Round-Trip besteht
if (candidates[0].lossless) db.update(row.id, candidates[0].text);

text = raw.decode('utf-8').encode('gbk').decode('utf-8')

# Einmal an der Grenze dekodieren, mit der Kodierung, die die Datei wirklich verwendet
with open(path, encoding='gbk') as f:
    text = f.read()

Wann Sie das brauchen

Eine Datenbankmigration hat Buchstabensalat erzeugt

Alte MySQL-Tabellen, die als latin1 deklariert sind, tatsächlich aber UTF-8-Bytes enthalten, sind die mit Abstand häufigste Ursache. Fügen Sie eine kaputte Zeile hier ein und bestätigen Sie die echte Kette, bevor Sie das ALTER TABLE schreiben — die Konvertierung in die falsche Richtung macht aus einem behebbaren Problem ein dauerhaftes.

Eine CSV-Datei zeigt in Excel Unsinn

Excel unter Windows nimmt für CSV-Dateien ohne BOM immer noch die Codepage des Systems an, also kommen UTF-8-Exporte als Mojibake an. Bestätigen Sie die Kette hier und exportieren Sie dann erneut mit BOM, oder importieren Sie über den Textassistenten mit explizit gesetzter Kodierung.

Logdateien eines Altsystems

Anwendungen, die gegen GBK oder Shift_JIS gebaut wurden, schreiben ihre Logs in diesen Kodierungen, während moderne Log-Aggregatoren alles als UTF-8 lesen. Fügen Sie eine Zeile ein, um sie wiederherzustellen — und weil nichts hochgeladen wird, geht das auch mit Produktions-Logs.

Dateinamen, die ein ZIP-Archiv zerlegt hat

Das ZIP-Format hat kein Feld für die Kodierung, deshalb tragen Archive von chinesischen oder japanischen Windows-Systemen Dateinamen in GBK oder Shift_JIS, die Unix-Werkzeuge als UTF-8 lesen. Stellen Sie die echten Namen hier wieder her, bevor Sie irgendetwas umbenennen.

Eine Datenbankspalte dimensionieren

Die Byte-Ansicht zeigt denselben Text über alle Kodierungen auf einmal. Ein chinesisches Zeichen belegt in UTF-8 3 Bytes, in GBK aber 2 — genau die Art Unterschied, die aus einem VARCHAR(50) einen Abschneidefehler macht.

Wie Mojibake entsteht

Bytes überleben, Bedeutung nicht

Kodieren bildet Zeichen auf Bytes ab, Dekodieren bildet Bytes zurück. Mojibake ist ein Dekodieren mit der falschen Abbildung. Die Bytes wurden nie beschädigt, und deshalb liefert das rückwärts ausgeführte Fehldekodieren den Originaltext exakt zurück — vorausgesetzt, das Fehldekodieren hat nichts verworfen.

Warum CJK-Text am stärksten leidet

ASCII belegt 0x00–0x7F, und darin sind sich alle gängigen Kodierungen einig, also kommt englischer Text unbeschadet durch. Chinesisch, Japanisch und Koreanisch brauchen Mehrbyte-Sequenzen, und die Kodierungen sind sich über deren Gruppierung uneinig. UTF-8 verwendet drei Bytes pro chinesischem Zeichen, GBK zwei. Füttert man einen GBK-Decoder mit UTF-8-Bytes, verschiebt sich die Gruppierung: Heraus kommt eine andere Anzahl anderer Zeichen.

Die Round-Trip-Prüfung

Für jede Kandidatenkette kodiert das Werkzeug den wiederhergestellten Text erneut mit der ersten Kodierung und dekodiert ihn erneut mit der zweiten. Reproduziert das die Eingabe exakt, erklärt die Kette jedes einzelne Zeichen und der Kandidat gilt als exakt. Kandidaten, die daran scheitern, werden trotzdem angezeigt, denn eine teilweise Wiederherstellung identifiziert den Text oft auch dann, wenn sie ihn nicht reproduzieren kann.

Woher die Kodierungstabellen kommen

Die Tabellen liefert der TextDecoder des Browsers. Die Gegenrichtung ist kniffliger, weil TextEncoder nur UTF-8 beherrscht — deshalb baut das Werkzeug eine Rückabbildung auf, indem es den Byteraum durchläuft und den Decoder nach der Bedeutung jeder Sequenz fragt. Die Abbildung stimmt damit immer mit dem Verhalten Ihres Browsers überein, und es werden keine Nachschlagetabellen an Ihr Gerät ausgeliefert.

Die Ranking-Heuristik und ihre Grenzen

Über die Round-Trip-Prüfung hinaus werden Kandidaten danach bewertet, welcher Anteil des Textes aus häufigen chinesischen Zeichen besteht (jene, deren GBK-Leitbyte in 0xB0–0xF7 liegt), abzüglich Abschlägen für Ersatzzeichen, Halbbreiten-Katakana und Steuerzeichen. Halbbreiten-Katakana ist ein starkes Shift_JIS-Signal, weil normaler japanischer Text sie kaum verwendet. Das ist eine Heuristik: Sie entscheidet Gleichstände, sie stellt keine Wahrheit fest.

So verhindern Sie eine Wiederholung

Die Quelle reparieren, nicht nur die Zeichenkette

Die unter jedem Kandidaten angezeigte Kodierungskette sagt Ihnen, welche Komponente falsch konfiguriert ist. Repariert man nur den Text, ohne Verbindungs-Zeichensatz, Datei-Leser oder Exporteinstellung zu ändern, macht man dasselbe morgen mit frischen Daten noch einmal.

Vor der Konvertierung einer ganzen Datei die Richtung bestätigen

Schicken Sie zuerst eine repräsentative Zeile durch diese Seite. Eine Konvertierung in die falsche Richtung kann Ersatzzeichen erzeugen, und anders als der ursprüngliche Fehler ist dieser Schritt nicht umkehrbar.

Die Kodierung überall explizit setzen

Zeichensatz der Datenbankverbindung, HTTP-Content-Type, Aufrufe zum Öffnen von Dateien, CSV-Exporte. Jede Stelle, die auf „die Kodierung des Systems“ zurückfällt, ist eine Stelle, an der derselbe Fehler zurückkommt, sobald der Code auf einer anderen Maschine läuft.

In MySQL utf8mb4 statt utf8 verwenden

MySQLs utf8 speichert höchstens drei Bytes pro Zeichen, deshalb werden Emoji und einige seltenere chinesische Zeichen stillschweigend abgeschnitten. utf8mb4 ist echtes UTF-8. Das ist ein anderer Fehler als Mojibake, und dieses Werkzeug hilft dabei nicht — diese Bytes sind wirklich weg.

Die Originalbytes behalten, bis die Reparatur geprüft ist

Legen Sie eine Kopie an, bevor Sie irgendetwas konvertieren. Solange die Originalbytes existieren, ist jedes Fehldekodieren umkehrbar — sind sie erst einmal mit Ersatzzeichen überschrieben, holt sie weder diese Seite noch sonst ein Werkzeug zurück.

Häufig gestellte Fragen