我正在编写一个需要解压缩由另一个应用程序压缩的数据的应用程序（这超出了我的控制 - 我无法更改它的源代码）。生产者应用程序使用 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
...这是同步或完全刷新的签名。
当我尝试使用该函数解压缩自己的数据时decompress()，一切正常。但是，当我尝试解压缩外部数据时，decompress()函数调用失败，返回码为Z_DATA_ERROR，表示数据损坏。
我有几个问题：
我是否应该能够使用 zlib“解压缩”功能来解压缩使用 z_stream 方法压缩的数据？
在上面的例子中，最后四个字节的意义是什么？假设外部压缩的数据流和我自己的测试数据流的长度相同，那么我的最后四个字节代表什么？
干杯