上传压缩包后在线解压，文件名变成问号和方块，文件内容却能正常打开——遇到这种情况，先别急着认定文件坏了。多数时候，问题出在文件名的编码在某个处理环节被读错了。文件名乱码和内容损坏是两件事，要分开判断：内容损坏的表现是解压报错、文件打不开、体积异常；文件名乱码则是文件本身完好，只是名字里的中文变成了乱码字符。先把这两类问题分清，排查方向才不会偏。
第一层，看压缩包自身有没有写编码标记。ZIP格式在文件头里有一个通用标志位，其中一位用来表示文件名是否采用UTF-8编码。打包工具写入了这个标记，解压方就应按UTF-8读取；没有写入，解压库只能按本地默认编码去猜。部分工具还会把编码信息写进额外字段，但这类字段并非所有解压库都能识别。核对方法是换一个明确支持编码声明的解压工具打开同一个包：如果文件名正常，说明包内标记存在，问题出在服务端读取环节；如果同样乱码，问题就在打包环节。
第二层，看打包环境。用Windows资源管理器右键压缩，中文文件名常按系统本地编码写入，且不一定设置UTF-8标志位；macOS归档工具和多数命令行压缩工具则默认倾向UTF-8。同一个中文文件名，在不同系统打包出的包，解压结果可能完全不同。让用户说明用什么系统、什么工具打包，往往能快速缩小范围。
第三层，看服务端解压参数。常见解压库默认按系统编码解析文件名，遇到未标记UTF-8的包就会读错。合理的读取顺序是：先读标志位，再读额外字段，两者都没有时按配置的候选编码依次尝试，最后才回退到默认编码。如果代码里直接写死默认编码，或者跳过了标志位判断，乱码就会稳定复现。
第四层，看转存与下载环节。解压后的文件名要写入对象存储的键名、临时目录和下载响应头，任何一处对非ASCII字符处理不当，都可能二次改写文件名。核对时对比解压后内存中的文件名与最终下载得到的文件名，就能判断乱码发生在解压阶段还是转存阶段。
排查清单可以这样用：先用支持编码声明的工具验证包内标记，再确认用户打包环境，然后检查解压库的编码读取顺序，最后比对转存与下载后的文件名。修复建议是：先固定编码声明策略，再统一要求打包规范，最后在上传页补一条提示，引导用户使用会写入UTF-8标记的工具打包。
把编码问题写进验收项，比反复让用户重传更有效。it数运在网站维护中处理这类问题时，按层定位、逐层排除，把文件名编码纳入上传功能的常规检查，减少同类问题重复出现。
