.net net中一个用于deflate、gzip和zlib的库

首先，让我们定义一些常见的混淆术语：

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种压缩格式，以便在web上使用。我希望每种格式的deflate压缩算法都是相同的实现。我已经入侵了zlib.net，强迫它在命令时给我原始的deflate（通过一个“未记录的特性”）……然而，添加gzip头和预告片在我的能力范围之内

有谁知道一个.net库可以做到这一点

---

澄清：

HTTP 1.1的deflate压缩格式实际上是zlib压缩格式。Zlib是一个包裹着deflate的包装器；它有一个2字节的头部和一个4字节的尾部，始终（当压缩方法和级别相同时）

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

deflate是一种用于压缩数据的压缩算法。当泄密数据周围没有包装器方法（例如，标题或拖尾）时，我将其称为“泄密”-也许我应该将其称为“原始泄密”

---

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

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

1） “原始deflate”总是小于您所称的“HTTP1.1deflate”，后者总是小于gzip。假设您使用相同的库来生成所有三个。也就是说，对于任何特定的压缩库，deflate 2） 大小的差异非常小。deflate和zlib之间的差异通常只有几个字节。deflate和gzip之间的差异最多只有几十个字节。无论文件大小如何，这都是正确的

3） 不同的deflate实现具有广泛不同的压缩比和执行时间。例如，zlib实现比.NET3.5实现提供了更好的压缩和更快的执行

4） 不同实现之间的互操作性几乎是100%。也就是说，由一个库创建的deflate（或gzip）文件可以由任何其他库解压缩。我听说过这样的案例，但我无法构建一个

5） 由于CRC计算，创建gzip比创建zlib需要更长的时间

我不知道有哪种C#库允许您在给定原始deflate数据的情况下生成zlib或gzip文件，但是如果您研究标准文档，您应该能够相当轻松地构建它们

我也不知道有哪个浏览器支持“原始deflate”。但是，我不能说我真的试过。我一直使用“HTTP 1.1 deflate”。

确实如此，而且。 这三种方法都使用相同的底层压缩引擎

---

DotNetZip也处理ZIP文件。

您是指压缩算法中的“deflate”，还是压缩方法中的“deflate”？请注意，如果您谈论的是方法，deflate==zlib（请参阅：），我不清楚您是否有3个案例要处理，或者2个。在后一种情况下，System.IO.Compression类可以工作吗？您想确定什么？zlib只是deflate压缩方法（rfc1951）和gzip文件格式（rfc1952）的一个实现。比较gzip和zlib是没有意义的。或者您是在尝试将gzip和deflate的.NET实现与gzip和deflate的zlib实现进行比较？我从定义开始，因为这些术语经常混淆。当提到deflate时，我并不是说HTTP1.1deflate（这将是zlib格式：）。我会在我的问题中澄清。谢谢，这证实了我一直在努力推广的一切。实际上，您使用的是原始的deflate，而不是HTTP 1.1 deflate（除非您非常不喜欢IE用户，以至于不会向他们发送充气数据）。：-）有关详细信息，请参阅。我发现CRC计算在压缩所需的时间上产生了重大差异，这一点非常令人惊讶。DEFLATE是底层算法，它使用哈夫曼编码加LZ77。这些是cpu密集型的；特别是LZ77通过滑动窗口搜索匹配项。CRC计算需要对已经压缩的数据进行异或运算，这比压缩所需的时间要少得多。CRC不是“免费”的，但我相信它与压缩时间相比应该是非常小的，对于任何非不重要的压缩负载。我想看看能重现您描述的显著差异的代码。一种可能性是，在HTTP服务器场景中测量压缩时，如果数据是CRC，服务器将缓冲数据，如果不需要CRC，则不缓冲数据。这可能会导致延迟差异，但原因不是CRC操作本身，而是缓冲。@Cheeso:我也很惊讶，但我的结果是可重复的。我在这里发布了它们：。要知道，那是2007年10月，使用的是当时的.NET风格。我不知道今天会是什么样子。+1谢谢！我刚刚在codeplex上给Cheeso发了一条消息，说主页上有一个打字错误，没有意识到你是Cheeso-D你看过我关于这个主题的研究了吗？另外，你能验证一下，当使用DotNetZip的DEFLATE压缩方法时，没有计算校验和吗？如果你使用DeflateStream类，没有计算CRC32。如果使用GZipStream，则会计算CRC32。我记不起ZLIB是否需要校验和，但从内存来看，我不需要校验和