相关疑难解决方法(0)

我在.NET 4.0中遇到了一些奇怪的机器/操作系统相关的GZipStream行为.这是相关代码:

public static string Compress(string input) {
    using(var ms = new MemoryStream(Encoding.UTF8.GetBytes(input)))
    using(var os = new MemoryStream()) {
        using(var gz = new GZipStream(os,CompressionMode.Compress,true)) {
            ms.CopyTo(gz);
        }
        return string.Join("",os.ToArray().Select(b=>b.ToString("X2")));
    }
}

运行压缩("freek")给了我

1F8B08000000000004004B2B4A4DCD06001E33909D05000000

在Windows 7和

1F8B0800000000000400ECBD07601C499625262F6DCA7B7F4AF54AD7E074A10880601324D8904010ECC188CDE692EC1D69472329AB2A81CA6556655D661640CCED9DBCF7DE7BEFBDF7DE7BEFBDF7BA3B9D4E27F7DFFF3F5C6664016CF6CE4ADAC99E2180AAC81F3F7E7C1F3F22CEEB3C7FFBFF040000FFFF1E33909D05000000

在Windows Server 2008R2上.两者都是64位.我希望结果是一样的.

当我解压缩任一结果时,两台机器都给出正确的结果.我已经发现在W7 ms.Length == 25而在W2K8R2 ms.Length == 128,但没有线索为什么.

这是怎么回事？

我有一个连接到后端WAS服务器的.NET 2.0 WinForms应用程序。我正在使用GZipStream解码从对服务器进行的HttpWebRequest调用返回的数据。返回的数据是Apache压缩的压缩CSV。整个服务器堆栈是Hibernate-> EJB-> Spring-> Apache。

对于较小的响应，性能很好（<50ms）。当我收到> 150KB的响应时，解压缩需要60秒钟以上。大部分时间似乎都花在了GZipStream构造函数上。

这是显示从HttpWebResponse调用获取响应流的代码：

using (Stream stream = this.Response.GetResponseStream())
{
 if (this.CompressData && this.Response.ContentEncoding == "gzip")
 {
        // Decompress the response
  byte[] b = Decompress(stream);
  this.ResponseBody = encoding.GetString(b);
    }
 else
 {
  // Just read the stream as a string
  using (StreamReader sr = new StreamReader(stream))
  {
   this.ResponseBody = sr.ReadToEnd();
  }
 }
}

编辑1

基于Lucero的评论，我将Decompress方法修改为以下内容，但是在实例化GZipStream之前，将ResponseStream加载到MemoryStream中不会带来任何性能优势。

private static byte[] Decompress(Stream stream)
{
 using (MemoryStream ms = new MemoryStream())
 {
  byte[] buffer = new byte[4096];
  int read = …