ZIP 文件名乱码源于 ZIP 协议默认 CP437 编码与中文系统实际使用 GBK/UTF-8 不匹配；Python 3.11+ 的 metadata_encoding 可指定编码但受限版本与手动预判；手动转码方案最可靠，通过先 CP437 编码再依次尝试 GBK/UTF-8 解码实现跨平台兼容。
zipfile 模块默认用 CP437 解码文件名，而中文 ZIP 包实际用了 GBK 或 UTF-8 —— 编码不匹配直接导致乱码，不是 Python 本身 bug，是 ZIP 协议历史包袱。
ZIP 文件名乱码的根源在协议层
ZIP 格式诞生于 DOS 时代，默认用 CP437（IBM 扩展 ASCII）存文件名，压根没考虑中文。后来 Windows 用 GBK、Linux/macOS/麒麟用 UTF-8，但 ZIP 文件头不强制声明编码，zipfile 只能猜。Python 默认坚持 CP437，一读就错。
Python 3.11+ 的 metadata_encoding 参数真能一键解决？
能，但有硬限制：
- 仅限
Python >= 3.11，旧版本（如 3.8/3.9/3.10）根本不存在这个参数 - 必须提前知道编码：传
metadata_encoding='gbk'才能解 GBK 压缩包，传'utf-8'才能解 UTF-8 压缩包 - 跨平台混合压缩包（比如 Windows 打的包传到麒麟 Linux）无法自动识别，仍需人工判断
手动转码方案为什么最可靠？
它绕过“猜编码”，直接对 zipfile.ZipInfo.filename 字节做二次解码：
立即学习“Python免费学习笔记（深入）”；
- 先用
CP437读出原始字节（zipinfo.filename.encode('cp437')） - 再尝试用
GBK和UTF-8分别解码，哪个能成功且含中文就用哪个 - 兼容所有 Python 版本，Windows / 麒麟 / macOS 全通吃，连带处理嵌套 ZIP 也不卡壳
示例关键逻辑：
raw_bytes = zipinfo.filename.encode('cp437')<br>for enc in ('gbk', 'utf-8', 'utf-8-sig'):<br> try:<br> name = raw_bytes.decode(enc)<br> if '\u4e00' <= name[0] <= '\u9fff': # 中文字符范围<br> zipinfo.filename = name<br> break<br> except UnicodeDecodeError:<br> continue
为什么不要依赖 patoolib 或系统 unzip？
看似省事，实则埋雷：
- 服务器环境常无
7z或unzip，patoolib直接抛OSError: Command not found - 调用外部命令会丢失 Python 的异常上下文，错误定位困难
- 嵌套 ZIP 解压时，子包编码可能和父包不一致，系统工具通常不处理这种细节
- 权限问题：某些容器或沙箱环境禁止执行外部二进制
真正需要稳定交付的自动化脚本，应避免任何外部命令依赖。
乱码修复最易被忽略的一点：ZIP 文件名解码失败后，zipfile 不报错，只是默默生成非法路径（如 ???.txt），导致后续 os.path.join 写入失败或覆盖同名文件——务必在解压前校验 zipinfo.filename 是否为合法中文字符串。
