有用户反馈，把7Z压缩包上传到网页端解压后，文件内容能正常打开，但文件名全变成了问号、方块或一串看不懂的字符。遇到这种情况，先别急着认定压缩包损坏。内容能打开，说明压缩数据本身大概率是完整的，问题更可能出在文件名的编码记录方式与网页端解压环境的识别方式不一致。先判断是文件名乱码还是内容损坏，再按下面的顺序逐层排查，能少走很多弯路。
第一层，核对压缩包本身。把同一个7Z文件下载到本地，用系统自带的解压工具打开，观察文件名是否正常显示。如果本地打开也是乱码，说明问题出在打包环节，压缩时文件名编码没有按通用方式记录，网页端只是把这个问题暴露出来。如果本地显示正常，那压缩包本身没问题，重点转向网页端的解压处理。
第二层，核对文件名编码。中文文件名在压缩包内可能以不同编码方式记录，常见的有UTF-8和本地代码页两类。网页端使用的解压库如果只按其中一种方式识别，另一种就会显示成乱码。这一层要查的是解压库文档中关于文件名编码的说明，确认它默认按什么编码解析、是否提供手动指定编码的选项。很多乱码问题就卡在这里，不是代码写错，而是编码参数没有对上。
第三层，核对网页端解压流程。从用户上传、临时存储、调用解压、重命名到返回文件列表，每个环节都可能引入编码转换。重点看重命名这一步：解压库输出的原始文件名是什么形态，程序在写入列表或存储时有没有再做一次编码转换。如果中间某一步把字节按错误编码解码后又重新编码，文件名就会在这一步被破坏。可以保留一份解压库的原始输出做对照，判断转换发生在哪一环。
第四层，核对浏览器与下载环节。有时候解压后的文件名在网页列表里显示正常，用户下载到本地却变成乱码。这种情况问题不在解压，而在下载响应头的文件名编码方式。响应头中的文件名如果编码声明与实际字节不一致，浏览器就会按自己的理解还原，结果出现乱码。检查响应头的写法，确认文件名编码与声明匹配，是这一层的核心。
给出一个可执行的核对清单：先在本地用系统工具打开压缩包，确认文件名是否正常；再查解压库文档，确认默认编码和可配置项；接着保留原始压缩包与解压库输出做对照，定位转换发生的环节；最后检查下载响应头的文件名编码声明。四步走完，问题基本能锁定在一个具体环节。
处理这类问题，顺序比速度重要。先定位是打包、解压库识别、流程转换还是下载响应头的问题，再针对那一层修改，比直接重写整套解压逻辑更稳妥。it数运在网站维护中处理类似反馈时，也遵循先分层核对、再动手调整的原则，避免把小问题改成大改动。
