在抓取页面的过程中，在存储抓取到的页面内容的时候我需要先将页面压缩再存储， 为了使用上的方便，采用了2.0下的GZipStream来进行压缩。
引用如下：
using System.IO;
using System.IO.Compression;
......
public static byte[] Compress(byte[] data)
{
MemoryStream stream = new MemoryStream();
GZipStream gZipStream = new GZipStream(stream, CompressionMode.Compress);
gZipStream.Write(data, 0, data.Length);
//....暂时先在注释的位置卖点关子
return stream.ToArray();
}
public static byte[] Decompress(byte[] data)
{
MemoryStream stream = new MemoryStream();
GZipStream gZipStream = new GZipStream(new MemoryStream(data), CompressionMode.Decompress);
byte[] bytes = new byte[4096];
int n;
while ((n = gZipStream.Read(bytes, 0, bytes.Length)) != 0)
{
stream.Write(bytes, 0, n);
}
return stream.ToArray();
}
上面的代码使用起来似乎是没有什么问题的（如果你不仔细做测试的话）， 但是当我对各种大小的页面进行测试后，发现如果压缩后byte[]长度<4K，那么问题出 来了：没法解压，解压函数中Read返回结果总是0。闻一多先生曾经在演讲中说“郁 闷啊，郁闷，这是某集团的郁闷，恰恰是微软的光荣（笔者注：我觉得应该属于微软bug ）”。
我一度怀疑是不是Decompress函数中的bytes数组长度设置长了，后来把长度设置的很 小，但是解压后还是那样，返回0。真想去和盖茨理论理论。
不过幸运的是，我测试发现了这个4K下限制，所以Google了下“GZipStream 4K”，哈哈，在国外的一论坛 （http://www.dotnetmonster.com/Uwe/Forum.aspx/dotnet-framework/19787/Problem- with-the-GZipStream-class-and-small-streams）里面终于找到了答案：原来 GZipStream存取数据的时候是以4K为块进行存取的。所以在压缩的时候，在返回 stream.ToArray()前应该先gZipStream.Close()（也就是上面俺卖关子的那里），原因是 GZipStream是在Dispose的时候把数据完全写入。你说冤吗？我明明已经Write了，竟然还 要我再Close才可以。