把压缩包再压一次，能一直变小吗？

假设一张纸上连续写着一千个 A，我们可以记成“重复 A 一千次”。这条描述比原文短，而且接收方按约定就能还原。真实压缩器会寻找重复片段或利用不同符号出现的规律；它没有把信息凭空消灭，而是换成更省空间的表示。

但这个约定也要能被理解。“一千次”怎样编码，原文字母恰好包含命令时怎样区分，数据在哪里结束，都需要规则。文件头、长度和校验信息也可能占空间。因此短文件即使有一点重复，节约的部分也未必足以抵消额外开销。

把问题缩小：长度恰好为两位的二进制串只有四个，分别是 00、01、10、11。比两位更短的串有哪些？只有空串、0 和 1，总共三个。如果要求四种输入都缩短，又要求能够无损还原，就必须给四张不同纸条安排三个不同标签。

至少两张纸条会撞到同一个标签。解压程序只看到标签，便无法知道应还原哪一张。这就是简单的计数理由：在固定解码规则下，不可能让每一种输入都更短。扩大到更长文件，短表示数量不够的矛盾仍然存在，与使用哪种编程语言无关。

这不意味着第二次压缩绝对不能变小。第一个压缩器可能没找完规律，特定格式也可能留下重复结构；换工具或再次处理，有时仍能省一点。zlib 的技术说明就讨论过特殊重复数据的这种情况，所以“一定毫无效果”同样说得太满。

但每压一次都保证缩小，适用于所有文件的承诺无法成立。已经压得很紧的数据常常没有足够可用的重复，外层格式却还要增加说明。所谓无损，是解压后逐字节相同；若把图片缩尺寸、删细节后变小，那是在改变需要保留的内容，回答了另一个问题。

你可以准备一份重复文字和一份已压缩文件，用同一个工具记录输入、输出字节数，再解压比较内容。只需小文件就能观察现象，没必要制造巨大压缩包。压缩比应说明分子分母：有人说原大小除以压缩后大小，也有人报节省百分比。

如果一个方案把主要内容藏进共享字典、远端服务器或接收方预装的数据里，小文件并不等于总成本变小。共享数据在真实场景可能很有价值，但比较时要说明谁已经拥有它、用了多少空间。把这些前提写出来，比只展示漂亮的压缩倍数更有意义。