Zlib 兼容的压缩流?
System.IO. Compression.GZipStream 或 System.IO. Compression.Deflate 是否与 zlib 压缩兼容?
Are System.IO.Compression.GZipStream or System.IO.Compression.Deflate compatible with zlib compression?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(8)
DotNetZip 包括 DeflateStream、ZlibStream 和 GZipStream,用于处理 RFC 1950、1951 和 1952。 DEFLATE 算法,但每个算法的帧和头字节都不同。
作为一个优点,DotNetZip 中的流不会出现数据大小扩展的异常情况 在压缩下,根据内置流进行报告。 此外,没有内置的 ZlibStream,而 DotNetZip 为您提供了该功能,以便与 zlib 实现良好的互操作。
DotNetZip includes a DeflateStream, a ZlibStream, and a GZipStream, to handle RFC 1950, 1951, and 1952. The all use the DEFLATE Algorithm but the framing and header bytes are different for each one.
As an advantage, the streams in DotNetZip do not exhibit the anomaly of expanding data size under compression, reported against the built-in streams. Also, there is no built-in ZlibStream, whereas DotNetZip gives you that, for good interop with zlib.
来自 MSDN 关于 System.IO. Compression。 GZip 流:
来自 zlib 常见问题解答:
因此,zlib 和 GZipStream 应该是可互操作的,但前提是您使用 zlib 函数来处理 gzip 格式。
据报道,System.IO.Compression.Deflate 和 zlib 不可互操作。
如果您需要处理 zip 文件(您可能不需要,但其他人可能需要这个),您需要使用 SharpZipLib 或其他第三方库。
From MSDN about System.IO.Compression.GZipStream:
From the zlib FAQ:
So zlib and GZipStream should be interoperable, but only if you use the zlib functions for handling the gzip-format.
System.IO.Compression.Deflate and zlib are reportedly not interoperable.
If you need to handle zip files (you probably don't, but someone else might need this) you need to use SharpZipLib or another third-party library.
我使用 GZipStream 来压缩 .NET XmlSerializer 的输出,并且使用gunzip(在 cygwin 中)、winzip 和另一个 GZipStream 解压结果时效果非常好。
作为参考,这是我在代码中所做的:
然后,在 c# 中解压缩
使用 cygwin 中的“文件”实用程序表明,使用 GZipStream 和使用 GNU GZip 压缩的同一文件之间确实存在差异(可能是其他人所说的标头信息)在此线程中)。 然而,这种差异在实践中似乎并不重要。
I've used GZipStream to compress the output from the .NET XmlSerializer and it has worked perfectly fine to decompress the result with gunzip (in cygwin), winzip and another GZipStream.
For reference, here's what I did in code:
Then, to decompress in c#
Using the 'file' utility in cygwin reveals that there is indeed a difference between the same file compressed with GZipStream and with GNU GZip (probably header information as others has stated in this thread). This difference, however, seems to not matter in practice.
gzip 是 deflate + 一些页眉/页脚数据,例如校验和和长度等。因此,它们不兼容,因为一种方法可以使用来自另一种方法的流,但它们采用相同的压缩算法。
gzip is deflate + some header/footer data, like a checksum and length, etc. So they're not compatible in the sense that one method can use a stream from the other, but they employ the same compression algorithm.
他们只是使用 zlib 或 deflate 算法压缩数据,但不提供某些特定文件格式的输出。 这意味着,如果您将流按原样存储到硬盘驱动器,您很可能无法使用某些应用程序(gzip 或 winrar)打开它,因为文件头(幻数等)不包含在流中,您应该你自己写。
They just compressing the data using zlib or deflate algorithms , but does not provide the output for some specific file format. This means that if you store the stream as-is to the hard drive most probably you will not be able to open it using some application (gzip or winrar) because file headers (magic number, etc ) are not included in stream an you should write them yourself.
从 .NET Framework 4.5 开始,
System.IO.Compression.DeflateStream
类使用 zlib 库。来自课程的 MSDN 文章:
Starting from .NET Framework 4.5 the
System.IO.Compression.DeflateStream
class uses the zlib library.From the class's MSDN article:
我同意安德烈亚斯的观点。 您可能无法在外部工具中打开该文件,但如果该工具需要流,您也许可以使用它。 您还可以使用相同的压缩等级将文件放气。
I agree with andreas. You probably won't be able to open the file in an external tool, but if that tool expects a stream you might be able to use it. You would also be able to deflate the file back using the same compression class.
我在使用 Git 对象时遇到了这个问题。 在这种特殊情况下,它们将对象存储为带有 Zlib 标头的压缩 blob,该标头记录在 RFC 1950 中。 您可以通过创建包含以下内容的文件来创建兼容的 blob:
0x78 0x01
CM
= 8 = 放气CINFO
= 7 = 32Kb 窗口FCHECK
= 1 = 此标头的校验和位DeflateStream
DeflateStream
输入数据的 Adler32 校验和,大端格式(MSB 在前)我制作了自己的 Adler 实现
,仅此而已。
I ran into this issue with Git objects. In that particular case, they store the objects as deflated blobs with a Zlib header, which is documented in RFC 1950. You can make a compatible blob by making a file that contains:
0x78 0x01
CM
= 8 = deflateCINFO
= 7 = 32Kb windowFCHECK
= 1 = checksum bits for this headerDeflateStream
DeflateStream
, big-endian format (MSB first)I made my own Adler implementation
And that was pretty much it.