Heyo，
我有两个版本的网络库-一个原始版本，丢失了源代码-还有我的版本，这是一个较新的实现。在我的较新版本中，我使用的是zlib 1.2.5，然后更新为1.2.11。
此升级完全打破了压缩。较新的库不再能理解较旧库的输出，反之亦然。由于会有读者同时使用我的版本和旧版本的网络库，因此不适合。
我已经确认（压缩的）消息字节符合预期；正确的大小和数据，字节与发送的内容相同。为了确定，我已经在十六进制编辑器中对它们进行了比较。我唯一的结论是，图书馆发生了一些变化。
测试输入为：“这是测试二进制消息。” （ASCII，带有空字节终止符）
来自旧库的结果（可能是zlib 1.1.3）：
00000000: 1f00 0000 789c 0bc9 c82c 5600 a244 8592 ....x....,V..D..
00000010: d4e2 1285 a4cc bcc4 a24a 85dc d4e2 e2c4 .........J......
00000020: f454 3d06 00af cc0a ce .T=......
来自新库的结果（zlib 1.2.11）：
00000000: 78da 0bc9 c82c 5600 a244 8592 d4e2 1285 x....,V..D......
00000010: a4cc bcc4 a24a 85dc d4e2 e2c4 f454 3d06 .....J.......T=.
00000020: 00af cc0a ce .....
解压缩会产生“无效的块类型”或“不正确的标头检查”。
为了产生相同的压缩结果，我尝试遵循建议将MAX_WBITS弄乱的this post，但MAX_WBITS，-MAX_WBITS和MAX_WBITS + 16仍然会导致Z_DATA_ERROR和错误的输出大小（分别为37、31和49字节） ）。
我不确定它是deflate还是zlib，我检查了this post，但似乎没有一个完全匹配（最接近的是.z）。文档说“ zlib”，但是由于它是作为消息发送的单个二进制代码块，因此我认为它更可能使用原始deflate。
任何可能导致此问题的建议，我们将不胜感激。哦，还有here's my code。
结果是较旧的zlib-或较旧的网络库-压缩后的输出前面有一个32位的“未压缩输出”大小。在较新版本中复制该行为可使事情恢复正常并向后兼容。