我正在使用Software Inflate方法（原始deflate方法，而不是GZIP / ZLIB变体）进行解压缩操作。
奇怪的是，我注意到了以下令人讨厌的地方
1。）当我传递单个压缩缓冲区（avail_in和next_in字段）作为源数据和单个目标缓冲区（avail_out和next_out）以进行减压输出时，充气式减压操作以Z_STREAM_END为正状态成功完成。我还将此与原始未压缩的数据及其匹配项进行了比较。
2。）但是，当我将压缩数据分成两个缓冲区时，一个压缩数据缓冲区减去一个字节（压缩数据大小-1），第二个缓冲区大小为1字节，并且一个目标缓冲区大小为原始未压缩的大小长度上，z_OK肯定状态填充了我完整的目标缓冲区（avail_out = 0且total_out =原始未压缩大小）后，膨胀解压操作成功完成。我还将此与原始未压缩的数据及其匹配项进行了比较。
我对为什么inflate（）操作在不处理第二个源缓冲区的情况下成功生成所有原始数据感到非常困惑。这是使用inflate操作的预期行为吗？
3。）我还尝试了以上2种方法，将源数据分成2个缓冲区，最后一个缓冲区的长度为2个字节，1个源缓冲区的大小为压缩数据-2，并且只有一个目标缓冲区。之2。
此行为是预期的。
膨胀的数据是可变位长的代码流，它们一起串联到字节流中。各个代码单元不是字节对齐的，并且压缩流通常不会在字节边界上结束。因此，压缩流的最后一个字节可能有一些未使用的位。
压缩流不存储其长度。而是将其中一个代码单元用作流结束指示符。代码单元本质上是霍夫曼代码，因此最常见的是最短的。流结束指示符仅在流中出现一次，因此其代码可能超过8位。
因此，可以确保压缩流中的最后一个字节仅包含流结束指示符，并且流结束指示符很有可能也占据了整个倒数第二个字节，以及一些倒数第二个字节的位。 （我很确定代码长度限制为16位，但是我没有检查参考资料。）
每个代码单元对应于原始消息中的一个或多个字节，并且可以在不参考下一个代码单元的情况下重新生成这些字节。如果解压缩到流末尾的代码单元，则已经解压缩了整个文件；流结束指示器告诉您的唯一一件事就是您已经完成。