中文文件名 zip 三次上传失败，改成英文名一次成功：openJiuwen 提交踩坑复盘

今天在提交 openJiuwen 的时候，遇到一个看似玄学、实则有明确规范依据的问题：一个中文文件名的 zip 包，三次上传全部失败；把文件名改成英文后，其他什么都没改，一次就成功了。把完整经过和排查思路记录下来，希望能帮后来人少踩一次坑。

一、发生了什么

今天提交 openJiuwen，需要把项目打成 zip 包上传。第一次打包时，压缩包文件名用了中文，点上传，失败；以为是偶发问题，又重试了两次，结果一模一样——三次全部失败。

换了个思路：把 zip 文件名改成纯英文，其他什么都不改，再传一次，立刻成功。

三次失败、一次成功，唯一变的量就是文件名里的中文。

二、排查过程

一开始也怀疑过几个常见原因：

1. 网络问题：但同一网络下其他操作都正常，而且失败可以稳定复现三次，不像网络抖动；
2. 文件损坏或过大：zip 包体不大，本地解压验证完好，排除；
3. 浏览器或缓存：重试、等一会儿再传都没有变化。

排除下来，问题就锁定在“文件名”上，具体说是文件名里的中文字符在上传、解压链路上的编码处理。

三、查到的命名规范原文

顺着这个方向查，找到了华为云对象存储服务（OBS）“在线解压”功能文档里的说明，原文如下：

如果 ZIP 包中包含非 UTF-8 或 GB 2312 编码的文件名或文件夹（文件目录）名，可能导致解压生成文件的文件名或文件目录名出现乱码、解压过程中断等情况，请使用 UTF-8 或 GB 2312 编码命名您的文件。

也就是说，平台侧对压缩包内文件名的编码是有明确要求的，超出 UTF-8 / GB 2312 范围的命名，可能直接导致解压流程中断。中文文件名本身不是原罪，关键是它在打包、传输、解压整条链路里用的是什么编码——一旦某个环节按非预期编码解析，就会出问题。

另外补充一点排查经验：Python 的 zipfile、Windows 资源管理器内置解压，以及不同系统默认的文件名编码并不一致，跨平台打包时最容易在这里踩坑。稳妥的做法是：

• 对外提交的文件名优先用英文、数字、下划线和连字符；
• 必须用中文文件名时，先确认打包工具写的是 UTF-8 编码；
• 上传前先在目标环境解压验证一次。

四、结论

• 上传失败不一定是网络或文件问题，先看文件名。
• 中文文件名 zip 三次失败、改英文名一次成功，根因大概率在编码与平台命名规范。
• 对外提交文件时，英文命名是最省事的默认选择。