Mojibake: understanding and fixing garbled characters (é, ü, –)

In short: If your data suddenly shows "München" instead of "München" or "Non réponse" instead of "Non réponse", you're looking at mojibake – garbled text that appears when data is saved in one character encoding and read in another. The most common case: UTF-8 bytes interpreted as Windows-1252/ISO-8859-1. In this article you'll learn why this happens, find a translation table of the most common garbled characters, repair affected text right here with the mojibake fixer – and see how DataLion catches the problem during data import.

What is mojibake?

Mojibake (Japanese 文字化け, "transformed characters") is the technical term for text made unreadable by a wrong character encoding. To understand how an "é" turns into "é", it helps to look at how computers store text: not as letters, but as bytes – numbers between 0 and 255. Which letter hides behind which number is defined by the character encoding. And there is more than one:

• UTF-8 is today's standard on the web and in modern tools. Accented characters take two bytes here: "é" is the byte sequence 0xC3 0xA9.
• ISO-8859-1 ("Latin-1") and Windows-1252 ("ANSI") are older encodings where every character takes exactly one byte. They predate UTF-8 and still live inside many Windows programs and legacy systems.

The problem: you can't tell a file's encoding by looking at it. A CSV file contains only bytes – no information about how they are meant to be read. Every program that opens the file has to guess the encoding. And when it guesses wrong, this is exactly what happens:

That's why mojibake is so recognizable: every accented character turns into exactly two (for symbols like "€", three) strange characters, and the first one is almost always an "Ã" or "â". If the garbled text is saved and mis-read again, you get double mojibake – "é" then becomes "é".

The translation table: é, ü, – & co.

If you see these character sequences in your data, you now know what was actually meant:

Two related symptoms that are not classic mojibake:

• "M�nchen" with � characters: the reverse case. Latin-1 text was read as UTF-8; the byte 0xFC ("ü") is not valid UTF-8, so the program inserts the replacement character U+FFFD. The good news: the source file is usually still intact – it just needs to be re-read with the right encoding.
• "M?nchen" with question marks: the worst scenario. Some system replaced the character with a literal "?" during conversion. The information is irrecoverably lost – no tool in the world can turn that "?" back into a "ü". The only fix is going back to the original file.

Repair garbled text instantly: the mojibake fixer

Staring at a broken value right now – a label, an answer option, an address list? Paste the text here. The tool reverses the wrong decoding (including multiply mis-encoded text) and shows you the original:

The fixer is great for single values and short lists. For a whole data file, though, don't fight the symptom with find-and-replace – fix it at the source, or it will come right back with the next import.

Where mojibake happens in practice

In survey and data-analysis work there are four classic entry points:

1. CSV exports from Excel. The classic. On Windows, "CSV (comma delimited)" traditionally saves as Windows-1252 ("ANSI"), not UTF-8. If the next tool opens the file as UTF-8 – or vice versa – every accented character breaks. Excel itself shows garbage when opening a UTF-8 CSV without a BOM.
2. SPSS files from old archives. Older .sav files were written in code-page mode (e.g. Windows-1252), modern ones in Unicode mode. The file does declare its encoding in the header – but only if the reading tool actually respects that declaration.
3. Databases and interfaces. A MySQL connection with a latin1 charset in front of a utf8mb4 table, an API that omits the charset header, a script that reads files with the system locale – every hand-off between two systems is an opportunity to guess wrong.
4. Copy & paste detours. Text that travels through several programs (mail → editor → Excel → upload) can be re- and mis-encoded multiple times along the way – that's how double mojibake ("é") is born.

The common denominator: the problem never happens while displaying the data, always during a hand-off. That's why fiddling with fonts or settings in your dashboard tool won't help – the characters were already broken when they were read in.

How to fix mojibake at the source

The rule of thumb: repair the import, not the result. In practice:

• Excel: When saving, explicitly choose "CSV UTF-8 (comma delimited)" – available since Excel 2016. When opening a foreign CSV, don't double-click it; use Data → From Text/CSV and set the "File origin" (65001: Unicode UTF-8) explicitly.
• Text editor: Editors like Notepad++ or VS Code show the detected encoding in the status bar and can re-interpret a file in a specific encoding ("Reinterpret in encoding") or convert it ("Convert to UTF-8").
• Command line: iconv -f WINDOWS-1252 -t UTF-8 old.csv > new.csv converts a file in one step.
• Python: The library ftfy ("fixes text for you") automatically repairs already-broken text – the same logic our mojibake fixer above uses.
• Databases: Connection charset and table charset must match (for MySQL: utf8mb4 end to end).

How DataLion prevents mojibake during data import

The most honest solution to the encoding problem is the one where you never have to think about it. That's how data import in DataLion is built: your file's encoding is detected on upload and converted to UTF-8 automatically – and from there the whole pipeline down to the database is UTF-8 end to end. You upload the file, the accents show up in the dashboard.

• CSV: A CSV file fundamentally cannot declare its own encoding – so DataLion detects it. If the file isn't valid UTF-8, it is interpreted as Windows-1252/ISO-8859-1 and converted before loading; UTF-16 files with a BOM are normalized to UTF-8 and BOM markers are stripped. That classic Windows export from Excel lands in your dashboard just as cleanly as a UTF-8 file.
• SPSS (.sav): SPSS files carry their encoding in the file header. The SPSS import reads exactly that declaration – even older code-page files (e.g. Windows-1252) arrive intact. Umlauts and accents in variable and value labels survive the import.
• Excel (.xlsx): Excel workbooks store text internally as Unicode – there is simply nothing to guess. If your data already lives in Excel, uploading the workbook directly is always the shortest path: the Excel import skips the CSV detour and with it every encoding question.
• Triple-S: The survey interchange format Triple-S declares its encoding in its XML metadata – DataLion honours it.
• REST API: For automated uploads via the REST API you can additionally pass the encoding explicitly (UTF-8, ISO-8859-1 or Windows-1252) and override the detection – useful when you know exactly where your data comes from.

On top of that, smart cleanup runs at import time: column names containing dots, spaces or special characters are repaired automatically (auto_fix), and the delimiter is detected for you. That way "file in" really does become "dashboard out" – without "München" turning into "München" along the way.

And if the data already reaches you broken, because an upstream system saved it wrong long ago? Then the mojibake fixer above handles individual values, and for whole variables you can correct the labels in one pass while recoding.

Data in, dashboard out – with your special characters intact: Upload your Excel, SPSS or CSV file and check the first row with accents right in the finished dashboard. See the Excel & CSV import or try DataLion for free.

Checklist: getting special characters through your data pipeline intact

• Always export from Excel as "CSV UTF-8", never as plain "CSV (comma delimited)".
• After every import, check a row containing accents or umlauts first – not the numeric columns.
• If you see é or –: UTF-8 was read as Windows-1252. If you see �: the reverse. If you see ?: get the original file, the information is gone.
• Fix things at the source (export or import setting), not with find-and-replace on the result.
• Keep the original file until the import has been verified.