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，因此没有设置“最终块”位。我认为这是因为流接口永远不知道传入数据的结束时间，所以从来不设置该位？

最后，外部数据中的最后四个字节是00 00 FF FF，而在我的测试数据中是24 E9 04 55。我在这页上找到的

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

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

当我尝试使用decompress()函数解压缩自己的数据时，一切都很完美。但是，当我尝试解压缩外部数据时，decompress()函数调用将失败，返回代码为Z_DATA_ERROR，表示数据损坏。

我有几个问题：

1. 应该能够使用zlib“解压缩”函数来解压缩使用z_stream方法压缩的数据吗?在上面的示例中，
2. ，最后四个字节的意义是什么？假设外部压缩的数据流和我自己的测试数据流都是相同的长度，那么最后四个字节代表什么呢？

干杯

Answer 1

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

78 9c f2 48 cd c9 c9 57 08 cf2f约49 51 e4 e5 02 00 00 ff，即部分zlib流，由zlib头和部分放气流组成。有两个街区，两个街区都不是最后一个街区。第二个块是一个空存储块，在冲洗时用作标记。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头、一个标记为最后一个块的块和一个zlib拖车组成。拖车是未压缩数据的Adler-32校验和。

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

Answer 2

解决方案在这里：http://technology.amis.nl/2010/03/13/utl_compress-gzip-and-zlib/

这是从78 9C签名压缩数据库blob (或流)开始的解压缩和压缩功能。