compression - zlib解压失败

Question

我正在编写一个应用程序，该应用程序需要解压缩由另一个应用程序压缩的数据(这超出了我的控制 - 我无法更改它的源代码)。生产者应用程序使用 zlib 使用 z_stream 机制压缩数据。它经常使用 Z_FULL_FLUSH(在我看来，可能过于频繁，但这是另一回事)。这个第三方应用程序也能够解压缩它自己的数据，所以我非常有信心数据本身是正确的。

在我的测试中，我使用这个第三方应用程序来压缩以下简单的文本文件(十六进制):
48 65 6c 6c 6f 20 57 6f 72 6c 64 21 0d 0a
我从应用程序收到的压缩字节如下所示(同样，以十六进制表示):
78 9c f2 48 cd c9 c9 57 08 cf 2f ca 49 51 e4 e5 02 00 00 00 ff ff
如果我尝试压缩相同的数据，我会得到非常相似的结果:
78 9c f3 48 cd c9 c9 57 08 cf 2f ca 49 51 e4 e5 02 00 24 e9 04 55
我可以看到两个不同之处:

首先，第四个字节是F2 ，而不是 F3 ，因此放气“最终 block ”位尚未设置。我认为这是因为流接口(interface)永远不知道传入数据何时结束，所以永远不要设置那个位？

最后，外部数据中的最后四个字节是00 00 FF FF ，而在我的测试数据中它是 24 E9 04 55 .在此页面上搜索我发现

http://www.bolet.org/~pornin/deflate-flush.html

...这是同步或完全刷新的签名。

当我尝试使用 decompress() 解压缩我自己的数据时功能，一切正常。但是，当我尝试解压缩外部数据时，decompress()函数调用失败，返回码为 Z_DATA_ERROR ，表示数据损坏。

我有几个问题:

我是否应该能够使用 zlib“解压缩”功能来解压缩使用 z_stream 方法压缩的数据？

在上面的例子中，最后四个字节的意义是什么？假设外部压缩的数据流和我自己的测试数据流的长度相同，那么我的最后四个字节代表什么？

干杯

Answer 1

感谢 zlib 作者，我找到了答案。第三方应用程序正在生成未正确完成的 zlib 流:

78 9c f2 48 cd c9 c9 57 08 cf 2f ca 49 51 e4 e5 02 00 00 00 ff ff

那是部分 zlib 流，
由一个 zlib 头文件和一个
部分放气流。那里有两个
block ，都不是最后一个
堵塞。第二 block 是空的
存储 block ，用作标记时
冲洗。 zlib 解码器将
正确解码那里的内容，并且
之后继续找资料
那些字节。

78 9c f3 48 cd c9 c9 57 08 cf 2f ca 49 51 e4 e5 02 00 24 e9 04 55

那是一个完整的 zlib 流，
由一个 zlib 头文件、一个单一的
标记为最后一个 block 的 block ，以及
zlib 拖车。预告片是
未压缩的 Adler-32 校验和
数据。

所以我的解压失败了——可能是因为缺少 CRC，或者解压代码一直在寻找更多不存在的数据。