Why Chinese and Japanese Names Turn Into ???? in Excel — and How to Fix It

You export a list of contacts from a scanner, a CRM or a conference platform, double-click the CSV, and 山田太郎 has become 山田太郎. Or worse: ????. The instinct is to blame the export. Nine times out of ten the export is perfect and the file is intact — what broke is the last three seconds, when Excel decided which alphabet the file was written in and guessed wrong.

Here is what is actually happening, and the fixes in order of how permanently they solve it.

What is mojibake?

Text files do not store characters. They store bytes. An encoding is the lookup table that says which byte sequences mean which characters, and a file carries no reliable label telling you which table was used.

UTF-8 — the modern default — encodes 山 as the three bytes E5 B1 B1. Windows-1252, the Western European legacy table, has no notion of three-byte characters, so it reads those same bytes as three separate Latin characters: å, ±, ±. Repeat across a name and you get 山田太郎.

That is mojibake (文字化け): right bytes, wrong table. The Japanese word is the standard term because Japan hit the problem first and hardest, back when four incompatible Japanese encodings were in daily circulation.

The legacy tables still built into every operating system are the usual wrong answers:

Script	Legacy encoding	Windows code page
Japanese	Shift_JIS	932
Simplified Chinese	GBK / GB18030	936
Traditional Chinese	Big5	950
Korean	EUC-KR	949
Western European	Windows-1252	1252
Everything, correctly	UTF-8	65001

Which wrong table gets applied determines what flavour of nonsense you see. UTF-8 Japanese read as Windows-1252 gives Latin gibberish. The same bytes read as GBK give you plausible-looking but meaningless Chinese: 文字化け comes out as 鏂囧瓧鍖栥亼. That second case is the cruel one, because it looks like real text and passes a quick eyeball check.

Why Excel on Windows is nearly always the culprit

Because of one specific behaviour: when you double-click a .csv, Excel does not ask about encoding. It decodes the file using the system’s ANSI code page — the legacy setting tied to your Windows locale — rather than UTF-8. A machine set to English or German applies Windows-1252. A machine in Japan applies Shift_JIS. Same file, different machines, different garbage.

There is one exception, and it is the whole trick: if the file begins with a UTF-8 byte order mark — the three bytes EF BB BF — Excel recognises it as UTF-8 and decodes correctly. The BOM is invisible in every normal viewer. It is three bytes of metadata that decide whether your Chinese contacts open or break.

This is why the same file behaves differently everywhere. Google Sheets assumes UTF-8 on import. Numbers on macOS defaults to UTF-8 because macOS itself is UTF-8 throughout. Excel on Windows is the holdout that still defers to a locale setting most people have never seen.

Are the characters lost, or just misread?

This is the question that determines whether you spend two minutes or re-do the export. Read the symptom:

What you see	Diagnosis	Recoverable
山田太郎 (accented Latin)	UTF-8 bytes decoded as Windows-1252	Yes — bytes intact
김민준	UTF-8 Korean decoded as Windows-1252	Yes — bytes intact
鏂囧瓧鍖栥亼 (wrong-language CJK)	UTF-8 decoded as GBK or Shift_JIS	Yes — bytes intact
????	Characters converted through a set that cannot hold them	No — re-export
□□□□ empty boxes	Encoding fine; font has no glyphs	Yes — change font

The rule in one line: mojibake is a reading error, question marks are a writing error. Mojibake means someone applied the wrong table to good bytes — reopen the original file with the right encoding and every character returns. Question marks mean someone already re-encoded the text into a character set with no room for CJK, and the encoder substituted ? for each character it could not represent. That substitution is one-way. No amount of reopening brings 山田太郎 back out of ????.

Which means the first thing to do when you see mojibake is stop. Do not save. Do not “fix” cells by hand. Close the file without writing to it, and reopen it properly — because saving is exactly the step that converts a recoverable problem into an unrecoverable one.

How to open a UTF-8 CSV in Excel without breaking it

1. Do not double-click the file. That is the step that hands the decision to your system locale. Open Excel first, with a blank workbook, and leave the file where it is.

2. Go to Data → From Text/CSV. In current versions this may sit under Get Data → From File → From Text/CSV. Select your file. Excel opens a preview dialog rather than loading it blind. (On Excel for Mac the menu wording varies by version — look for File → Import or Data → Get Data; the encoding dropdown is the same idea.)

3. Set File Origin to 65001: Unicode (UTF-8). The preview redraws live as you change it, which makes this self-verifying: when you land on the right encoding, the names snap into correct characters in front of you.

4. Check the delimiter, then fix column types. Confirm the delimiter is Comma. Then use Transform Data to set phone-number and ID columns to Text, or Excel will helpfully strip the leading + from +81 3-1234-5678 and turn long numbers into 8.13123E+11. Click Load.

5. Verify, then save deliberately. Spot-check a few CJK rows. If you need to write the file back out, save as .xlsx, or choose the CSV UTF-8 (Comma delimited) option — never plain CSV (Comma delimited).

That last point deserves its own warning.

Why re-saving from Excel can re-break the file

Excel’s plain “CSV (Comma delimited)” save writes the file in the system ANSI code page — the same legacy table that caused the problem on the way in. Chinese, Japanese and Korean characters have no representation there, so Excel writes ? for each one and, in most versions, warns you with a dialog about features that are not compatible, which everyone clicks through.

The result is a file that is genuinely, permanently damaged. This is the most common way CJK contact data actually dies: not in the export, but in a round trip through a spreadsheet that was saved with the default option.

Use CSV UTF-8 (Comma delimited), which writes UTF-8 with a BOM. It has been in Excel for years and it is the correct default for any file containing non-Latin text.

The faster routes: Sheets, Numbers and a text editor

Three ways to sidestep Excel entirely:

• Google Sheets. File → Import → Upload. Sheets assumes UTF-8 and gets CJK right without any dialog. Also the quickest diagnostic available: if the names look correct in Sheets, the file was always fine and the problem is local.
• Numbers on macOS. Opens UTF-8 CSVs correctly by default. Export back out via File → Export To → CSV, which writes UTF-8.
• A real text editor. VS Code, Sublime, BBEdit and Notepad++ all let you reopen a file with a chosen encoding and re-save it as UTF-8 — the clean way to convert a legacy Shift_JIS or Big5 file once, permanently, before it goes anywhere near a spreadsheet.

To check a file before you trust it, on macOS or Linux run file -I contacts.csv; a Unicode file reports charset=utf-8. For the BOM specifically, head -c 3 contacts.csv | xxd should print efbbbf.

Prevention: fix it at the export, not the import

Every fix above is a workaround for a file that should have been written correctly in the first place. Three rules for exporting contacts that contain CJK names:

• Write UTF-8 with a BOM for anything destined for a spreadsheet. Three bytes remove the entire problem class for Windows users, and every other tool ignores them.
• Never let a pipeline transcode to a legacy code page. Once ? is written, the data is gone.
• Keep the native script and the romanization in separate columns. Then even a badly configured viewer leaves you something readable to work from.

This is the reasoning behind how BizCardPro.AI writes its own files: the spreadsheet CSV export begins with a UTF-8 BOM precisely so that double-clicking it on a Windows machine opens Chinese, Japanese and Korean names correctly, and vCard (.vcf) exports are UTF-8 as well. A good export should not require anyone to learn what a code page is — the full walkthrough of the formats and where each one belongs is in scanning business cards into Excel and Google Contacts.

If a tool you rely on cannot produce a UTF-8 file, that is worth knowing before you build a contact archive inside it. Encoding is not a detail at the edge of the system — for anyone working across scripts, it is the system.