实心压缩原理:为什么压得更小的包不一定更好用

一个反直觉的现象

把一堆文件丢进压缩包，体积确实降下来了。但如果这个包里有一份几百兆的原始素材，而你只想从中抽出其中一个文件来用，事情就没那么美好了——解压工具必须从压缩包的开头一路解码到你要的那一段，才能把文件交出来。

这个现象背后是一组几乎所有压缩工具都默认做了、却很少解释的取舍。

两种打包思路

压缩包里存文件的方式大致分成两类。

非实心（每个文件独立压缩）：包里的每个文件各自被当成一段独立的数据流，从零开始建自己的字典，压完一个再压下一个。它的好处是每个文件都有明确的起始位置，想取哪个文件，解压工具直接跳过去就行。坏处是每个文件的字典都是"冷启动"，前几百个字节因为没有可参考的历史，往往压得不怎么样。

实心（多个文件连成一条流）：所有文件的头尾相接，拼成一条长长的数据流，再用一套字典从头压到尾。后面的文件可以引用前面文件里出现过的内容——如果十个文件开头都是同一份模板说明，实心模式下第十个文件几乎不用为这段内容花任何代价。它的坏处正好相反：字典是共享的、连续的，你没法直接跳到中间某个位置。

这个取舍的本质

说得再直白一点，实心压缩用"访问的灵活性"换了"压缩效率"。

字典类算法的压缩能力来自历史数据——它能引用多远的过去，取决于字典窗口能开多大。非实心模式下，每个新文件开始时字典都是空的，等于主动放弃了前面所有文件积累的匹配信息。实心模式把这部分浪费省掉了，但同时把"每个文件自带起点"这个性质也一起丢掉了。

这也是为什么实心模式在同类文件扎堆时收益最明显：几十张来自同一台设备的照片、几十份格式统一的文档，它们的头部和背景有大量重复，共享字典能把这些重复一遍遍复用。而如果包里装的是一堆彼此无关的东西，实心带来的优势就会被文件之间的频繁切换稀释掉。

随机访问为什么重要

判断一个压缩包"好不好用"，很多人只盯着体积。实际工作里经常遇到的却是另一类问题：

• 只想要包里的一个文件，不想全解
• 想看看包里有什么，但不愿意为了看目录解压一遍整个大包
• 需要在不解压的前提下，直接访问压缩包里的某个条目

这三件事都指向同一个能力——随机访问。它不是压缩算法本身的属性，而是打包结构决定的。

在闪压里处理压缩包相关需求时，可以先想清楚一件事：这个包是为了让别人一次性完整取走，还是为了让某个人随时能取其中一部分。前者适合实心思路，后者适合非实心思路。具体操作可以参考压缩包解压模块的常被忽略细节和从压缩包里单独解出一个文件这两篇。

还有一层：预压缩数据

实心压缩还有一个常被忽略的变体：先对整个文件集做一次字典训练，把常见的字符串模式抽成一份预设字典，再拿这份字典去压缩实际数据。

这相当于给算法一份"预习资料"，让它在压缩第一个字节时就已经知道后面可能出现哪些模式。对文本类、日志类、数据库导出这类结构高度重复的内容，预训练字典往往比单纯把字典窗口开大更有效。这背后的思路和压缩管线中的预处理是同一套逻辑——编码器能力有限，就先在编码之前把数据收拾成它更擅长的样子。

怎么选

给一个粗略的判断框架：

偏向实心/大字典——包里全是同一类文件、追求极限体积、只考虑完整取走和解压（比如项目归档包、整套素材交付）。

偏向非实心/小字典——包内文件类型混杂、需要频繁访问单个条目、需要在不解压的前提下查看内容。

考虑预训练字典——内容以文本、代码、日志、表格为主，重复模式明显且规律性强。

一句话总结

压缩包的体积和可用性经常被人当成同一件事的两面，其实它们分属两套不同的机制。字典开多大、要不要跨文件共享历史，取决于你打算怎么用这个包，而不是取决于哪个数字更小。

想了解压缩流程里字典怎么建、怎么用的，可以接着看字典编码与熵编码如何分工和字典压缩四十年演进。想直接上手处理本地压缩包，用闪压的压缩包解压和文件压缩模块即可。