有用户反馈，把一份GZ压缩包上传到网站后台在线解压，文件内容打开都正常，但文件名里的中文全变成了问号或一串看不懂的字符。重新上传一次，结果依旧。这种情况通常不是文件坏了，而是文件名在传递过程中经历了多次编码转换，某一层没有对上。要定位问题，可以按下面几层依次核对。
第一层，先看压缩包是在什么环境下生成的。GZ本身只是压缩流，真正承载文件名信息的是它内部的打包结构。如果打包时使用的系统区域设置与文件名实际编码不一致，比如在一种默认编码环境下打包了另一种编码命名的文件，那么在源头文件名就已经带着不确定的编码信息。核对方法是回到打包的那台机器，确认打包工具的版本、系统语言设置，以及打包时文件名是否包含生僻字、空格或特殊符号。可以先用几个纯中文的简单文件名做一次小样本打包，排除个别字符干扰。
第二层，看在线解压服务读取文件名时采用的编码假设。不同解压程序对文件名编码的默认判断并不一致，有的按系统默认编码读取，有的按压缩包内记录的标志位判断。当压缩包内没有明确编码标记时，服务端可能按自己的默认编码去解释字节流，中文就很容易变成乱码。常见表现是同一批文件里，纯英文名正常，中文名全部异常，或者只有部分含特定字符的文件名出错。这一层要核对的是解压服务本身的配置说明，确认它是否有可指定的文件名编码参数。
第三层，看解压后文件落盘与下载环节是否再次转码。有些情况下，解压时文件名读取是对的，但写入存储或生成下载链接时又经过一次编码转换，导致最终看到的名称出错。区分方法很直接：在解压完成后的文件列表页面看一次文件名，再把文件下载到本地看一次文件名。如果列表页正常而下载后乱码，问题在下载环节；如果列表页就已经乱码，问题在解压读取环节。把乱码发生的具体步骤定下来，后面的处理才有方向。
可执行的核对清单可以这样安排。第一步，准备一个小样本压缩包，只放三到五个中文名文件，文件名尽量简单，不含空格和符号。第二步，上传解压后逐条对比原始文件名与页面显示名称，记录哪些字符发生了变化。第三步，分别记录打包环境的编码设置、解压服务的编码参数、下载环节的响应头信息，形成一条完整的传递链。第四步，如果条件允许，换一种打包工具重新生成同样内容的压缩包再测一次，观察差异是否随打包工具变化。
预防上，建议在打包前统一命名规范，中文文件名尽量保持简洁，避免混用全角半角符号和表情字符。对批量文件，可以在打包前先做一次名称整理，把容易出问题的字符替换掉。网站维护方在接收用户上传的压缩包时，也可以在小样本测试通过后再处理正式文件。具体处理方式应以服务环境的实际情况和相关技术文档为准，不同解压服务的默认行为存在差异，不宜直接套用同一种设置。
