Encoding 用静态哈夫曼码压缩编码

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

因此，让我们进行编码，例如“晚放气”。Params:[搜索缓冲区：8kb，前瞻缓冲区4kb]好的，LZSS算法的输出是“Deflate”，下一步使用静态哈夫曼编码来减少冗余。这是我的问题，我不知道我应该如何编码这对哈夫曼

---

[已编辑] D 000
f 001
L010
a 011
t 100
_101
e 11

---

那么，根据这个表，字符串“Deflate”写为000110010111001101。作为下一步，让我们对该对（5，4）进行编码。根据《数据压缩-完整参考》一书，长度为4的固定前缀代码为258，其次是距离为5的固定前缀代码（代码4+1额外位）

这可以概括为：

长度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]，但是如果我创建一个哈夫曼树，它就不再是静态哈夫曼了，对吗

你好

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

不是放气静态代码。静态文字/长度代码全部为7、8或9位，距离代码全部为5位。你问过关于静态代码的问题

“Deflate late”以静态Deflate格式编码为文本“Deflate”，长度为4，距离为5，十六进制匹配为：

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

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

---

既然您没有询问如何对“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]，但如果我创建一个哈夫曼树，它不是一个静态哈夫曼，对吗？你能解释一下为什么00101110=D和10101001=e吗？请阅读RFC 1951第3.2.6节。D=0x44。添加0x30以获取0x74。反转位，得到00101110。e=0x65。添加0x30以获得0x95。将位倒转，得到10101001。RFC非常混乱，它的表是十进制的，而不是二进制的，并且没有清楚地解释这些表是如何派生出来的。你从哪里得到0x30的？它总是+0x30，还是基于要添加的值？你为什么要倒过来？您知道有没有其他资源（除了RFC）提供了压缩数据膨胀的清晰示例，并解释了为什么固定表是这样的？我查看了一下，但在列表中找不到任何半生不熟的表。0x30是固定哈夫曼码（256到279）中的7位代码数。在哈夫曼代码的规范构造中，这些代码位于8位代码之前，因此要对0到143范围内的文字进行编码，需要添加0x30以说明这些代码之前的代码。根据3.1.1中的约定，位被颠倒。为了可能有助于您理解RFC 1951，您可以查看，这是一个简单的充气器，用于明确定义格式。

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