Problem
How to Fix Garbled Characters in a CSV (é and Friends)
Café is showing as Café. Every apostrophe is ’. The file is not corrupt — it is being
read with the wrong alphabet.
The short answer
Read the file with the encoding it was actually written in, then write a copy Excel will open correctly. In DataTray, open the file in Data Explorer or Clean & Anonymize: the detected encoding is shown on screen and can be overridden, with a live preview. Export as UTF-8 with a BOM, which is what Excel on Windows needs.
What is actually happening
Text on disk is bytes. An encoding is the agreement about which bytes mean which characters.
In UTF-8, é is stored as two bytes: C3 A9. In Windows-1252 — the old single-byte Western
encoding Excel reaches for by default — C3 is à and A9 is ©. A reader using the wrong
agreement therefore shows you é, faithfully, from completely intact data.
This class of garbling has a name, mojibake, and its signature is telling: accented letters
become exactly two odd characters, and the first one is very often à or â.
The BOM, and why Excel needs it
A byte-order mark is three bytes (EF BB BF) at the very start of a file that say "this is
UTF-8".
Excel on Windows will not assume UTF-8 without it. A perfectly correct, spec-clean, BOM-less UTF-8 CSV opens in Excel with every accent mangled — and the user blames the tool that produced it, not Excel. This is why DataTray writes CSV with a BOM by default and says so in words on the panel rather than hiding it behind an Advanced toggle.
The opposite is true for JSON, NDJSON and Parquet: a BOM there is malformed, not helpful, so DataTray never writes one for those.
Fixing a file you were sent
- Open it and set the input encoding — UTF-8 if you see the
épattern, Windows-1252 or Latin-1 if you see?or empty boxes where accents should be. - Check the preview. The right encoding is obvious the moment you pick it; the names go back to being names.
- Export a clean copy as UTF-8 with a BOM.
If the preview never looks right in any encoding, the file was probably opened and re-saved by something that already destroyed the original bytes. At that point the fix is upstream — request a fresh export.
The one that is not recoverable
If a file was read as Windows-1252 and then saved as UTF-8, the mojibake is now genuinely in
the data: é has been written out as two real characters. It can sometimes be undone with a
find-and-replace over the known pairs, and DataTray's Clean & Anonymize will do that, but it is
patching symptoms. Getting the file again is better whenever it is possible.
Catch it before it spreads
Clean & Anonymize flags mojibake as a finding, with a count of affected rows, when it scans a file — alongside the other encoding-adjacent problems that travel with it: stray whitespace, inconsistent casing, and numbers stored as text. Fixing all of them in one pass is a minute's work, and it is the difference between a file you can trust and one that keeps surprising people downstream.
Every other free way to do this asks you to upload the file first — and an encoding problem is usually discovered on a file full of real customer names.
Do this in one pass with — Clean & Anonymize
Trailing whitespace, dates in four formats, numbers stored as text, the leading zeros that vanished, encoding that turned é into é. DataTray finds them without being asked and fixes them in one previewable stack of operations — and in the same pass it finds the personal data, so you can mask, hash or tokenize it before the file goes anywhere. Every finding is a deterministic rule over the column, explainable in one sentence. No model, no API key, nothing uploaded. Learn more about the Clean & Anonymize.
Windows 10/11 (x64) · Free · No account