GZipStream实现压缩以及出现的问题

最新推荐文章于 2022-03-20 18:28:46 发布

iteye_4392

最新推荐文章于 2022-03-20 18:28:46 发布

阅读量469

点赞数

文章标签： Google

本文介绍了使用.NET Framework下的GZipStream进行数据压缩时遇到的问题，特别是当压缩后的数据小于4KB时，解压会失败。文章揭示了问题的原因在于GZipStream的工作机制，并提供了正确的使用方法。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

在抓取页面的过程中，在存储抓取到的页面内容的时候我需要先将页面压缩再存储，为了使用上的方便，采用了2.0下的GZipStream来进行压缩。

引用如下：

 
  usingSystem.IO; 
 usingSystem.IO.Compression; 
......
 publicstaticbyte[]Compress(byte[]data) 
{
 MemoryStreamstream=newMemoryStream(); 
 GZipStreamgZipStream=newGZipStream(stream,CompressionMode.Compress); 
gZipStream.Write(data,0,data.Length);
 //....暂时先在注释的位置卖点关子  
 returnstream.ToArray(); 
}
 publicstaticbyte[]Decompress(byte[]data) 
{
 MemoryStreamstream=newMemoryStream(); 
 GZipStreamgZipStream=newGZipStream(newMemoryStream(data),CompressionMode.Decompress); 
 byte[]bytes=newbyte[4096]; 
 intn; 
 while((n=gZipStream.Read(bytes,0,bytes.Length))!=0) 
{
stream.Write(bytes,0,n);
}
 returnstream.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才可以。。。

继续郁闷......还不知道会出现什么更加有意思东西哦