Why ZIP File Names Turn into Garbled Text and How to Fix It - Shift_JIS and UTF-8
The short answer: the two sides disagree about the name encoding
When a ZIP opens and only the Japanese file names come out as strings like "Ä╩É^âè" or "蜀咏悄繝ｪ", the program that made the archive and the program that opened it disagree about how the file names are encoded. The data inside is intact, and reading the names again with the right encoding brings the originals back.
The ZIP specification, APPNOTE.TXT (PKWARE, version 6.3.10, revised November 2022), allows only one bit of the general purpose bit flag to state the encoding of a file name: bit 11. If bit 11 of the general purpose bit flag in an entry's header (the Language encoding flag, or EFS) is set, the name must be UTF-8. That flag arrived with version 6.3.0 in September 2006.
When bit 11 is not set, the specification says the name should follow "the original ZIP character encoding", which is IBM Code Page 437 (CP437, Appendix D). CP437 is the character table of the 1980s IBM PC, and it has no Japanese characters at all. Archives with Japanese names exist in huge numbers anyway because many programs never set the flag and simply wrote the bytes of the PC's own encoding into the name field (on Japanese Windows, cp932, a variant of Shift_JIS). Faced with a name that carries no flag, the program opening the archive can only guess the encoding, and a wrong guess produces garbled text.
There are three ways to deal with it: choose the name encoding again in the program you open it with, rebuild the ZIP with corrected names, or, on the creating side, set the UTF-8 flag or stick to ASCII names. The sections below start with how to read the garbling.
Windows and macOS write names differently
According to Microsoft's "Code Page Identifiers" reference, Japanese Windows uses cp932 (code page 932, named shift_jis in the table). The documentation for Python's zipfile module also notes that some legacy implementations write names in "the current locale encoding or code page", mostly on Windows.
What about macOS? Checked on macOS 26.5 in October 2026, both the built-in ditto command and the bundled zip command (Info-ZIP Zip 3.0) wrote a file called 写真リスト.txt (Japanese for "photo list") as UTF-8 bytes without setting bit 11. The result is a ZIP whose names are UTF-8 with nothing saying so.
How Japanese names are written (checked October 2026):
- ditto on macOS 26.5: names in UTF-8, bit 11 not set
- zip on macOS 26.5 (Zip 3.0): names in UTF-8, bit 11 not set
- zipfile in Python 3.14: names in UTF-8, bit 11 set
- Older Windows software (per the Python documentation): names in the PC's own code page (cp932 for Japanese), bit 11 not set
The list shows the two classic directions of garbling. A cp932 ZIP from Windows garbles in a program that assumes UTF-8, and a flagless UTF-8 ZIP from a Mac garbles in a program that assumes cp932. A clever guess on the opening side avoids the problem, though: the same Mac's ditto extracted a ZIP with cp932 names back to the correct 写真リスト.txt (on a Japanese-language system). Whether names garble depends on the pairing of the tool that made the archive and the tool that opens it.
Linux is no different. The Debian unzip manual (trixie) warns that names with 8-bit characters may not be portable across systems, because tools and platforms use different encodings for them.
Reading the garbling to find the cause
The shape of a garbled name tells you which encoding was misread as which. Here is 写真リスト.txt misread three ways, reproduced with Python 3.14.
| Name you see | Actual encoding | Misread as |
|---|---|---|
Ä╩É^âèâXâg.txt | Shift_JIS (cp932) | CP437 |
蜀咏悄繝ｪ繧ｹ繝�.txt | UTF-8 | Shift_JIS (cp932) |
�ʐ^���X�g.txt | Shift_JIS (cp932) | UTF-8 |
- Accented Latin letters and box-drawing symbols (Ä, É, ╩ and so on): a Shift_JIS name read as CP437, the specification's default. Tools that follow the specification closely, such as Python's zipfile, do this
- Unfamiliar kanji mixed with half-width katakana (繝 and 縺 stand out): a UTF-8 name read as Shift_JIS. This is what you get when a flagless UTF-8 ZIP from a Mac is opened by a tool that assumes cp932. UTF-8 hiragana and katakana are three-byte sequences starting with E3, so read as Shift_JIS they keep producing the same characters such as 繝 and 縺
- Lots of replacement characters (�): a Shift_JIS name read as UTF-8, with the bytes that are not valid UTF-8 thrown away. This form cannot always be reversed, so choosing the encoding again in the tool before extracting is the reliable route
If you extract while the names are garbled, the files are saved under those garbled names. Reopening the original ZIP with the right encoding is faster than renaming afterwards, and nothing slips through.
The fix: reopen it with the right name encoding
The easiest fix is to reopen the archive in a tool that lets you choose the name encoding. The piclab ZIP extractor detects the encoding of Japanese file names in a ZIP automatically, and if they still look wrong you can pick Shift_JIS, GBK or another encoding under the file name encoding setting. Select the files and save them, and you get a ZIP with the names fixed. Everything happens inside the browser, so the files are never sent anywhere.
If Python 3.11 or later is installed, the standard zipfile command can fix it too. According to the Python documentation, --metadata-encoding, added in 3.11, sets the encoding used to read names that carry no flag (it does not affect flagged names, where UTF-8 wins).
python3 -m zipfile --metadata-encoding cp932 -l archive.zip
python3 -m zipfile --metadata-encoding cp932 -e archive.zip out/The first line lists the contents so you can check the names; the second extracts into out/. In October 2026, with a ZIP built with cp932 names, Python 3.14 listed the file as Ä╩É^âèâXâg.txt without the option and as 写真リスト.txt with cp932. If a UTF-8 ZIP from a Mac is the one garbling, use utf-8 instead of cp932.
For a Chinese ZIP choose gbk, for a Korean one cp949, and so on: pick the encoding of the system that made it. If you are not sure, use the table in "Reading the garbling to find the cause" as a guide. For the background of the encoding itself, see the glossary entry Shift JIS.
Prevention: set the UTF-8 flag or use ASCII names
When you build a ZIP for someone whose system you do not know, writing the names in an unambiguous way saves them trouble.
- Create it with the UTF-8 flag: Python's zipfile automatically writes names containing non-ASCII characters as UTF-8 and sets bit 11 (per the documentation and a test in October 2026). A ZIP made with
python3 -m zipfile -c archive.zip 写真リスト.txtcarried the flag. With the flag present, any tool that follows the specification reads UTF-8 without guessing - Use ASCII-only names: name files with characters from the ASCII range only, like
photo-2026-10-01.jpg, and the bytes are the same in every encoding, so nothing garbles. Names built from a date and a number also sort well - Test before sending from a Mac to Windows: as the list in "Windows and macOS write names differently" shows, the standard macOS tools write UTF-8 without the flag. Before sending, check once that the archive opens on a system like the recipient's, or rename to ASCII before compressing
To switch a batch of photos to ASCII names before sending, the steps in bulk image file renaming apply. Advice for the receiving side on a phone is in how to open a password-protected ZIP on a phone.
FAQ: why 7z and RAR rarely garble names
Do 7z and RAR archives garble names too? Rarely. 7-Zip lists Unicode file names among the features of the 7z format, and the RAR 5.0 format description from RARLAB specifies that the name field of a file header is UTF-8. 7z stores names in Unicode and RAR 5.0 archives fix names as UTF-8, so readers never split over a flag the way ZIP readers do.
Is garbled text inside the files (text or CSV) the same problem? No. Appendix D of APPNOTE states that bit 11 says nothing about the encoding of file contents or passwords. A CSV that garbles in Excel after extraction has an encoding issue of its own, so specify the encoding when importing it.
Can a ZIP carry a separate UTF-8 copy of each name? Yes. Appendix D of APPNOTE notes that Ed Gordon of the Info-ZIP group defined a pair of extra field records for UTF-8 names and comments; the name record is Header ID 0x7075, the Info-ZIP Unicode Path Extra Field. It lets an archive keep a name in its original encoding and in UTF-8 without setting bit 11. Support depends on the tool: a ZIP made by ditto on macOS 26.5 in October 2026 did not contain that field.
What if I already extracted with garbled names? If the original ZIP is still around, extracting it again with the method in "The fix: reopen it with the right name encoding" is the reliable fix. If the ZIP is gone, the only option is to rename the files by hand.