为什么要排列代码长度代码（动态霍夫曼代码

【问题标题】：Why permutate the code length codes ( Dynamic Huffman Codes | RFC-1951 )?为什么要排列代码长度代码（动态霍夫曼代码 | RFC-1951）？
【发布时间】：2013-05-25 08:16:37
【问题描述】：

我一直在研究 RFC 1951（DEFLATE 压缩算法），并发现了 Mark Adler 的有趣“学习”源文件，名字很可爱——puff.c。虽然通过合理遵循 RFC-1951 规范，大脑解析该文件是一种启发性的体验，但作者做了一些我不太清楚的事情——他改变了索引长度数组的顺序。

在代码的cmets中解释有点模糊：

码长码长按置换顺序接收（参见 order[] 数组下面）来制作更短的码长码长列表可能。事实证明，非常短和非常长的代码更少可能会在动态代码描述中看到，因此可能会出现什么最初是一种特殊的顺序。

这是楼上描述的排列数组：

static const short order[19] =      /* permutation of code length codes */
        {16, 17, 18, 0, 8, 7, 9, 6, 10, 5, 11, 4, 12, 3, 13, 2, 14, 1, 15};

所以，我的问题是：

为什么 RFC-1951 中没有提到这一点？
他们如何确定order 中列出的确切排列？
它是如何工作的？顺序变了，为什么解码过程没有失败？

非常感谢。这不是作业，我也不是为了学习经验而试图超越原始算法。我搜索了这个网站，谷歌是我的朋友，但无济于事。

【问题讨论】：

标签： c compression huffman-code deflate

【解决方案1】：

它是在RFC 1951:

       (HCLEN + 4) x 3 bits: code lengths for the code length
          alphabet given just above, in the order: 16, 17, 18,
          0, 8, 7, 9, 6, 10, 5, 11, 4, 12, 3, 13, 2, 14, 1, 15

如果您尝试更改它，解码过程将会失败（在放气端也没有更改它，在这种情况下它不能再称为放气）。

最可能使用的代码长度代码在列表的前面，最不可能在列表的后面。这允许列表在大多数情况下更短，因此HCLEN 更小，每个不存在的列表项节省三位。

【讨论】：

漂亮，一定错过了。谢谢！但是，我必须问 - 有没有什么地方我可以读到他们实际上是如何确定排列顺序的？
代码长度可以是 1..15，最小和最大的可能性最小。所以1和15在最后。 2和14在那之前。等等。重复代码 16、17 和 18 几乎总是被使用，0 表示符号不存在。所以这些还不如一开始。