我正在使用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（）操作成功生成所有原始数据而不处理第二个源缓冲区感到非常困惑？这是预期的行为吗？
3。）我还尝试了以上2种方法，将源数据拆分为2个缓冲区，其中最后一个缓冲区的长度为2个字节，1个源缓冲区的大小为压缩数据-2，并且具有单个dest缓冲区。 2。
答案 0 :(得分：0)
此行为是预期的。
膨胀的数据是可变位长的代码流，它们一起串联到字节流中。各个代码单元不是字节对齐的，并且压缩流通常不会在字节边界上结束。因此，压缩流的最后一个字节可能有几个未使用的位。
压缩流不存储其长度。而是将其中一个代码单元用作流结束指示符。代码单元本质上是霍夫曼代码，因此最常见的是最短的。流结束指示符仅在流中出现一次，因此其代码可能超过8位。
因此，可以确保压缩流中的最后一个字节仅包含流结束指示符，并且很有可能流结束指示符也占据了整个倒数第二个字节，以及倒数第二个字节的几位。 （我很确定代码长度限制为16位，但是我没有检查参考资料。）
每个代码单元对应于原始消息中的一个或多个字节，并且可以在不参考下一个代码单元的情况下重新生成这些字节。如果解压缩到流末尾的代码单元，则已经解压缩了整个文件。流结束指示器告诉您的唯一一件事就是您已经完成。