Question

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

在代码的评论中，解释有点模糊：

代码长度代码长度以置换顺序接收（参见 order [] array below）使短代码长度列表更多有可能。事实证明，非常短且非常长的代码更少可能会在动态代码描述中看到，因此可能会出现最初是一种特殊的顺序。

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

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中确切排列的？
它是如何工作的？为什么解码过程因订单发生变化而失败？

非常有责任。这不是家庭作业，也不是我试图超越原始算法，只是为了学习体验。我搜索了这个网站，谷歌是我的朋友，但无济于事。

Answer 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

如果你试图改变它，解码过程就会失败（不会在deflate端改变它，在这种情况下它不能再被称为deflate）。

要使用的最可能的代码长度代码在列表的早期，最不可能在列表的后面。这允许列表在大多数时间内更短，因此HCLEN更小，每个列表项不存在三位。

为什么要置换代码长度代码（动态霍夫曼代码| RFC-1951）？

1 个答案: