Problem: Chinese filenames garbled when unzipping Windows-created zips on Linux/WSL (GBK encoding) —— Trove problem library

What you will run into

Zips received from Windows (WinRAR / 360 Compression / Haozip), when extracted on Linux/WSL, show garbled Chinese filenames: the archive was written by a GBK-encoding Windows tool, but unzip assumes UTF-8, so the entry names render as mojibake (see the sample output in the Symptom section).

File contents are fine; only filenames break; UTF-8-flagged zips (compressed on Linux/macOS) are unaffected.

Why this happens

The zip spec leaves filenames without an encoding declaration by default: Windows compression tools (360 Compression, old WinRAR etc.) store filenames in the local codepage GBK/GB2312 without setting the UTF-8 flag;

Linux's unzip decodes with its default charset (CP437) → mojibake.

zip.js#181 is the classic question for this scenario.

The zip spec's filename encoding is a historical legacy: the format does not mandate an encoding declaration; Windows compressor tools write filenames in the local codepage (Chinese locale = GBK/GB2312);

the UTF-8 flag (general purpose bit 11) is a later convention that old tools do not set.

Linux unzip decodes unflagged entries using the default charset (CP437) — GBK bytes interpreted as CP437 turn Chinese into mojibake. The archive is not corrupted; it is a mismatch of "writer encoding (GBK) × reader decoding (CP437)".

Deterministic takeaway: for mojibake filenames, first identify the writer — old archives from Windows = GBK; newer archives from Linux/mac tools = UTF-8 (flag set); extract GBK archives with unzip -O GBK (Info-ZIP supports -O for output charset) or 7z x -mcp=936;

when re-packaging, use tools that set the UTF-8 flag (newer 7-Zip / native zip -r) to avoid the trap; fixed diagnostic: mojibake in a fixed pattern (every character shifted) = encoding mismatch, not genuinely corrupt names.

Step by step

1. Extract with an explicit encoding (most common) — Required

unzip -O GBK 文件.zip

-O sets the DOS/Windows archive encoding; measured supported by Debian unzip 6.00; or unzip -O GB18030 (superset of GBK; some rare characters need it).

2. List first, then extract — Required

unzip -O GBK -l 文件.zip

Confirm filenames look right before the real extraction.

3. Python approach (site docs — Required

zipfile doesn't support encoding specification directly; use unzip -O GBK, or extract then batch-rename with convmv -f GBK -t UTF-8 --notest <dir>/.

4. Root fix on the sender's side — Required

Have the compressor use UTF-8 mode (WinRAR: check "Use UTF-8 for filenames"; Windows 11's built-in zip is already UTF-8), or rename Chinese names to pinyin/English before compressing.

5. GUI tools — Required

7-Zip (Linux p7zip handles GBK names well), KDE Ark, and most file managers auto-detect GBK names.

6. Reverse scenario — Required

Files without the UTF-8 flag that are actually UTF-8 (compressed by old Linux tools): unzip -O UTF-8 fixes in reverse.

How to confirm it works

Filenames display correctly (measured output shape):

unzip -O GBK -l → shows 「测试文件.txt」 (measured)
Actual extraction to disk is also correct (compared via ls, measured)

Reproduction baseline: unzip -l → �����ļ�.txt (mojibake, measured).

Other environments

Symptom

Zips received from Windows (WinRAR/360 Compression/Haozip) extract with garbled Chinese filenames on Linux/WSL:

$ unzip -l file.zip
  Length  Date  Time  Name
       11  2026-08-29  11:48  �����ļ�.txt     # should be 「测试文件.txt」

Key traits: Chinese names at compression time become ����-style replacement chars; file *content* is fine, only names are broken; zips with proper UTF-8 flags (Linux/macOS) are unaffected.

Cause

The zip spec does not declare an encoding for filenames by default: Windows compressors (360 Compression, older WinRAR, etc.) store names in the local codepage (GBK/GB2312) without setting the UTF-8 flag; Linux unzip decodes with its default charset (CP437) → garbage. zip.js#181 is the classic question for this exact scenario (360-compressed files, garbled Chinese names).

Solution

1. Extract with an explicit encoding (most common): unzip -O GBK file.zip (-O sets the DOS/Windows archive charset; verified on Debian unzip 6.00);

or unzip -O GB18030 file.zip (superset of GBK, needed for some rare characters).

1. Inspect first: unzip -O GBK -l file.zip to confirm names are correct before extracting.
2. Python/scripted: zipfile does not decode GBK names directly — use unzip -O GBK, or extract then batch-rename with convmv -f GBK -t UTF-8 --notest dir/.
3. Root fix on the sender side: enable UTF-8 filenames in WinRAR, or use Windows 11's built-in zip (already UTF-8).
4. GUI tools: 7-Zip (p7zip on Linux handles GBK names well), KDE Ark, and most file managers auto-detect GBK names.
5. The reverse case (UTF-8 names with the flag missing, from old Linux tools): unzip -O UTF-8.