不解压就看清 ZIP 内容清单:压缩包检查的完整做法

收到一个来历不明的压缩包,最危险的动作就是双击它。解压的那一刻,文件已经落到磁盘上,路径、覆盖、体积全都由压缩包说了算。更稳妥的顺序是反过来:先看清里面有什么,再决定要不要解压。这篇文章讲的就是怎么不解压也能列出 ZIP 的完整内容清单,顺便把可疑文件和异常体积提前挑出来。

ZIP 里其实自带一份目录

很多人以为不解压就读不到 ZIP 内容,其实不然。每个 ZIP 文件末尾都有一段叫中央目录(central directory)的结构,它像一本书的目录,记录了归档里每一个条目的元数据:文件名(完整路径)、压缩后大小、解压后大小、压缩方法、加密标记、CRC32 校验值,还有时间戳。读这段目录不需要把任何文件真正解压出来,字节量很小,几兆甚至几百兆的压缩包,读清单都是瞬间的事。

所以"列出 ZIP 内容"和"解压 ZIP"是两件事。前者只读目录区,后者才会把压缩数据流真正还原成文件写到磁盘。检查这一步,我们只做前者。ZIP 清单检查器正是这么工作的:在浏览器里打开 ZIP,解析中央目录,把每个条目逐行列出来,再导出一份 CSV。整个过程不解压、不执行、不上传。

一份清单要看哪几列

把中央目录列成表后,有几列特别值得盯:

路径:看有没有 ../ 这种穿越路径、绝对路径或反斜杠路径,这些是解压时写到目标文件夹外面的隐患。
压缩后大小与解压后大小:两者一比就是压缩率。文本和日志压得很高很正常,但一个几 KB 的条目解压后变成几个 GB,就要当心 ZIP 炸弹。
压缩方法:Store(不压缩)、Deflate 最常见,出现不认识的方法值要留意。
加密标记:被加密的条目在清单里会标出来,提醒你它需要密码,也提醒你别在不知情时把它当普通文件处理。
CRC32:每个条目自带的校验值,可以和你预期的版本核对,确认内容没被篡改或损坏。
重复名称:同名条目可能在解压时互相覆盖,清单里集中列出来一眼就能发现。

一个真实例子

我前阵子接到一个供应商发来的 release 包,文件名叫 vendor-build.zip,大小 18 MB。没急着解压,先丢进清单检查器跑了一遍,导出的清单大致是这样:

| 路径 | 压缩后 | 解压后 | 压缩率 | 备注 | |---|---|---|---|---| | dist/app.js | 1.2 MB | 4.8 MB | 75% | 正常 | | dist/vendor.css | 240 KB | 1.1 MB | 78% | 正常 | | assets/logo.png | 86 KB | 88 KB | 2% | 正常 | | ../config/secrets.env | 1 KB | 3 KB | 67% | 路径穿越 | | data/seed.sql | 30 KB | 920 MB | 99.99% | 膨胀比异常 |

前三行都很正常,图片几乎压不动也合理。问题出在后两行:一个 ../config/secrets.env 想往上级目录写,典型的路径穿越;还有一个 30 KB 的 SQL 文件解压后竟有 920 MB,膨胀比逼近一万倍,标准的 ZIP 炸弹特征。要是直接双击解压,前者可能覆盖掉项目外的配置,后者直接把磁盘塞满。清单这一步就把这两个坑提前暴露了,我把 CSV 转给供应商核对,问题当场就定位了。

把检查变成习惯动作

第一人称说一句:自从养成"先看清单再解压"的习惯,我处理外来压缩包的心态轻松了很多。以前是带着赌的心态双击,出事再补救;现在是先看一眼那张表,路径、体积、重复名称都在眼前,该批准批准,该退回退回。清单还能直接发给安全或运维同事审批,大家看的是同一份事实,不用各自猜。

要让检查更完整,清单里的 CRC32 可以配合校验工具一起用。比如你手上有官方公布的文件指纹,就能用文件校验和比对把下载到的内容和预期值核对一遍,确认压缩包在传输途中没被篡改或截断。清单看结构,校验和看内容,两步合起来,完整性才算真的确认过。

需要提醒的是,导出的 CSV 里会带上真实文件名和路径,这些本身可能是敏感信息,转发时记得控制范围。ZIP 结构在你本地浏览器里解析,不会上传,但导出的清单去了哪里就得你自己把关了。

小结

排查一个压缩包,不必先解压。读中央目录就能列出全部文件名、大小、压缩率、加密标记和 CRC32,顺手把路径穿越、异常膨胀比和重复名称挑出来。供应商交付、客服附件、CMS 导入、训练数据集,凡是来路不全清楚的归档,先跑一遍清单,再决定下一步,既稳又快。

Made by Toolora · Updated 2026-06-13