什么会导致GZipStream压缩数据过零填充？

Question

我正在使用.NET框架内的GZipStream类压缩一些数据包。一切正常，压缩比也没问题，但是当我使用十六进制编辑器查看压缩数据时，我注意到每个压缩数据包中有三分之一是尾随零。这是正常的吗？

据推测，GZipStream是一个基于块的压缩器，输出被填充以与某些块大小对齐？是否存在一些同样稳定的替代方案，但是没有这个问题？ （我想通过使用类似的压缩算法，我可以获得另外10-30％的压缩，但不会过度填充）。

Answer 1

使用GZipStream不应添加过多的尾随零。

但如果您错误地使用MemoryStream，则可能会导致此效果。它在内部使用byte[]来存储数据。此内部缓冲区可能比目前写入的数据大，以减少分配数量。如果你使用GetBuffer()就可以获得完整的数组，那么你自己的责任就是只使用它的第一个Length字节。

或者，您可以调用ToArray()，它返回一个精确Length个字节的新字节数组。

引用GetBuffer()的文档：

  

请注意，缓冲区包含可能未使用的已分配字节。例如，如果将字符串"test"写入MemoryStream对象，则从GetBuffer返回的缓冲区长度为256，而不是4，未使用252个字节。要仅获取缓冲区中的数据，请使用ToArray方法;但是，ToArray会在内存中创建数据的副本。

Answer 2

gzip格式没有尾随零。除了小文件最多三个尾随零字节外，因为未压缩数据的长度（模2 ³² ）最后存储为四字节小端整数。

还有其他东西将那些零点放在那里。