33

如果我 GZip 这个文本：

你好世界

通过 C# 使用此代码：

Stream stream = new MemoryStream(Encoding.Default.GetBytes("Hello World"));
var compressedMemoryStream = new MemoryStream();
using (var gzipStream = new GZipStream(compressedMemoryStream, CompressionMode.Compress))
{
    stream.CopyTo(gzipStream);  
    gzipStream.Close(); 
}

结果流为 133 字节长

通过 FiddlerUtilities.GzipCompress或这个 PHP 页面运行相同的字符串，结果只有 31 个字节长。

在这两种情况下，输入都是 11 个字节，所以我认为 PHP 结果是正确的，但显然这意味着我无法从 .NET 中解压缩 PHP zip，反之亦然。为什么 .NET 输出要大得多？

实际上事实证明，虽然 PHP 和 Fiddler 的结果长度相同，但它们并不相同。我可以在 .NET 中解压 PHP 版本，但不能解压 Fiddler 版本。PHP 页面解压缩了所有三个，因此看起来 Fiddler 和 .NET 的 gzip 实现之间可能存在不兼容。

根据要求，我已将三个输出上传到此处的保管箱。

这些是这些文件的原始十六进制转储（不确定它们是否真的有这样的用途，但我认为这表明提琴手和 PHP 版本之间的区别在于标头，而不是压缩数据本身）：

提琴手：

0000-0010:  1f 8b 08 00-c2 e6 ff 4f-00 ff f3 48-cd c9 c9 57  .......O ...H...W
0000-001f:  08 cf 2f ca-49 01 00 56-b1 17 4a 0b-00 00 00     ../.I..V ..J....

PHP：

0000-0010:  1f 8b 08 00-00 00 00 00-00 03 f3 48-cd c9 c9 57  ........ ...H...W
0000-001f:  08 cf 2f ca-49 01 00 56-b1 17 4a 0b-00 00 00     ../.I..V ..J....

C＃：

0000-0010:  1f 8b 08 00-00 00 00 00-04 00 ec bd-07 60 1c 49  ........ .....`.I
0000-0020:  96 25 26 2f-6d ca 7b 7f-4a f5 4a d7-e0 74 a1 08  .%&/m.{. J.J..t..
0000-0030:  80 60 13 24-d8 90 40 10-ec c1 88 cd-e6 92 ec 1d  .`.$..@. ........
0000-0040:  69 47 23 29-ab 2a 81 ca-65 56 65 5d-66 16 40 cc  iG#).*.. eVe]f.@.
0000-0050:  ed 9d bc f7-de 7b ef bd-f7 de 7b ef-bd f7 ba 3b  .....{.. ..{....;
0000-0060:  9d 4e 27 f7-df ff 3f 5c-66 64 01 6c-f6 ce 4a da  .N'...?\ fd.l..J.
0000-0070:  c9 9e 21 80-aa c8 1f 3f-7e 7c 1f 3f-22 be 9d 97  ..!....? ~|.?"...
0000-0080:  65 95 7e b7-aa cb d9 ff-13 00 00 ff-ff 56 b1 17  e.~..... .....V..
0000-0085:  4a 0b 00 00-00
4

5 回答 5

76

前言： .NET 用户在任何情况下都不应使用 Microsoft 提供的 GZipStream 或 DeflateStream 类，除非 Microsoft 将它们完全替换为可用的东西。 请改用DotNetZip 库。

前言更新： .NET Framework 4.5 及更高版本修复了压缩问题，GZipStream 和 DeflateStream 在这些版本中使用 zlib。我不知道下面提到的 CRC 问题是否已修复。

另一个更新： CRC问题不仅没有修复，而且微软已经决定他们不会修复它！

这是 GZipStream 中的几个错误之一。任何自尊的 gzip 压缩器都不应该从 11个字节的输入中产生 133 个字节的输出。请参阅我在为什么 BCL GZipStream（带有 StreamReader）不能可靠地检测 CRC32 的数据错误？.

内部发生的情况是 GZipStream 没有使用静态或存储方法，这两种方法都会产生与输入数据大小相同的压缩数据（在其之上将添加 18 个字节的 gzip 标头和尾标）。相反，它使用的是动态方法，该方法为极少数代码创建了一个非常大的代码描述符头。这只是一个错误/非常糟糕的实现。

更新：

通过十六进制转储，我可以提供一些分析。首先，Fiddler 和 php 的输出都是正确和正确的。它们之间的唯一区别在于 gzip 标头，特别是在 Fiddler 中设置但在 php 中没有设置的时间戳，以及在 php 中设置但不在 Fiddler 中设置的原始操作系统。对于这两个 13 字节的压缩数据是相同的，并且可以表示为（使用我的infgen 程序来反汇编 deflate 流）：

last
static
literal 'Hello World
end

这正是它应该的样子。单个静态块，不需要代码描述符，只需将所有字节编码为文字。（没有与长度和距离匹配的先前字符串。）

另一方面，GZipStream 的输出在几个方面都是一团糟。压缩后的数据是：

dynamic
code 3 5
code 4 5
code 5 4
code 6 4
code 7 4
code 8 3
code 9 3
code 10 4
code 11 4
code 12 4
code 13 4
code 14 3
code 16 3
litlen 0 14
litlen 1 14
litlen 2 14
litlen 3 14
litlen 4 14
litlen 5 14
litlen 6 14
litlen 7 14
litlen 8 14
litlen 9 12
litlen 10 6
litlen 11 14
litlen 12 14
litlen 13 14
litlen 14 14
litlen 15 14
litlen 16 14
litlen 17 14
litlen 18 14
litlen 19 14
litlen 20 14
litlen 21 14
litlen 22 14
litlen 23 14
litlen 24 14
litlen 25 14
litlen 26 14
litlen 27 14
litlen 28 14
litlen 29 14
litlen 30 13
litlen 31 14
litlen 32 6
litlen 33 14
litlen 34 10
litlen 35 12
litlen 36 14
litlen 37 14
litlen 38 13
litlen 39 10
litlen 40 8
litlen 41 9
litlen 42 11
litlen 43 10
litlen 44 7
litlen 45 8
litlen 46 7
litlen 47 9
litlen 48 8
litlen 49 8
litlen 50 8
litlen 51 9
litlen 52 8
litlen 53 9
litlen 54 10
litlen 55 9
litlen 56 8
litlen 57 9
litlen 58 9
litlen 59 8
litlen 60 9
litlen 61 10
litlen 62 8
litlen 63 14
litlen 64 14
litlen 65 8
litlen 66 9
litlen 67 8
litlen 68 9
litlen 69 8
litlen 70 9
litlen 71 10
litlen 72 11
litlen 73 8
litlen 74 11
litlen 75 14
litlen 76 9
litlen 77 10
litlen 78 9
litlen 79 10
litlen 80 9
litlen 81 12
litlen 82 9
litlen 83 9
litlen 84 9
litlen 85 10
litlen 86 12
litlen 87 11
litlen 88 14
litlen 89 14
litlen 90 12
litlen 91 11
litlen 92 14
litlen 93 11
litlen 94 14
litlen 95 14
litlen 96 14
litlen 97 6
litlen 98 7
litlen 99 7
litlen 100 7
litlen 101 6
litlen 102 8
litlen 103 8
litlen 104 7
litlen 105 6
litlen 106 12
litlen 107 9
litlen 108 6
litlen 109 7
litlen 110 7
litlen 111 6
litlen 112 7
litlen 113 13
litlen 114 6
litlen 115 6
litlen 116 6
litlen 117 7
litlen 118 8
litlen 119 8
litlen 120 9
litlen 121 8
litlen 122 11
litlen 123 13
litlen 124 12
litlen 125 13
litlen 126 13
litlen 127 14
litlen 128 14
litlen 129 14
litlen 130 14
litlen 131 14
litlen 132 14
litlen 133 14
litlen 134 14
litlen 135 14
litlen 136 14
litlen 137 14
litlen 138 14
litlen 139 14
litlen 140 14
litlen 141 14
litlen 142 14
litlen 143 14
litlen 144 14
litlen 145 14
litlen 146 14
litlen 147 14
litlen 148 14
litlen 149 14
litlen 150 14
litlen 151 14
litlen 152 14
litlen 153 14
litlen 154 14
litlen 155 14
litlen 156 14
litlen 157 14
litlen 158 14
litlen 159 14
litlen 160 14
litlen 161 14
litlen 162 14
litlen 163 14
litlen 164 14
litlen 165 14
litlen 166 14
litlen 167 14
litlen 168 14
litlen 169 14
litlen 170 14
litlen 171 14
litlen 172 14
litlen 173 14
litlen 174 14
litlen 175 14
litlen 176 14
litlen 177 14
litlen 178 14
litlen 179 14
litlen 180 14
litlen 181 14
litlen 182 14
litlen 183 14
litlen 184 14
litlen 185 14
litlen 186 14
litlen 187 14
litlen 188 14
litlen 189 14
litlen 190 14
litlen 191 14
litlen 192 14
litlen 193 14
litlen 194 14
litlen 195 14
litlen 196 14
litlen 197 14
litlen 198 14
litlen 199 14
litlen 200 14
litlen 201 14
litlen 202 14
litlen 203 14
litlen 204 14
litlen 205 14
litlen 206 14
litlen 207 14
litlen 208 14
litlen 209 14
litlen 210 14
litlen 211 14
litlen 212 14
litlen 213 14
litlen 214 14
litlen 215 14
litlen 216 14
litlen 217 14
litlen 218 14
litlen 219 14
litlen 220 14
litlen 221 14
litlen 222 14
litlen 223 14
litlen 224 14
litlen 225 14
litlen 226 14
litlen 227 14
litlen 228 14
litlen 229 14
litlen 230 14
litlen 231 14
litlen 232 14
litlen 233 14
litlen 234 14
litlen 235 14
litlen 236 14
litlen 237 14
litlen 238 14
litlen 239 14
litlen 240 14
litlen 241 14
litlen 242 14
litlen 243 13
litlen 244 13
litlen 245 13
litlen 246 14
litlen 247 13
litlen 248 14
litlen 249 13
litlen 250 14
litlen 251 13
litlen 252 14
litlen 253 14
litlen 254 14
litlen 255 14
litlen 256 14
litlen 257 4
litlen 258 3
litlen 259 4
litlen 260 4
litlen 261 4
litlen 262 5
litlen 263 5
litlen 264 5
litlen 265 5
litlen 266 5
litlen 267 6
litlen 268 6
litlen 269 5
litlen 270 6
litlen 271 7
litlen 272 8
litlen 273 8
litlen 274 9
litlen 275 10
litlen 276 9
litlen 277 10
litlen 278 12
litlen 279 11
litlen 280 12
litlen 281 14
litlen 282 14
litlen 283 14
litlen 284 12
litlen 285 11
dist 0 6
dist 1 10
dist 2 11
dist 3 11
dist 4 9
dist 5 8
dist 6 8
dist 7 8
dist 8 7
dist 9 7
dist 10 5
dist 11 6
dist 12 4
dist 13 5
dist 14 4
dist 15 5
dist 16 4
dist 17 5
dist 18 4
dist 19 4
dist 20 4
dist 21 4
dist 22 4
dist 23 4
dist 24 4
dist 25 5
dist 26 4
dist 27 5
dist 28 5
dist 29 5
literal 'Hello World
end
!
last
stored
end

那是什么？实际数据只是靠近“literal 'Hello World”结尾的那一行，它只是对输入的每个字节进行编码。前面是对一组用于文字、长度和距离的霍夫曼代码的描述。以下是它的问题：

  • 首先，它根本不应该使用动态。描述这组代码大约需要 100 个字节。这正是为什么 deflate 格式提供了一组用于静态块的预定义代码的原因。在这种情况下，压缩器应该选择一个静态块（这是 php 和 Fiddler 正在做的）。
  • 其次，定义了每一个可能的代码，即使绝大多数从未使用过！使用动态块时，适当的压缩器只会定义该块中实际使用的文字、长度和距离的代码。在这种情况下，没有使用长度或距离，只使用了八种不同的文字（H、e、l、o、空格、w、r 和 d）。相反，它继续定义 256 个文字代码、29 个长度代码和 30 个距离代码。我猜一些实验会表明 GZipStream 的动态标头总是相同的，在这种情况下它甚至不是动态的，这就是重点！
  • 第三，它最后会抛出一个不必要的空存储块。第一个块应该被标记为最后一个块。

所有这些都指向一个简单的事实，即编写此 GZipStream 代码的人，尽可能礼貌地说，对 deflate 格式或一般压缩缺乏任何了解。他们选择只生成动态块（最后一个空的静态块除外），每次只生成相同的动态标题（我认为），违背了动态块的目的，并且不费心去弄清楚当前是否块是最后一个，需要放一个空块来标记结束。

如其他地方所述，这些并不是 GZipStream 的唯一问题。它甚至无法正确使用 CRC-32 来检测损坏的流。

真正令人困惑的不是微软为什么指派一个不称职的人来编写 gzip 压缩器和解压器，而是为什么他们指派任何人来编写它！有一个免费可用的代码zlib，它具有极其自由的许可证，允许商业使用而无需署名。这段代码已经被广泛部署了近二十年，并且完成了它应该正确有效地完成的所有事情。大多数其他东西都使用zlib，包括php，我也怀疑Fiddler。

于 2012-07-11T15:18:04.240 回答
2

GZipStream如RFC 1952 规范中所述，将 10 字节的标头和 8 字节的页脚添加到压缩数据中。这给出了 133 字节长的结果。

如果要求 ( GZIP-compatible encoding?)，您链接到的 PHP 页面也会添加相同的 18 字节页眉/页脚。如果你使用它，它会给出一个 31 字节长的结果。

如果没有页眉/页脚，它们之间的差异是 125 字节与 13 字节。

于 2012-07-11T15:11:04.053 回答
2

无论您向 GZipStream 提供什么内容，您都会获得相同的开销。GZipStream 的前 108 个字节看起来相同

1f 8b 08 00 00 00 00 00 04 00 ec bd 07 60 1c 49
96 25 26 2f 6d ca 7b 7f 4a f5 4a d7 e0 74 a1 08
80 60 13 24 d8 90 40 10 ec c1 88 cd e6 92 ec 1d
69 47 23 29 ab 2a 81 ca 65 56 65 5d 66 16 40 cc
ed 9d bc f7 de 7b ef bd f7 de 7b ef bd f7 ba 3b
9d 4e 27 f7 df ff 3f 5c 66 64 01 6c f6 ce 4a da 
c9 9e 21 80 aa c8 1f 3f 7e 7c 1f 3f 22 >>>

符合标准定义（ ttp 1f 8b 08 00 00 00 00 00 04 00://www.faqs.org/rfcs/rfc1952.html ）。@mark-adler 在为什么 BCL GZipStream (with StreamReader) 不能可靠地检测 CRC32 的数据错误中解释了固定部分的其余部分？

于 2012-07-11T15:29:16.170 回答
0

部分专利：

压缩级别不如其他一些应用程序的原因是市场上最有效的压缩算法都受专利保护。另一方面，.net 使用非专利技术。

和

好吧，当我问同样的问题时（从 MS 的某个人那里）得到的解释是，这与微软无法在不修改 GZip 算法的情况下使用它有关；由于专利/许可问题。

http://social.msdn.microsoft.com/Forums/fr-FR/c5f0b53c-a2d5-4407-b43b-9da8d39c01df/why-do-gzipstream-compression-ratio-so-bad?forum=netfxbcl

最初我怀疑微软的 gzip 实现；我知道他们实施了 Deflate 算法，该算法不是最有效但没有专利。

http://challenge-me.ws/post/2010/11/05/Do-Not-Take-Microsofts-Code-for-Granted.aspx

于 2014-07-06T20:47:29.900 回答
-4

现代压缩工具通常会使用一种以上的压缩策略。使用 Winzip 和 WinRAR 等，您通常会获得以下选项：

  • 最大压缩
  • 最快的
  • 普通的

如果您也这样做，您可能可以进一步压缩文件。

于 2012-07-11T15:12:27.427 回答