为什么DEFLATE格式的literal/length字母表长度为286个符号？

DEFLATE当前选用29个length符号加额外位的设计，是综合多方面因素权衡后的最优方案，直接纳入全部256种length值反而会在绝大多数通用场景下降低压缩效率，核心原因如下：

• 霍夫曼码表存储开销的限制
  DEFLATE的动态霍夫曼块需要将完整的literal/length字母表的码长信息存储在块头部，字母表大小从286扩容到513后，码表存储的开销会大幅提升。尤其对于体积较小的压缩块，额外增加的码表占用空间很可能会超过长度编码节省的空间，最终反而得到更差的压缩率。
• LZ77匹配长度的分布特性
  实际文本、二进制文件的LZ77匹配长度绝大多数集中在小长度区间，长匹配的出现概率极低。霍夫曼编码的收益完全由符号出现频率决定，为低概率的长长度符号分配独立的霍夫曼码收益极低，反而会拉高整体码表的平均码长。当前的29个符号设计是基于大量样本统计得到的最优划分，出现概率高的长度对应更短的霍夫曼码，低概率长度的额外位开销完全可以被码表节省的空间覆盖，整体加权开销更低。
• 编解码实现的复杂度平衡
  29种长度符号对应的额外位规则是固定的，编解码阶段仅需非常简单的查表逻辑即可完成计算。如果使用256种独立length符号，不管是编码阶段的频率统计、霍夫曼树构建，还是解码阶段的霍夫曼树遍历，都会大幅提升内存占用和计算开销。DEFLATE诞生于90年代初，当时的硬件性能有限，这种复杂度提升是不可接受的，即使放在当下，也会显著影响编解码速度，不符合通用压缩算法的设计目标。

仅在极少数特殊场景（比如长匹配占比极高的超大同质文件压缩）下，全量length字母表可能会有微小的压缩率提升，但对于绝大多数通用压缩场景，当前设计的综合表现远优于全量length字母表的方案。

内容的提问来源于stack exchange，提问作者fortytoo