C 充气减压操作成功，无需处理完整的压缩数据

我正在使用软件充气方法（原始放气方法，而不是GZIP/ZLIB变体）进行解压缩操作

奇怪的是，我注意到了以下几点

1.）当我传入单个压缩缓冲区（avail_in和next_in字段）作为源数据，传入单个目标缓冲区（avail_out和next_out）作为解压缩输出时，充气解压缩操作成功，Z_STREAM_END状态为正。我还将其与原始未压缩数据进行了比较，并与之匹配

2.）但是，当我将压缩数据拆分为两个缓冲区时，一个缓冲区包含压缩数据减去一个字节（压缩数据大小-1），第二个缓冲区包含大小为1字节的数据，以及一个大小为原始未压缩长度的单目标缓冲区，充气解压缩操作成功，Z_OK肯定状态填写我的完整目标缓冲区（avail_out=0，total_out=原始未压缩大小）。我还将其与原始未压缩数据进行了比较，并与之匹配

我非常困惑为什么充气（）操作在不处理第二个源缓冲区的情况下成功地生成了所有原始数据。？这是充气操作的预期行为吗

---

3.）我还尝试了上述2种方法，将源数据拆分到2个缓冲区中，其中最后一个缓冲区的长度为2字节，1个源缓冲区的大小为压缩数据-2，并使用一个dest缓冲区。看到了与2相同的类似行为。

这种行为是预期的

膨胀数据是一个可变位长代码流，连接在一起形成字节流。单个代码单元没有字节对齐，压缩流通常不以字节边界结束。因此，压缩流的最后一个字节可能有一些未使用的位

压缩流不存储其长度。相反，其中一个代码单元用作流结束指示器。代码单元本身本质上是哈夫曼代码，因此最常见的是最短的。流结束指示器在流中只出现一次，因此其代码可能超过8位

因此，可以保证压缩流中的最后一个字节只包含流结束指示符，并且流结束指示符很可能还占用了整个第二个最后一个字节，以及第三个最后一个字节的一些位。（我很确定代码长度限制为16位，但我没有检查参考资料。）

---

每个代码单元对应于原始消息中的一个或多个字节，可以在不引用下一个代码单元的情况下重新生成这些字节。如果您解压缩到流结束之前的代码单元，那么您已经解压缩了整个文件；流结束指示器告诉您的唯一一件事就是您已经完成了

非常感谢。那么，你的意思是没有固定大小的蒸汽末端标记用于放气（充气）减压算法吗@user355515：从技术上讲，有三种数据块：未压缩、使用固定的哈夫曼代码压缩、使用动态计算的哈夫南代码压缩。大多数街区属于第三种类型。在这种情况下，代码项的长度将因块而异。