压缩包格式演进逻辑:从单一容器到组合管线怎么走过来的

压缩包格式不是一次设计出来的,每一代都在解决上一代留下的麻烦。看懂这条演进线索,比记一堆格式名字有用得多。

最早只有一个容器

最早的压缩包,容器和压缩算法是绑在一起的。ZIP 把目录结构、文件元数据和压缩后的数据打包在一起,用的是自己的压缩方法。

这种绑定带来一个直接后果:ZIP 能读 RAR 吗?不能。因为文件头的结构就不一样,连哪些字节是压缩后的数据都判断不出来。

容器和算法混在一起,每换一个算法就要发明一个新格式。用户想用更好的压缩方法,只能换一个完全不同的压缩包格式,老的包还得重新打一遍。

把压缩和容器拆开

后来的思路是分工:容器只负责组织,压缩算法只负责把字节变小。

文件头写着我是容器,里面有一段说明用的是哪种压缩方法,还有一段说明原始文件多大。读取的时候,先读容器结构,再按说明调用对应的解压器。

这样一来,同一个容器格式可以承载多种压缩算法,新的算法出来也不需要重新发明格式。归档和压缩分开组合的那类产物就是典型例子,整体结构见压缩管线的完整拆解。

代价是容器格式变多了。每个组合都得单独记一套约定,ZIP 内部到底放了什么,可以看压缩包内部结构解析。

格式变多的原因

容器和算法拆开之后,格式数量自然膨胀。每种格式都有自己的适用场景:有的擅长随机访问,有的擅长压缩比,有的擅长流式处理。

所以选格式不是选最好的那个,而是选合适的那个。日常要发给 Windows 用户,ZIP 是最省事的,对方双击就能打开;要压到极致而且对方也是 Windows,那个支持加密和分卷的格式更合适;要在 Unix 环境里跑脚本,归档和压缩分开的那种组合更顺手。

格式选错带来的问题往往不是压不出来,而是对方打不开。选之前先想清楚收件人用什么。

分块为什么成为共识

大文件压缩有个绕不开的问题:要压缩就得先把整个文件读进内存。文件越大,内存占用越夸张,机器直接卡住。

分块策略把文件切成独立的小块,每块单独压缩。好处是内存占用恒定,块与块之间还能并行处理。坏处是块与块之间无法互相参考,压缩比会略降。

现代格式普遍采用某种形式的分块,这是流式处理和并行压缩的基础。分块为什么必要、切多大合适,见分块压缩原理。

从选择角度看这条线索

把演进线索落到日常选型上,能省不少试错。

要发给不确定环境的收件人,优先考虑对方一定能打开的那种格式,兼容性优先于压缩比。要是自己长期存档,压缩比和加密能力优先,因为以后只有自己能解。

要在超大文件上工作,重点看格式是否支持分块和流式,不然内存直接吃满。要反复往压缩包里取单个文件,随机访问能力比压缩比更重要。

这四个需求对应了格式设计上的四个方向,每一个方向都是当年某一代格式要解决的具体问题。看懂这条线,选格式基本不用靠试。

看起来像是历史考古,其实在排查问题时很有用。

遇到一个包解不开,先判断是容器不认识还是算法不支持。容器不认识,是格式本身超出对方工具的能力;算法不支持,是拆得太细导致对方缺少对应的解码器。两种问题的解法完全不同,前者只能换格式重打,后者可以换个工具试试。

同样,自己打的包要长期保存,就别只盯着压缩比。容器和算法分开之后,你可以分别选择:用兼容性最好的容器装最省空间的算法。以后要换算法,容器不用重做。

这就是分层的价值,也是这条演进线索真正的落点。

说到底,格式演进的每一步都是拿某种代价换另一种好处。拆开容器和算法,代价是格式变多;引入分块,代价是压缩比略降。

没有哪个格式在所有维度上都是最优的,只有在不同约束下的合适选择。理解了这一点,就不会再纠结于哪个格式"最好"。