【问题标题】：DEFLATE Encoding with static Huffman Codes使用静态霍夫曼码的 DEFLATE 编码
【发布时间】：2013-06-28 05:55:56
【问题描述】：

需要一些帮助来了解 DEFLATE 编码的工作原理。我知道这是LZSS算法和霍夫曼编码的结合。

所以让我们编码例如“Deflate Late”。 Params: [Search buffer: 8kb and Look-ahead buffer 4kb] 那么LZSS算法的输出是“Deflate” 下一步使用静态huffman编码来减少冗余。这是我的问题，我不知道我应该如何用霍夫曼对这对进行编码。

[已编辑]

D 000
f 001
l 010
011
t 100
_ 101
11

好吧，根据这个表，字符串“Deflate”写成 000 11 001 010 011 100 11 101。下一步让我们对 (5, 4) 对进行编码。《Data Compression - The Complete Reference》一书中长度为4的固定前缀码为258，后跟距离为5的固定前缀码（Code 4 + 1 Extra bit）。

可以概括为：

长度 4 -> 258 -> 0000010
距离 5 -> 4 + 1 个额外位 -> 00100|0

所以，编码的字符串写成 [header: 1 01] 000 11 001 010 011 100 11 101 0000010 001000 [end-of-block: 0000000]，但是如果我创建一个霍夫曼树，它不是静态的哈夫曼了，对吧？

美好的一天

【问题讨论】：

既然您没有询问如何编码“Deflate”，那么您必须已经知道如何为这些文字发出霍夫曼代码。您执行完全相同的操作，即发出长度 4 而不是文字，后跟距离代码 5。
好吧，根据这个表，字符串“Deflate”写成 000 11 001 010 011 100 11 101。下一步让我们对 (5, 4) 对进行编码。《数据压缩-完整参考》一书中长度为4的固定前缀码为258，后跟距离为5的固定前缀码。【概括为】：长度4 -> 258 -> 0000010 [7位]距离 5 -> 4 + 1 个额外位 -> 00100|0 因此，编码字符串写为 [header: 1 01] 000 11 001 010 011 100 11 101 0000010 001000 [end-of-block: 0000000]，但如果我创建了一棵霍夫曼树，它不是静态的霍夫曼树，对吧？

标签： encoding zip huffman-code deflate

【解决方案1】：

不是 Deflate 静态代码。静态文字/长度代码都是 7、8 或 9 位，距离代码都是 5 位。你问的是静态代码。

'Deflate Late' 以静态 deflate 格式编码为文字 'Deflate' 和长度为 4、距离 5 的十六进制匹配是：

73 49 4d cb 49 2c 49 55 00 11 00

分解如下（首先从每个字节的最低有效部分读取位）：

011 - 01 means fixed code, 1 means last block
00101110 - D
10101001 - e
01101001 - f
00111001 - l
10001001 - a
00100101 - t
10101001 - e
00001010 - space
0100000 - length 4
00100 - distance 5 or 6 depending on one extra bit
0 - extra bit -> distance 5
0000000 - end code
0 - fill bit to byte boundary

【讨论】：

您能否详细说明为什么 00101110 = D 和 10101001 = e？
阅读 RFC 1951，第 3.2.6 节。 D = 0x44。添加 0x30 得到 0x74。反转位并得到 00101110。e = 0x65。添加 0x30 得到 0x95。反转位，得到 10101001。
RFC 非常令人困惑，并且有半生不熟的十进制表而不是二进制表，并且没有清楚地解释这些表是如何派生的。你从哪里得到 0x30？它总是+ 0x30，还是基于您要添加的值？你为什么要反转位？您是否知道任何其他资源（除了 RFC）提供了膨胀压缩数据的明确示例，并解释了为什么固定表是这样的？
我查看了，但在RFC 中找不到任何半生不熟的表格。 0x30 是固定霍夫曼码（256 到 279）中 7 位码的数量。这些在霍夫曼代码的规范结构中位于 8 位代码之前，因此要对 0 到 143 范围内的文字进行编码，您需要添加 0x30 来说明这些代码之前的代码。这些位按照 3.1.1 中提到的约定进行反转。
为了帮助您理解 RFC 1951，您可以查看 puff.c，这是一个简单的充气器，用于明确定义格式。