How to fix mojibake: when UTF-8 text displays as gibberish and how to recover it
Mojibake is always caused by a mismatch between the encoding used to write bytes and the encoding used to read them. Fix it by identifying both encodings and reinterpreting correctly. Prevent it by using UTF-8 everywhere and declaring it explicitly.
Mojibake (Japanese for 'character transformation') is the garbled text you see when bytes written in one encoding are read as another. The classic example: UTF-8 bytes interpreted as Latin-1 produce strings like é instead of é. The data isn't corrupt. It's being misinterpreted. Fixing it means knowing what encoding it was written in and what encoding it's being read as.
By TechCompare · Updated
How this is calculated
Common mojibake scenarios: a MySQL database column was created as latin1 but the application writes UTF-8 bytes into it, a CSV file exported from Excel doesn't include a BOM and is opened as ASCII, or an API response declares charset=ISO-8859-1 but actually returns UTF-8. Recovery depends on whether the bytes were transcoded or just mislabeled. If they were only mislabeled, reinterpret with the correct encoding. If they were double-encoded (UTF-8 bytes treated as Latin-1, then encoded to UTF-8 again), you need to reverse the double-encoding step by step. Prevention is simpler than recovery: always declare UTF-8 explicitly in HTTP headers, HTML meta tags, database schemas, and file formats.
Verdict
Three mislabeling scenarios cause most of the gibberish. A latin1 MySQL column receiving UTF-8 bytes, an Excel CSV exported without a BOM, and an API header lying about its charset. If the bytes were only mislabeled, reinterpret with the right encoding. If they were double-encoded, you have to reverse each layer in order. Prevention wins: declare UTF-8 in HTTP headers, meta tags, and schema definitions.