【问题标题】:One library for deflate, gzip, and zlib in .net.net 中用于 deflate、gzip 和 zlib 的一个库
【发布时间】:2010-09-10 00:27:43
【问题描述】:

首先,让我们定义一些容易混淆的术语:

deflate = compression_algorithm;
zlib = header + deflate + trailer;
gzip = header + deflate + trailer;

我正在寻找一个基本上可以让我执行以下操作的库:

if(method == "gzip"){
    Response.Filter = new CompressionLibrary.OutputStream(Response.Filter, CompressionLibrary.Formats.GZIP);
}
else if(method == "deflate"){
    Response.Filter = new CompressionLibrary.OutputStream(Response.Filter, CompressionLibrary.Formats.DEFLATE);
}
else if(method == "zlib"){
    Response.Filter = new CompressionLibrary.OutputStream(Response.Filter, CompressionLibrary.Formats.ZLIB);
}

我正在寻找一种方法来比较测试这 3 种压缩格式以供在网络上使用。我希望每种格式的 deflate 压缩算法都是相同的精确实现。我已经破解了 zlib.net 以强制它在命令上给我原始的 deflate(通过“未记录的功能”)......但是,添加 gzip 标头和预告片有点超出我的范围。

任何人都知道这样做的 .net 库吗?


澄清:

HTTP 1.1 的deflate 压缩format 实际上是zlib 压缩格式。 Zlib 是 deflate 的包装器;它有一个 2 字节的头部和一个 4 字节的尾部,总是(当压缩方法和级别相同时)。

Gzip 在内部使用与 zlib 相同的压缩数据格式...这是 deflate(原始 deflate,而不是 HTTP 1.1 deflate [即 zlib])。根据我自己的初步测试,gzip 压缩后的数据比 zlib 大 12 倍中的 11 倍。

deflate 是一种用于压缩数据的压缩算法。当压缩数据周围没有包装方法(例如,标题或尾部)时,我将其称为“deflate” - 也许我应该将其称为 “raw deflate”

我正在分析这些压缩方法及其在 Web 浏览器中的支持,并且需要对所有三种类型使用一种压缩方法。

【问题讨论】:

  • 您的意思是“deflate”作为压缩算法,还是作为压缩方法?请注意,如果您正在谈论方法,则 deflate==zlib(请参阅:gzip.org/zlib/zlib_faq.html#faq38)我不清楚您是否有 3 个案例要处理,或者 2 个。在后一种情况下,System.IO.Compression 类是否有效?
  • 您要确定什么? zlib 只是 deflate 压缩方法 (RFC 1951) 和 gzip 文件格式 (RFC 1952) 的实现。比较 gzip 和 zlib 是没有意义的。或者您是否尝试将 gzip 和 deflate 的 .NET 实现与 gzip 和 deflate 的 zlib 实现进行比较?
  • 我从定义开始,因为这些术语经常被混淆。当提到 deflate 我不是在谈论 HTTP 1.1 deflate(那将是 zlib 格式:zlib.net/zlib_faq.html#faq39)。我会在我的问题中澄清。

标签: .net compression gzip zlib deflate


【解决方案1】:

DotNetZip 执行 RFC 1950 (ZLIB)RFC 1951 (DEFLATE)RFC 1952 (GZIP)。 它对所有三个都使用相同的底层压缩引擎。

DotNetZip 也可以处理 ZIP 文件。

【讨论】:

  • +1 谢谢!我刚刚在 codeplex 上向 Cheeso 发送了一条关于主页上的错字没有意识到您是 Cheeso 的消息。 :-D 你看过我对here这个主题的研究吗?
  • 另外,您能否验证使用 DotNetZip 的 DEFLATE 压缩方法时没有计算校验和?
  • 如果使用 DeflateStream 类,则不计算 CRC32。如果使用 GZipStream,则计算出 CRC32。我不记得 ZLIB 是否需要校验和,但从记忆中我认为 ZLIB 需要一个经过计算的 Adler32。而且,不,我还没有看到你的研究。我去看看。
【解决方案2】:

根据我对标准文档的阅读以及我对 zlib、.NET gzip 和 deflate 实现以及其他几个 .NET 压缩包所做的工作,我确定:

1) “raw deflate”总是小于你所说的“HTTP 1.1 deflate”,它总是小于 gzip。假设您使用相同的库来生成所有三个。也就是说,对于任何特定的压缩库,deflate

2) 大小差异非常小。 deflate 和 zlib 之间的区别通常只有几个字节。 deflate 和 gzip 之间的区别最多只有几十个字节。无论文件大小如何,都是如此。

3) 不同的 deflate 实现具有广泛不同的压缩率和执行时间。例如,zlib 实现比 .NET 3.5 实现提供更好的压缩和更快的执行速度。

4) 不同实现之间的互操作性几乎是 100%。也就是说,由一个库创建的 deflate(或 gzip)文件可以由任何其他库解压缩。我听说过这种情况不正确,但我无法构建一个。

5) 由于 CRC 计算,创建 gzip 比创建 zlib 需要更长的时间。

我不知道有哪个 C# 库可以让您根据原始 deflate 数据生成 zlib 或 gzip 文件,但如果您研究标准文档,应该能够相当容易地构建它们。

我也不知道有任何浏览器支持“原始放气”。但是,我不能说我实际上已经尝试过了。我一直使用“HTTP 1.1 deflate”。

【讨论】:

  • 谢谢,这证实了我一直在努力推广的一切。而且,您实际上使用的是原始 deflate,而不是 HTTP 1.1 deflate(除非您不喜欢 IE 用户,以至于您不会向他们发送充气数据)。 :-) 详情请见this answer
  • 我发现 CRC 计算在压缩所需时间上产生了重大差异,这非常令人惊讶。 DEFLATE 是底层算法,它使用霍夫曼编码加上 LZ77。这些是 CPU 密集型的;特别是 LZ77 通过滑动窗口搜索匹配项。 CRC 计算需要对已经压缩的数据进行 XOR,这比压缩花费的时间要少得多。 CRC 不是“免费”的,但我相信对于任何不重要的压缩有效负载,与压缩时间相比,它应该非常小。
  • 我希望看到重现您所描述的显着差异的代码。一种可能性是,在 HTTP 服务器场景中测量压缩时,如果数据经过 CRC,服务器会缓冲数据,如果不需要 CRC,则不缓冲。这可能会导致延迟差异,但原因不是 CRC 操作?*本身*,而是缓冲。
  • @Cheeso:我也对此感到非常惊讶,但我的结果是可重复的。我在这里发布了它们:informit.com/guides/content.aspx?g=dotnet&seqNum=615。请理解,那是 2007 年 10 月,使用当时流行的任何 .NET 风格。我不知道今天会是什么样子。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2021-07-24
  • 2018-07-15
  • 2011-06-11
  • 1970-01-01
  • 2011-09-04
  • 2013-05-05
  • 2017-11-08
相关资源
最近更新 更多