How to fix a CSV whose Japanese text turns into garbage in Excel: re-import it with From Text/CSV, choose UTF-8 or CP932 correctly, and avoid breaking leading zeros and 20-digit order IDs along the way.
Contents (10)
When you open a CSV in Excel, Japanese text can turn into unreadable characters such as "繧" and "縺." This kind of garbled text is often called mojibake. It does not necessarily mean the CSV itself is broken. First make a copy of the original file, then re-import it in Excel with Data > From Text/CSV, specifying the character encoding.
Even when the Japanese displays correctly, though, the import has not succeeded if an order ID like "00123" becomes "123," or a 20-digit identifier is changed by number conversion. This article covers not just fixing the garbled text, but the whole sequence: protecting the original data, column types, and the format you save in for delivery.
Re-import the CSV in Excel: 7 steps
If a file looked garbled when you opened it by double-clicking, do not save it as is. Keep the original CSV and change only how you import it.
- Close the garbled CSV and copy the original CSV under a new name. Do not overwrite it.
- Open a blank workbook in Excel.
- Choose Data > From Text/CSV and select the copied CSV. Depending on your screen, you may go through Get Data > From File.
- In the preview, check File Origin (the character encoding). If the original is UTF-8, choose the equivalent of "65001: Unicode (UTF-8)"; if it is Windows CP932, choose the option for code page 932 (Japanese). The option names vary by environment.
- Once names and product names display correctly, check the Delimiter. Commas are most common, but depending on the source, it could be tabs or semicolons.
- Import order numbers, postal codes, customer IDs, and similar values as text, not numbers. See the section on data types below.
- Check the row count, column count, and IDs in the preview before loading. Save a working copy as an Excel workbook (.xlsx) under a new name.
Microsoft also documents how to open a UTF-8 CSV without a BOM correctly, through Power Query and similar routes. Trying Excel's built-in import before converting the file to Shift_JIS avoids changing the format unnecessarily.
Source: Microsoft Support: Opening CSV UTF-8 files correctly in Excel
If the Japanese in the preview is still garbled
Even if you choose the UTF-8 setting, the original file is not necessarily UTF-8. Look up the encoding used by whatever exported the file, and re-import with the right option. Checking the original CSV in a separate text editor also helps.
If the text is correct but the columns are misaligned, the problem is not the encoding but delimiters, quotes, or line breaks inside cells. Changing the encoding again and again will not fix a structural problem.
Symptoms and where to fix them
| Symptom | Likely cause | Where to fix it |
|---|---|---|
| Japanese turns into characters like "繧" or "譁" | Mismatch between the encoding used to save and the one used to read | Review the encoding setting in Excel's import |
| Japanese is fine but "00123" becomes "123" | Automatic number conversion of the column | Import that column as text in Power Query |
| Long IDs turn into scientific notation and the last digits change | Excel's numeric precision and type detection | Use the text type from the very start of the import |
| Everything ends up in one column, or extra columns appear | How delimiters and quotes are handled | Check the original CSV's structure and the delimiter setting |
| The file itself contains "�" or "?" | Information lost in an earlier wrong conversion or export | Look for the original, the export source, or a backup |
An encoding problem and Excel changing the data type are two separate failures. Even if only the Japanese is fixed, you have not imported the original data correctly if identifier values have changed.
How to keep leading zeros and order IDs of 16+ digits
For example, imagine a CSV with these order IDs:
| Order ID | Product name |
|---|---|
| 00123 | 日本語 |
| 00057 | テスト |
| 12345678901234567890 | サンプル |
An order ID is not a number for calculation; it is an identifier where leading zeros and every digit matter. If Excel interprets it as a number, it may drop the leading zeros or lose precision for numbers longer than 15 digits.
Power Query's Text/CSV connector lets you choose how data types are detected: based on the first 200 rows, based on the entire dataset, or do not detect data types. When your data has identifiers, it is easier to manage if you first import everything as text with "Do not detect data types," then change only the columns you need to numbers or dates afterward.
Once "00123" has already become "123," changing the cell format to Text will not bring the lost leading zeros back automatically. Check the automatic "Changed Type" step under Applied Steps in the Query Editor, and if needed, re-import from the original CSV as text.
Sources: Microsoft Learn: Text/CSV connector / Microsoft Support: Keeping leading zeros and large numbers
Why does UTF-8 still come out garbled?
A CSV is text, but the same characters become different bytes depending on the encoding used to save them. For example, the three characters "日本語" (Japanese for "Japanese language") look like this:
| Encoding used to save | Bytes (hex) |
|---|---|
| UTF-8 | E6 97 A5 E6 9C AC E8 AA 9E |
| Windows CP932 | 93 FA 96 7B 8C EA |
If bytes saved as UTF-8 are read as a different encoding, they may be interpreted as characters other than the original Japanese. Changing the font will not fix a mismatch in the underlying encoding.
Windows CP932 is often called "Shift_JIS" in practice, but it is not exactly the same as standard Shift_JIS. Check first which format the receiving system requires.
What about with or without a BOM?
The UTF-8 BOM is the three bytes "EF BB BF" at the start of a file. The encoding of the text itself is the same as UTF-8 without a BOM, but the BOM gives Excel a clue that the file is UTF-8.
Microsoft says a UTF-8 CSV with a BOM can be opened the normal way. But a missing BOM does not necessarily mean the file is CP932. And if the destination specifies UTF-8 without a BOM, you should not add a BOM just because it makes the file easier to open directly in Excel.
Comparing the same CSV saved three ways
The following is fictional test data with no real customer information. (The Japanese column headers mean Order ID, Product name, and Notes.)
注文ID,商品名,備考
00123,日本語,原本を保護
00057,山田太郎,"東京, 大阪"
12345678901234567890,佐藤花子,20桁の識別子
From the same content, I created four test files: UTF-8 without a BOM, UTF-8 with a BOM, Windows CP932, and a broken example that was misread and then saved again with replacement characters.
| Sample | How it is saved | What to check |
|---|---|---|
| 01_utf8_no_bom.csv | UTF-8, no BOM | Whether the Japanese is readable when UTF-8 is specified |
| 02_utf8_with_bom.csv | UTF-8 with BOM | How the BOM changes detection |
| 03_cp932.csv | Same text encoded as CP932 | What happens when you choose the code page 932 (Japanese) option |
| 04_bad_decode_saved_utf8.csv | UTF-8 misread as CP932, replaced, then saved again as UTF-8 | A contrast showing what lost information looks like |
I generated these samples on October 1, 2026, with the Python standard library and checked the original strings, the BOM, and the bytes of each encoding. This does not mean I measured the results in Excel's interface in each environment. Until a download page is ready on the site, you can copy the contents of the code block to compare.
Checks before saving (for the sample CSV)
| What to check | Correct value | Example of failure |
|---|---|---|
| Product names | 日本語 / 山田太郎 / 佐藤花子 | Characters like 繧 appear |
| Order ID in row 1 | 00123 | Becomes 123 |
| Order ID in row 2 | 00057 | Becomes 57 |
| Order ID in row 3 | 12345678901234567890 | Scientific notation or changed final digits |
| Notes in row 2 | 東京, 大阪 (one cell) | Split into two columns |
| Record count | 3 rows excluding the header, 3 columns | Extra rows or columns appear |
Do not save the broken state back to CSV until everything matches this table. If you are working with your own business data, prepare similar checks for IDs, amounts, dates, notes, and row counts.
If you already saved the garbled version
Whether you can recover depends on whether the original CSV is still there because you only opened it, or whether you converted it to the wrong characters and then overwrote it.
- The original still exists: copy it and re-import it with the right encoding.
- Only the misread text remains: check whether all of the original bytes were preserved. It cannot always be converted back.
- Characters were replaced with "�" or "?": the original information may be lost. Look to the original sender, a fresh download, or a backup.
When the Japanese is correct but the columns are off
The Notes field in the following CSV contains a comma, but because it is enclosed in quotes, it is a single cell when parsed correctly. (The headers mean Product and Notes.)
商品,備考
A,"東京, 大阪"
Processing that treats every comma as a delimiter will break even a valid CSV. Quotes, line breaks inside cells, and doubled quote characters have their own rules, and need to be handled separately from fixing the encoding.
Once it imports correctly, what format should you save in?
| What you will do next | How to think about saving |
|---|---|
| Edit or analyze in Excel | First save as .xlsx under a new name, keeping ID types intact |
| Send a CSV to someone who uses Excel | Check the recipient's environment and whether a BOM is needed |
| Deliver to a web service or business system | Follow the specified encoding, delimiter, and line endings |
| Keep the original for storage and recovery | Store the CSV you received separately from edited versions |
Being readable in Excel is not the same as being in the CSV format the destination requires. And converting everything to Shift_JIS in Excel can lose emoji and some other characters that it cannot represent.
Before handing your CSV to an online fixing tool
If Excel's built-in features fix the problem, there is no need to upload the file to a conversion site. For CSVs that contain customer names, contact details, or transaction information, check how the other service handles your data before handing it over.
General criteria are covered in Files You Shouldn't Upload to Online Tools.
FAQ
Is my CSV broken if it looks garbled when I double-click it?
Not necessarily. Keep the original CSV and choose the right encoding again with From Text/CSV in Excel.
Is UTF-8 with a BOM always the right answer?
It can help when the goal is opening the file directly in Excel, but some systems specify UTF-8 without a BOM. Follow the delivery spec first.
The Japanese is fixed, but the leading zeros in my order numbers disappeared
The likely cause is not the encoding but Excel's automatic data type conversion. Do not just change the display format; re-import the ID column from the original CSV as text.
If I convert to Shift_JIS, will Excel be able to read it?
It may, but if the file contains Unicode characters that cannot be represented, information can be lost. If you only need to read it in Excel, try the built-in import first.
I already overwrote the CSV
First look for where the original data was downloaded from, who sent it, or a backup. If replacement characters were saved, changing the encoding alone may not fully restore it.
Official sources
- Microsoft Support: Opening CSV UTF-8 files correctly in Excel
- Microsoft Learn: Power Query Text/CSV connector
- Microsoft Support: Keeping leading zeros and large numbers
- RFC 4180: Common Format and MIME Type for CSV Files
For garbled CSVs, the basic order is: keep the original → specify the right encoding → check column data types → save under a new name. Make sure not only that the Japanese is readable, but that the contents of the original data are intact.