Developer

Mojibake

Garbled text like é where é belongs. It happens when bytes saved in one encoding are read as another, most often UTF-8 read as Latin-1 or Windows-1252.

What the garbling looks like

Mojibake follows patterns, and the pattern tells you what went wrong. The most common one is UTF-8 text read as Latin-1 or Windows-1252. Every non-ASCII character turns into two or three odd ones:

  • é is the bytes C3 A9. Read one byte at a time as Latin-1, they show as é.
  • ü is C3 BC, which shows as ü, so für turns into für.
  • £ is C2 A3, which shows as £.
  • ’ is E2 80 99, which shows as ’ in Windows-1252.

Lots of Ã, Â and â in your text means UTF-8 was read as a single byte encoding. The reverse mistake, Latin-1 bytes read as UTF-8, usually gives � (the replacement character U+FFFD), because a lone byte like E9 isn't valid UTF-8.

Where it comes from

The bytes are fine. The reader assumed a different encoding than the writer used. There are three usual causes: nothing says which encoding to use and software guesses, the label is wrong (a file marked ISO 8859-1 that's really Windows-1252 or UTF-8), or several signals disagree, like an HTTP header, a <meta> tag and a byte order mark. When a page declares its encoding in both the header and the HTML, the header wins.

Typical sources are a database column or connection set to latin1 that's fed UTF-8, a CSV file opened in a spreadsheet that guesses the wrong encoding, and a server that sends charset=ISO-8859-1 for UTF-8 files.

Fixing it

Start by naming both encodings: the one the bytes were written in and the one the reader used. If the text was only displayed wrong, nothing is lost. Reopen the file or reload the page with the right encoding.

If the garbled text was saved again, it's double encoded. é saved as UTF-8 is the four bytes C3 83 C2 A9. Undo it by reversing each step: encode the text back to Latin-1 or Windows-1252 bytes, then decode those bytes as UTF-8. If the text already contains �, the original bytes are gone and only the source can bring them back.

Prevention beats repair. Use UTF-8 for files, database columns, connections and APIs, and declare it in the charset=utf-8 part of the Content-Type header and with <meta charset="utf-8">. The Text Encoding Converter shows the hex bytes behind a string, which makes it easy to see whether you're looking at C3 A9 or E9.

Work it out yourselfOpen the Text Encoding Converter

Sources

Back to the glossary