Why Your CSV Shows é (Mojibake) and How to Fix It

1. What Is Mojibake and Why Does It Happen?

If you have ever exported a customer list from an e-commerce platform or opened a spreadsheet report only to find Café instead of Café, ’ instead of an apostrophe (’), or Montréal instead of Montréal, you have encountered mojibake (pronounced moh-jee-bah-keh).

The word originated from the Japanese phrase 文字化け, which translates to "character transformation" or "character disguise." In computer software, mojibake is not a random glitch: it is the deterministic mathematical result of reading binary data encoded in one character set using an incompatible decoding table.

Unlike modern file formats such as .xlsx or .docx, which wrap XML structures in a zip container and explicitly define character encoding inside an XML declaration, CSV files are plain binary byte streams. A CSV file does not inherently broadcast whether its bytes represent ASCII, UTF-8, Windows-1252, or ISO-8859-1. When an application attempts to open a CSV file without explicit instructions, it must make a guess. If that guess is wrong, readable text turns into garbled symbols.

2. The Byte-Level Math: UTF-8 vs. Windows-1252

To understand why the lowercase accented letter é specifically transforms into é, we need to examine what happens at the binary byte level.

In standard UTF-8, every ASCII character (0 through 127) is stored as a single byte. However, characters beyond standard ASCII, including Western European accented letters, require two or more bytes:

• The letter e (ASCII 101) is stored as single byte 0x65.
• The accented letter é (Unicode code point U+00E9) is encoded in UTF-8 as the two-byte sequence 0xC3 0xA9.

Now consider what happens when a software program—such as Microsoft Excel running in a legacy Windows default configuration—opens that file assuming the single-byte Windows-1252 (ANSI) codepage:

Because Windows-1252 treats every byte as an independent character, a single two-byte UTF-8 glyph is split into two distinct Western European characters. Similarly, a typographical curly apostrophe (’, U+2019), which requires three bytes in UTF-8 (0xE2 0x80 0x99), is decoded by Windows-1252 as three separate characters: â (0xE2), an unprintable control character (0x80), and ™ (0x99), resulting in the common artifact ’.

3. Common Mojibake Strings to Watch For

The table below illustrates the most prevalent mojibake artifacts caused by UTF-8 bytes misinterpreted through Windows-1252 / Latin-1 decoding tables:

4. Manual Fixes in Excel, Google Sheets, and Notepad

If you are working with an individual file on your desktop, here is how you can resolve mojibake using standard applications:

Method A: Microsoft Excel (Import from Text/CSV)

1. Do not double-click the CSV file in Windows Explorer, as Excel will default to system ANSI encoding.
2. Open a blank workbook in Excel.
3. Navigate to the Data tab on the ribbon and click From Text/CSV.
4. Select your file and click Import.
5. In the preview dialog, look at the File Origin dropdown at the top left. Change the selection from Windows (ANSI) to 65001 : Unicode (UTF-8).
6. Observe that accented characters in the preview window return to their correct forms. Click Load.

Method B: Windows Notepad (Save with Encoding)

1. Right-click your CSV file and choose Open with → Notepad.
2. Inspect the status bar at the bottom right. Notepad indicates whether it decoded the file as UTF-8 or ANSI.
3. If the file is already displayed correctly in Notepad, click File → Save As...
4. In the bottom dropdown next to the Save button, select UTF-8 with BOM or UTF-8, and save the file. The BOM header will prompt Excel to recognize UTF-8 automatically upon opening.

Method C: Google Sheets

1. Open Google Sheets and create a blank spreadsheet.
2. Click File → Import, choose the Upload tab, and select your CSV.
3. Google Sheets detects UTF-8 automatically during upload. If the file was already corrupted prior to upload, Google Sheets will retain the corrupted characters, necessitating a repair tool.

Method D: LibreOffice Calc (Text Import Dialog)

LibreOffice Calc provides the most transparent character encoding controls of any mainstream spreadsheet suite:

1. Launch LibreOffice and select Open File, then choose your CSV document.
2. The Text Import dialog opens immediately before the spreadsheet renders.
3. At the top of the dialog, locate the Character set dropdown menu. Change the selection from Western Europe (Windows-1252/WinLatin 1) to Unicode (UTF-8).
4. Examine the live preview grid in the bottom half of the dialog: words like Café will instantly transform back into Café.
5. Click OK to load the repaired data. When saving changes, ensure you select Edit filter settings and verify the character set is set to UTF-8.

5. How to Diagnose and Repair Mojibake in CSVFixKit

When you have a large dataset with thousands of rows, manual find-and-replace across columns is both error-prone and dangerous (e.g. replacing individual characters might accidentally modify unintended substrings).

CSVFixKit provides an automated, non-destructive mojibake diagnostic and repair engine:

1. Drop your CSV file into the CSVFixKit Studio homepage.
2. The client-side worker decodes the file and audits text cells for known mojibake signatures (such as é, ’, Â).
3. If mojibake is identified, CSVFixKit flags the issue under High Risk Issues and calculates the total affected row count.
4. Click Review Issues to inspect a side-by-side preview showing the corrupted original value next to the proposed UTF-8 restoration.
5. CSVFixKit applies reverse byte-mapping: re-encoding the string as Windows-1252 and decoding as strict UTF-8. Crucially, the repair is only accepted if decoding succeeds without replacement characters (U+FFFD), ensuring no data corruption occurs.
6. Approve the repair and download your clean, valid UTF-8 CSV file.

6. Best Practices for Exporting Clean CSVs

To prevent mojibake before it enters your data pipeline:

• Configure CRM and database exports to UTF-8: Ensure that your SQL queries, Python scripts, or SaaS export settings explicitly specify utf-8 encoding.
• Add a UTF-8 BOM for Excel users: If you know non-technical colleagues will open the file directly in Microsoft Excel, include a Byte Order Mark (BOM). Read our companion guide on UTF-8 vs UTF-8 with BOM to understand the trade-offs.
• Validate before importing: Run files through CSVFixKit prior to triggering production database seed scripts or bulk CRM syncs. If your file was exported from multiple CRM systems, consider following our guide to remove duplicate rows from CSV safely to avoid inserting redundant records.

7. Common Mistakes When Handling Mojibake

• Indiscriminate Find-and-Replace: Running a global string replacement for é → é often corrupts other multi-byte sequences. For example, three-byte and four-byte Unicode characters share prefix byte patterns, meaning manual regex replacements frequently break symbols, curly quotes, and emojis.
• Double Re-encoding (Compound Mojibake): Opening a file that already displays é and saving it again as Windows-1252 causes compound mojibake, turning é into é. Each misinterpretation compounds byte layers exponentially.
• Assuming All Accents Use the Same Codepage: Files originating from Eastern Europe (Windows-1250), Russia (Windows-1251), or Greece (Windows-1253) generate completely different replacement artifacts than Western European Windows-1252. Always inspect your byte signatures before guessing.

Frequently Asked Questions

Authoritative Standards & Verified Sources

CSVFixKit relies on standardized file specifications, encoding algorithms, and Unicode Consortium documentation:

• IETF RFC 3629: UTF-8, a transformation format of ISO 10646
• WHATWG Encoding Standard: Technical Multi-Byte Specification
• MDN Web Docs: WHATWG TextDecoder Web API Reference

9. Related Guides