gzip和deflate

注：我对压缩领域的各种概念一知半解，请以怀疑的态度阅读此文。

zlib支持两种封装格式：gzip和zlib stream。二者都是对deflate压缩算法的封装。

HTTP1.1(rfc2616)里的gzip就代表gzip，而deflate则代表zlib stream，并非raw deflate。

目前IE6,7,8宣称支持的deflate(即请求头里的Accpet-Encoding)，是raw deflate，而不是zbli stream封装过的deflate。即是说，IE6,7,8目前是不支持http1.1里的deflate的。（本段所述来自：http://en.wikipedia.org/wiki/Gzip#Other_uses，本人未做测试）

我们可以说IE是不支持rfc2616标准的，这已经司空见惯了。但是退一步说，HTTP1.1对deflate的定义，也不是一个准确的定义。我认为它应该使用”zlib”这个词，而不是”deflate”。

不过实际上，用zlib，还是会有混淆。因为如段一所述，zlib这个库实际上支持两种格式，gzip和zlib stream。但是用zlib至少比用deflate好吧？而且根据我的判断，zlib最初的设计，是为了封装各种压缩算法，而不仅仅是deflate，虽然目前只支持deflate。

之所以去了解这个，是因为需要对一批c#压缩的数据进行批量解压，发现了类似的情况。最诡异的是，似乎情况还是相反的。根据对方的代码来看，是用了c#的deflate类压缩，但是数据都是zlib stream。这是为什么？有玩C#的朋友给出解释吗？

另外提两个东西：
1）rfc2616还支持第三种压缩格式”compress“，它实际上也是对deflate的封装修正：compress是不同于deflate的一种算法。大多数浏览器都没支持这个压缩格式。
2）以前chrome刚推出的时候，我提到过chrome支持bzip2压缩格式(抱歉，因gfans挂了，我无法链此文)。我当时质疑为什么其他主流浏览器不支持。现在我明白了，因为rfc2616里没定义。我现在反而觉得chrome不应该支持这个算法了，因为一没web server支持，二不遵从标准。当然我也知道很多情况下事实标准会引导着标准走，在未来几年里bzip2进入新版的http协议里也说不定。