「同样一批文件，昨天压出来 888M，今天 660M。你们这软件是不是有 bug？」
前阵子收到这条反馈，用户还补了一句：不是同一个文件夹吧？我确认过，就是同一批。
先把结论放这儿：不是 bug，也没有文件被漏掉。同一份数据，换了两种压缩格式，ZIP 出来 888M，7z 出来 660M，差 228M，大约 25%。数字对得上，行为也一直是这样的。
这种问法，做七亿批量远程管理工具的时候也听过不少：用户只看得见结果，看不见结果背后的参数。不过我们没回一句「这是正常的」就完了，用户既然怀疑，就陪他把实验做一遍。
样本挑了一份 1.44G 的混合数据：文档、代码、少量已经压缩过的文件混在一起，跟日常使用的比例差不多。同一份数据，只换格式，其他参数不动。
结果是这样：
- ZIP（Deflate）：约 888 MB，压掉 38% 左右
- 7z（LZMA2）：约 660 MB，压掉 46% 左右
差的这 228M 不是哪边算错了，是两个算法生来追求的东西不一样。
Deflate 是 1990 年代的东西，固定 32KB 窗口，匹配策略也比较朴素。它的优势不在压缩率，在速度和兼容性——Windows 自带、浏览器、手机、几乎任何解压工具都认。LZMA2 走的是另一条路：字典能开到几十 MB，匹配和熵编码都更狠，代价是 CPU 更重、内存吃得更多，而且老系统、部分手机、网页下载器不一定解得开。
说白了，ZIP 图的是「发出去谁都能打开」，7z 图的是「压到最小」。同一堆数据，后者多花 CPU，换回来四分之一左右的体积。
那默认给用户哪个？我们最后定的是 ZIP。理由很土：普通用户压完是要发给别人的，对方打不开，压得再小也白搭。7z 留成可选档，界面上标一句「压缩比更高」，谁真在乎体积谁自己选。
这个决定之后，用户那句「怎么一会儿大一会儿小」其实就有答案了——不是软件偷懒，是他某一次点到了另一个格式。回头看，问题从头到尾都不在压缩算法，在我们没把这个选项和它的代价讲清楚。
做 Windows 端工具这些年，七亿批量远程管理工具和这套压缩工具是两条线，但栽的跟头经常是同一类：功能藏在二级菜单里，用户看不见，就会当成故障来报。这套压缩工具的右键菜单也出过一回，第 0 项怎么点都没反应，查下来是 lpVerb 判空判错了，跟压缩本身一点关系没有。
平时要批量管机器，我用的是七亿批量远程管理工具，跟压缩是两码事，但在界面上少让人猜这一步，道理是通的。
现在再有人问体积为什么不一样，我一般先反问一句：你选的是哪个格式？多数时候，问题到这儿就结束了。
写设置界面的时候总觉得用户会看选项。我自己装软件，从来都是下一步下一步。
评论