Mojibake: kaputte Umlaute (ä, ö, ü) verstehen und reparieren

Kurz gesagt: Wenn in deinen Daten plötzlich „München" statt „München" oder „Non réponse" statt „Non réponse" steht, ist das Mojibake – Zeichensalat, der entsteht, wenn Text in einer Kodierung gespeichert und in einer anderen gelesen wird. Der häufigste Fall: UTF-8-Bytes werden als Windows-1252/ISO-8859-1 interpretiert. In diesem Artikel erfährst du, warum das passiert, findest eine Übersetzungstabelle der häufigsten kaputten Zeichen, kannst betroffenen Text direkt im Mojibake-Fixer reparieren – und siehst, wie DataLion das Problem beim Datenimport abfängt.

Was ist Mojibake?

Mojibake (japanisch 文字化け, „verwandelte Zeichen") ist der Fachbegriff für Text, der durch eine falsche Zeichenkodierung unlesbar geworden ist. Um zu verstehen, wie aus einem „ä" ein „ä" wird, hilft ein Blick darauf, wie Computer Text speichern: nicht als Buchstaben, sondern als Bytes – Zahlen zwischen 0 und 255. Welcher Buchstabe hinter welcher Zahl steckt, legt die Zeichenkodierung fest. Und davon gibt es mehrere:

• UTF-8 ist heute der Standard im Web und in modernen Tools. Umlaute und Akzente belegen hier zwei Bytes: „ä" ist die Byte-Folge 0xC3 0xA4.
• ISO-8859-1 („Latin-1") und Windows-1252 („ANSI") sind ältere Kodierungen, in denen jedes Zeichen genau ein Byte belegt. Sie stammen aus der Zeit vor UTF-8 und stecken bis heute in vielen Windows-Programmen und Alt-Systemen.

Das Problem: Einer Datei sieht man ihre Kodierung nicht an. Eine CSV-Datei enthält nur Bytes – keine Information darüber, wie sie gemeint sind. Jedes Programm, das die Datei öffnet, muss die Kodierung raten. Und wenn es falsch rät, passiert genau das:

Deshalb ist Mojibake so gut erkennbar: Aus jedem Umlaut werden genau zwei (bei Sonderzeichen wie „€" auch drei) seltsame Zeichen, und das erste davon ist fast immer ein „Ã" oder „â". Wird der kaputte Text erneut falsch gespeichert und gelesen, entsteht doppeltes Mojibake – aus „ä" wird dann „ä".

Die Übersetzungstabelle: ä, ö, ü & Co.

Wenn du diese Zeichenfolgen in deinen Daten siehst, weißt du jetzt, was eigentlich gemeint war:

Zwei verwandte Symptome, die kein klassisches Mojibake sind:

• „M�nchen" mit �-Zeichen: der umgekehrte Fall. Hier wurde Latin-1-Text als UTF-8 gelesen; das Byte 0xFC („ü") ist kein gültiges UTF-8, also setzt das Programm das Ersatzzeichen U+FFFD ein. Die gute Nachricht: Meistens ist die Quelldatei noch intakt – sie muss nur mit der richtigen Kodierung neu eingelesen werden.
• „M?nchen" mit Fragezeichen: das schlechteste Szenario. Irgendein System hat das Zeichen beim Konvertieren durch ein echtes „?" ersetzt. Die Information ist damit unwiederbringlich verloren – kein Tool der Welt kann aus dem „?" wieder ein „ü" machen. Hier hilft nur der Weg zurück zur Originaldatei.

Kaputten Text sofort reparieren: der Mojibake-Fixer

Du hast gerade einen kaputten Wert vor dir – ein Label, eine Antwortoption, eine Adressliste? Füge den Text hier ein. Das Tool macht die falsche Dekodierung rückgängig (auch mehrfach kaputtkodierten Text) und zeigt dir das Original:

Der Fixer eignet sich für einzelne Werte und kurze Listen. Bei einer ganzen Datendatei solltest du das Problem aber nicht per Suchen-und-Ersetzen im Ergebnis bekämpfen, sondern an der Quelle beheben – sonst taucht es beim nächsten Import wieder auf.

Wo Mojibake in der Praxis entsteht

In der Umfrage- und Datenanalyse-Praxis gibt es vier klassische Einfallstore:

1. CSV-Export aus Excel. Der Klassiker. „CSV (Trennzeichen-getrennt)" speichert unter Windows traditionell als Windows-1252 („ANSI"), nicht als UTF-8. Öffnet das nächste Tool die Datei als UTF-8 – oder umgekehrt –, sind alle Umlaute kaputt. Excel selbst zeigt beim Öffnen einer UTF-8-CSV ohne BOM ebenfalls Zeichensalat.
2. SPSS-Dateien aus alten Beständen. Ältere .sav-Dateien wurden im Codepage-Modus (z. B. Windows-1252) geschrieben, moderne im Unicode-Modus. Die Datei deklariert ihre Kodierung zwar im Header – aber nur, wenn das einlesende Tool diese Angabe auch respektiert.
3. Datenbanken und Schnittstellen. Eine MySQL-Verbindung mit latin1-Charset vor einer utf8mb4-Tabelle, eine API, die den charset-Header weglässt, ein Skript, das Dateien mit der System-Locale einliest – jede Übergabe zwischen zwei Systemen ist eine Gelegenheit, falsch zu raten.
4. Copy & Paste über Umwege. Text, der durch mehrere Programme wandert (Mail → Editor → Excel → Upload), kann unterwegs mehrfach um- und fehlkodiert werden – so entsteht das doppelte Mojibake („ä").

Der gemeinsame Nenner: Das Problem entsteht nie beim Anzeigen, sondern immer bei einer Übergabe. Deshalb hilft es auch nichts, im Dashboard-Tool an der Schriftart oder den Einstellungen zu drehen – die Zeichen sind schon beim Einlesen kaputtgegangen.

So reparierst du Mojibake an der Quelle

Die Faustregel: Repariere den Import, nicht das Ergebnis. Konkret:

• Excel: Beim Speichern explizit „CSV UTF-8 (durch Trennzeichen getrennt)" wählen – das gibt es seit Excel 2016. Beim Öffnen einer fremden CSV nicht doppelklicken, sondern über Daten → Aus Text/CSV importieren und den „Dateiursprung" (65001: Unicode UTF-8) explizit setzen.
• Texteditor: Editoren wie Notepad++ oder VS Code zeigen die erkannte Kodierung in der Statusleiste und können Dateien gezielt neu interpretieren („Reinterpret in encoding") oder konvertieren („Convert to UTF-8").
• Kommandozeile: iconv -f WINDOWS-1252 -t UTF-8 alt.csv > neu.csv konvertiert eine Datei in einem Schritt.
• Python: Die Bibliothek ftfy („fixes text for you") repariert bereits kaputtgegangenen Text automatisch – dieselbe Logik, die auch unser Mojibake-Fixer oben nutzt.
• Datenbanken: Verbindungs-Charset und Tabellen-Charset müssen zusammenpassen (bei MySQL: durchgängig utf8mb4).

Wie DataLion Mojibake beim Datenimport verhindert

Die ehrlichste Lösung für das Kodierungsproblem ist die, bei der du dich damit gar nicht beschäftigen musst. Genau so ist der Datenimport in DataLion gebaut: Die Kodierung deiner Datei wird beim Upload erkannt und automatisch nach UTF-8 konvertiert – und ab dort ist die gesamte Pipeline bis in die Datenbank durchgängig UTF-8. Du lädst die Datei hoch, die Umlaute stehen im Dashboard.

• CSV: Eine CSV-Datei kann ihre Kodierung prinzipbedingt nicht selbst deklarieren – deshalb erkennt DataLion sie. Ist die Datei nicht in gültigem UTF-8 kodiert, wird sie als Windows-1252/ISO-8859-1 interpretiert und vor dem Laden konvertiert; UTF-16-Dateien mit BOM werden zu UTF-8 normalisiert, BOM-Marker entfernt. Der klassische Windows-Export aus Excel landet damit genauso sauber im Dashboard wie eine UTF-8-Datei.
• SPSS (.sav): SPSS-Dateien tragen ihre Kodierung im Datei-Header. Der SPSS-Import liest genau diese Angabe aus – auch ältere Codepage-Dateien (z. B. Windows-1252) kommen korrekt an. Umlaute in Variablen- und Wertelabels überstehen den Import.
• Excel (.xlsx): Excel-Arbeitsmappen speichern Text intern als Unicode – hier gibt es schlicht nichts zu raten. Wenn deine Daten ohnehin in Excel liegen, ist die Arbeitsmappe direkt hochzuladen immer der kürzeste Weg: Der Excel-Import umgeht den CSV-Zwischenschritt und damit jede Kodierungsfrage.
• Triple-S: Auch das Umfrage-Austauschformat Triple-S deklariert seine Kodierung in den XML-Metadaten – DataLion hält sich daran.
• REST-API: Beim automatisierten Upload über die REST-API kannst du die Kodierung zusätzlich explizit mitgeben (UTF-8, ISO-8859-1 oder Windows-1252) und die Erkennung damit überstimmen – nützlich, wenn du die Quelle deiner Daten genau kennst.

Dazu kommt die smarte Bereinigung beim Import: Spaltennamen mit Punkten, Leerzeichen oder Sonderzeichen werden automatisch repariert (auto_fix), das Trennzeichen wird selbst erkannt. So wird aus „Datei rein" tatsächlich „Dashboard raus" – ohne dass unterwegs aus „München" ein „München" wird.

Und wenn die Daten schon kaputt bei dir ankommen – weil ein Vorsystem sie längst falsch gespeichert hat? Dann hilft der Mojibake-Fixer oben für einzelne Werte, und für ganze Variablen lassen sich die Labels beim Umkodieren in einem Durchgang korrigieren.

Daten rein, Dashboard raus – mit heilen Umlauten: Lade deine Excel-, SPSS- oder CSV-Datei hoch und prüfe die erste Zeile mit Umlauten gleich im fertigen Dashboard. Excel- & CSV-Import ansehen oder DataLion kostenlos testen.

Checkliste: Umlaute heil durch die Datenpipeline bringen

• Exportiere aus Excel immer als „CSV UTF-8", nie als „CSV (Trennzeichen-getrennt)".
• Prüfe nach jedem Import als Erstes eine Zeile mit Umlauten oder Akzenten – nicht die Zahlenkolonnen.
• Siehst du ä oder –: UTF-8 wurde als Windows-1252 gelesen. Siehst du �: umgekehrt. Siehst du ?: Original besorgen, die Information ist weg.
• Repariere an der Quelle (Export- oder Import-Einstellung), nicht per Suchen-und-Ersetzen im Ergebnis.
• Bewahre die Originaldatei auf, bis der Import geprüft ist.