Mojibake repair that runs entirely on your device.
Repairs the classic chain UTF‑8 → Windows‑1252 → UTF‑8 (and legacy CJK mis‑decodes). Heuristic, so it refuses to touch text that shows no sign of corruption.
What it does. Almost all mojibake comes from a single mistake: text correctly stored as
UTF-8 (é is the bytes C3 A9) gets read by some program as Windows-1252,
so é renders as é — then the wrong text is re-saved as UTF-8, baking
the damage in. This tool reverses exactly that chain, including text mangled two or three times
over (café), and the same mistake through the legacy CJK code pages: Japanese
garbled via Shift_JIS (東京 → 譚ｱ莠ｬ), Chinese via GBK or Big5, Korean
via EUC-KR.
When you'd use it. Legacy CSV/JSON/SQL dumps where the accents arrived broken, old mail
archives, scraped pages, and log pipelines that keep printing ’ where an
apostrophe belongs.
It refuses clean text. A repair is applied only when it strictly reduces mojibake
evidence, so correctly-encoded prose — café, curly quotes, a lone em dash or euro
sign — is returned verbatim, and running the tool on its own output is a guaranteed no-op. That
caution has a flip side: ambiguous input that no repair provably improves is left alone rather
than guessed at.
Honest limits. It is a heuristic, not a proof: it handles the dominant cp1252 chain and
the four CJK chains above, but corruption from other code pages (KOI8-R, the wider ISO-8859
family, EUC-JP) is out of scope and left untouched. The replacement character �
means a byte was already destroyed upstream — the text around it is still repaired, but the lost
byte is never invented, and such input can never earn the "high" confidence rating (that rating
requires a byte-exact round-trip proof). Repairs deeper than 3 encoding passes stop at the
ceiling and report "medium" honestly. And CJK garble that happens to look like ordinary
ideographs carries no evidence, so it is conservatively left alone.