GZipStream机器依赖

Fre*_*eek 15 .net c# gzipstream .net-4.5

我在.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")));
    }
}
Run Code Online (Sandbox Code Playgroud)

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

1F8B08000000000004004B2B4A4DCD06001E33909D05000000
Run Code Online (Sandbox Code Playgroud)

在Windows 7和

1F8B0800000000000400ECBD07601C499625262F6DCA7B7F4AF54AD7E074A10880601324D8904010ECC188CDE692EC1D69472329AB2A81CA6556655D661640CCED9DBCF7DE7BEFBDF7DE7BEFBDF7BA3B9D4E27F7DFFF3F5C6664016CF6CE4ADAC99E2180AAC81F3F7E7C1F3F22CEEB3C7FFBFF040000FFFF1E33909D05000000
Run Code Online (Sandbox Code Playgroud)

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

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

这是怎么回事?

Rob*_*evy 18

据宣布.NET 4.5 Beta包含拉链压缩改进以减小尺寸:

从.NET Framework 4.5 RC开始,DeflateStream类使用zlib库进行压缩.因此,它提供了更好的压缩算法,并且在大多数情况下,它提供的压缩文件比早期版本的.NET Framework中提供的压缩文件小.

你可能在Win7机器上安装了.Net 4.5+吗?

  • 这就是我们在Stack Overflow上的一点,因为运行混合的4.0/4.5层和gzipping内容,然后将其推入(应该是)用于缓存的redis中的唯一集合.如果您*依赖于相同的压缩结果(例如,从集合中删除项目),请注意运行4.0和4.5服务器的混合环境. (4认同)

Fre*_*eek 5

似乎.NET 4.5中DeflateStream使用算法发生了变化:

从.NET Framework 4.5 Beta开始,DeflateStream类使用zlib库进行压缩.因此,它提供了更好的压缩算法,并且在大多数情况下,它提供的压缩文件比早期版本的.NET Framework中提供的压缩文件小.

由于我安装了4.5,这导致了问题.

  • 我不认为这是一个突破性的变化.这只是性能提升.应用程序不应对此API的结果有任何期望,除非它根据gzip规范有效. (2认同)