zipfile默认用cp437解码是因ZIP协议历史限制：flag第11位未置1时强制回退cp437，而Windows多用GBK写入却不设flag，Linux/macOS多用UTF-8但也不总设flag，导致编码错配；Python 3.11+的metadata_encoding可强制指定解码，但受限于版本、需预知真实编码且无法处理跨平台混合包；手动转码方案更可靠——先cp437还原原始字节，再依次尝试gbk/utf-8/utf-8-sig解码并校验中文字符范围，实现自动识别与兼容。
zipfile 模块默认用 cp437 解码文件名，而中文 ZIP 包实际用了 gbk 或 utf-8 —— 编码不匹配直接导致乱码，不是 Python 本身 bug，是 ZIP 协议的历史包袱。
为什么 zipfile 默认坚持 cp437
ZIP 格式诞生于 DOS 时代，文件名字段没预留编码标识位，只约定“若 flag 第 11 位为 1，则按 utf-8；否则一律按 cp437”。Windows 压缩工具（如系统自带、Bandizip）多数不设 flag，直接用 gbk 写入字节；Linux/macOS/麒麟下的 zip 命令默认走 utf-8，但也不总设 flag。结果就是：zipfile 看不到 flag，只能硬解 cp437，一读就错。
metadata_encoding 参数在 Python 3.11+ 中怎么用、有哪些坑
它确实能绕过 flag 判断，强制指定文件名解码方式，但有三个硬限制：
- 仅 Python >= 3.11 可用，
3.8/3.9/3.10版本根本不存在该参数 - 必须提前知道压缩包真实编码：传
metadata_encoding='gbk'才能解 Windows 打的包，传'utf-8'才能解 Linux 打的包 - 跨平台混合包（比如 Windows 打完传到麒麟服务器）无法自动识别，仍需人工判断或 fallback
手动转码方案为什么更可靠
它不依赖 flag，也不赌版本，而是对 zipinfo.filename 字节做二次解码：
- 先用
cp437把乱码字符串“还原”回原始字节：raw_bytes = zipinfo.filename.encode('cp437') - 再依次尝试
gbk、utf-8、utf-8-sig解码，哪个能成功且首字符落在中文 Unicode 范围（'\u4e00' ）就用哪个 - 全程不调外部命令，不改系统设置，Python 3.6+ 全版本通吃，嵌套 ZIP 也能递归处理
为什么不要用 patoolib 或系统 unzip
看似省事，实则引入不可控变量：
立即学习“Python免费学习笔记（深入）”；
- 服务器常无
7z或unzip，patoolib直接抛OSError: Command not found - 异常堆栈被截断，错误定位困难；嵌套 ZIP 的子包可能和父包编码不一致，系统工具通常不处理这种细节
- 容器/沙箱环境常禁用
subprocess，权限失败时连报错都看不到
zipfile 解码失败后不会报错，只是默默生成含问号或 的文件名——你得主动检查 zipinfo.filename 是否含非 ASCII 字符，否则问题会静默传递到后续流程。 
