Deflate压缩块的结构

Question

我无法理解 Deflate 算法 (RFC 1951)。

TL; DR如何解析Deflate压缩块4be4 0200？

我创建了一个包含字母和换行符a\n 的文件，然后运行gzip a.txt。结果文件a.txt.gz:

1f8b 0808 fe8b eb55 0003 612e 7478 7400

4be4 0200

07a1 eadd 0200 0000

我知道第一行是带有附加信息的标题，最后一行是 CRC32 加上输入大小 (RFC 1951)。这两个对我没有任何麻烦。

但是我如何解释压缩块本身（中间线）？

这是它的十六进制和二进制表示：

4be4 0200

0100 1011
1110 0100
0000 0010
0000 0000

据我了解，不知何故这些：

每个压缩数据块都以包含以下数据的 3 个标头位开始：

• 第一位 BFINAL
• 接下来的 2 位 BTYPE

...实际上结束于第一个字节的end：0100 1011。 （我将跳过这个问题，为什么有人将实际上位于其他事物尾部的事物称为“标题”。）

RFC 包含的内容据我所知应该是对此的解释：

• 数据元素按顺序打包成字节 增加字节内的位数，即开始 字节的最低有效位。
• 哈夫曼码以外的数据元素被打包 从数据的最低有效位开始 元素。
• 霍夫曼编码从最- 代码的重要部分。

换句话说，如果将压缩数据打印为 一个字节序列，从第一个字节开始 right 边距并继续到 left，最- 像往常一样，左侧每个字节的有效位是 能够以固定宽度从右到左解析结果 正确的 MSB 到 LSB 顺序和 Huffman 代码中的元素 位反转顺序（即，与代码的第一位在 相对 LSB 位置）。

但遗憾的是我不明白那个解释。

返回我的数据。 OK，这样BFINAL就设置好了，BTYPE是什么？ 10 点还是 01 点？

我如何解释该压缩块中的其余数据？

Answer 1

首先让我们将压缩数据的十六进制表示形式视为一系列字节（而不是您问题中的一系列 16 位大端值）：

4b e4 02 00

现在让我们将这些十六进制字节转换为二进制：

01001011 11100100 00000010 000000000

根据 RFC，这些位是“从字节的最低有效位开始”打包的。字节的最低有效位是字节的最右边位。所以第一个字节的第一位就是这个：

01001011 11100100 00000010 000000000
       ^
       first bit

第二位是这个：

01001011 11100100 00000010 000000000
      ^
      second bit

第三位：

01001011 11100100 00000010 000000000
     ^
     third bit

等等。一旦你遍历了第一个字节中的所有位，你就可以从第二个字节的最低有效位开始。所以第九位是这个：

01001011 11100100 00000010 000000000
                ^
                ninth bit

最后一位，三十秒位，是这个：

01001011 11100100 00000010 000000000
                           ^
                           last bit

BFINAL 值是压缩数据中的第一位，因此包含在上面标记为“第一位”的单个位中。它的值为1，表示这是压缩数据中的最后一个块。

BTYPE 值存储在数据的下两位中。这些是上面标记为“第二位”和“第三位”的位。唯一的问题是两者中哪一位是最低有效位，哪一位是最高有效位。根据 RFC，“哈夫曼代码以外的数据元素被打包 从数据元素的最低有效位开始。”这意味着这两个位中的第一个，标记为“第二位”的那个是最低有效位。这意味着 BTYPE 的值是二进制的01。所以表示该块是使用固定的霍夫曼码压缩的。

这是最简单的部分。解码压缩块的其余部分更加困难（并且对于更现实的示例来说，更加困难）。正确解释如何做到这一点会使这个网站的答案太长（而且你的问题太宽泛）。不过，我会给你一个提示，数据中接下来的三个元素是霍夫曼代码 10010001（'a'）、00111010（'\n'）和 0000000（流结束）。其余 6 位未使用，不属于压缩数据。

注意要了解如何解码压缩数据，您必须了解Huffman codes 是什么。您遵循的 RFC 假定您这样做。您还应该知道 LZ77 compression 的工作原理，尽管该文档或多或少地解释了您需要了解的内容。