Compression zlib解压失败

我正在编写一个应用程序，它需要解压缩由另一个应用程序压缩的数据（这不在我的控制范围内-我无法更改它的源代码）。producer应用程序使用zlib使用z_流机制压缩数据。它经常使用Z_FULL_FLUSH（在我看来，可能太频繁了，但那是另一回事）。这个第三方应用程序也能够解压缩自己的数据，所以我很有信心数据本身是正确的

在我的测试中，我使用这个第三方应用程序压缩以下简单文本文件（十六进制）：

48 65 6c 6c 6f 20 57 6f 72 6c 64 21 0d 0a

我从应用程序收到的压缩字节如下所示（同样，十六进制）：

78 9c F248 cd c9 c9 57 08 cf 2f ca 49 51 e4 e5 02 00 00 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

，因此未设置deflate“final block”位。我假设这是因为流接口永远不知道传入数据的结束时间，所以永远不会设置该位

最后，外部数据中的最后四个字节是

00 FF FF

，而在我的测试数据中是

24 E9 04 55

。搜索我在这页上找到的

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

当我尝试使用

decompress（）

函数对自己的数据进行解压缩时，一切都很正常。但是，当我尝试解压缩外部数据时，

decompress（）

函数调用失败，返回代码为

Z_data_ERROR

，表示数据已损坏

我有几个问题：

我应该能够使用zlib“uncompress”函数来解压缩用z_流方法压缩的数据吗

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

---

干杯

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

78 9c F248 cd c9 c9 57 08 cf 2f ca 49 51 e4 e5 02 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丢失，或者解压缩代码一直在寻找更多不存在的数据。

解决方案如下：

这是78 9C签名开始时的解压缩和压缩功能

---

压缩数据库blob（或stream）。

对此我没有任何线索，但您忘记添加到问题中的一个潜在相关信息是，zlib解压到底是如何失败的。谢谢-也添加了这一点。您的回答没有解决我的问题，但它确实带来了一个解决方案。结果我试图在流中间解压部分ZLIB流。您应该从流的开头开始解压，然后在块进入时追加块。（例如，使用Python的zlib.decompressobj（）.decompress（部分），如下所示：）