上传的GZ压缩包在网页端解压成功，文件内容也能正常打开，但文件名全变成了问号或方块。这种情况容易让人误以为是压缩包损坏，其实文件本身往往是完好的，问题出在文件名的字符编码在传递过程中被反复解读。GZ这类压缩格式在打包时通常只保留文件名的原始字节，并不强制记录编码信息，一旦打包环境和解压环境的字符集不一致，文件名就会失真。核对时按下面几层顺序推进，能少走弯路。
第一层，核对压缩包内文件名的编码来源。文件名在打包时使用什么字符集，取决于打包工具和操作系统。在部分中文环境下打包的文件名可能是GBK编码，而在另一些环境中打包的是UTF-8编码。GZ格式本身不像某些压缩格式那样带有统一的编码标记，解压工具只能靠猜测。可以先在本地用命令行查看压缩包内的原始文件名列表，观察是全部乱码还是只有中文乱码，全部乱码通常指向编码整体错配，只有中文乱码则更可能是打包端使用了本地字符集。
第二层，核对网页端解压工具的编码识别设置。不少在线解压组件默认开启自动识别，自动识别在文件名较短或混合中英文时容易判断失误。可以查看该工具是否提供手动指定编码的选项，将其切换为UTF-8或GBK分别试一次，对比结果。如果切换后文件名恢复正常，说明问题在识别环节，而不是压缩包本身。
第三层，核对服务器文件系统与下载环节的编码转换。解压后的文件名要经过服务器临时目录存储，再通过下载响应返回给浏览器。这一路上如果发生两次转换，比如解压时按一种编码写入磁盘，下载时又按另一种编码输出，文件名就会二次失真。常见的两次转换错误包括：解压程序按系统默认编码写盘，而下载接口按UTF-8输出；或者文件名在URL编码环节被重复编码。核对时可以观察服务器上实际存储的文件名与浏览器下载到的文件名是否一致，不一致就说明转换发生在输出环节。
给出一份从打包到下载的六步核对清单。第一步，确认打包环境的系统字符集并记录。第二步，打包时优先选择能显式指定UTF-8的工具参数。第三步，上传后在服务器端查看压缩包内文件名原始字节。第四步，解压工具手动指定编码试运行，对比自动识别的结果。第五步，检查解压后磁盘上的文件名与预期是否一致。第六步，下载时抓取响应头，确认文件名参数的编码方式。错误做法是每一步都依赖默认值，正确做法是至少在一个环节显式固定编码。
长期预防上，可以在团队内统一打包规范，要求压缩包内文件名使用UTF-8，并在维护记录中登记编码约定，方便后续排查时快速定位。网站维护中这类问题反复出现，往往不是技术难度高，而是缺少统一的约定。it数运在处理类似维护事项时，通常会把编码约定写进交付说明，减少后续沟通成本。
最后需要说明，不同服务器环境、不同解压组件对编码的处理存在差异，上述顺序只是一般性的核对思路，具体情况应以实际测试结果为准。文件名乱码不影响文件内容时，优先保障数据可用，再逐步修正显示问题。
