GZipStream机依赖 [英] GZipStream machine dependence
问题描述
我遇到在.NET 4.0中的一些奇怪的机器/ OS依赖GZipStream行为。这是相关的code:
公共静态字符串的COM preSS(字符串输入){
使用(VAR毫秒=新的MemoryStream(Encoding.UTF8.GetBytes(输入)))
使用(VAR OS =新的MemoryStream()){
使用(VAR GZ =新GZipStream(OS,COM pressionMode.Com preSS,真)){
ms.CopyTo(GZ);
}
返回的string.join(,os.ToArray()选择(二=> b.ToString(X2)));
}
}
正在运行的COM preSS(FREEK)给了我
1F8B08000000000004004B2B4A4DCD06001E33909D05000000
在Windows 7和
<$p$p><$c$c>1F8B0800000000000400ECBD07601C499625262F6DCA7B7F4AF54AD7E074A10880601324D8904010ECC188CDE692EC1D69472329AB2A81CA6556655D661640CCED9DBCF7DE7BEFBDF7DE7BEFBDF7BA3B9D4E27F7DFFF3F5C6664016CF6CE4ADAC99E2180AAC81F3F7E7C1F3F22CEEB3C7FFBFF040000FFFF1E33909D05000000
在基于Windows Server 2008R2。两者都是64位。我期望的结果是相同的。
这两款机器给出正确的结果,当我DECOM preSS无论是结果。我已经发现,在W7 ms.Length == 25,而在W2K8R2 ms.Length == 128,但不知道为什么。
这是怎么回事?
<一个href="http://msdn.microsoft.com/en-us/library/system.io.com$p$pssion.gzipstream%28v=vs.110%29.aspx#remarksToggle">It会上宣布,.NET 4.5 Beta版,包括拉链COM pression改进,以减少大小:
从.NET Framework 4.5 RC开始,DeflateStream类使用的COM pression zlib库。其结果是,它提供了一个更好的COM pression算法,在大多数情况下,一个较小的COM pressed文件比它提供了在早期版本的.NET Framework
你也许有净4.5+安装Win7的机器上?
I'm running into some strange machine/OS dependent GZipStream behavior in .NET 4.0. This is the relevant code:
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")));
}
}
Running Compress("freek") gives me
1F8B08000000000004004B2B4A4DCD06001E33909D05000000
on Windows 7 and
1F8B0800000000000400ECBD07601C499625262F6DCA7B7F4AF54AD7E074A10880601324D8904010ECC188CDE692EC1D69472329AB2A81CA6556655D661640CCED9DBCF7DE7BEFBDF7DE7BEFBDF7BA3B9D4E27F7DFFF3F5C6664016CF6CE4ADAC99E2180AAC81F3F7E7C1F3F22CEEB3C7FFBFF040000FFFF1E33909D05000000
on Windows Server 2008R2. Both are 64bit. I would expect the results to be the same.
Both machines give the correct result when I decompress either result. I already found out that on W7 ms.Length == 25 while on W2K8R2 ms.Length==128, but no clue why.
What's going on?
It was announced that .NET 4.5 Beta includes zip compression improvements to reduce the size:
Starting with the .NET Framework 4.5 RC, the DeflateStream class uses the zlib library for compression. As a result, it provides a better compression algorithm and, in most cases, a smaller compressed file than it provides in earlier versions of the .NET Framework.
Do you perhaps have .Net 4.5+ installed on the Win7 machine?
这篇关于GZipStream机依赖的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!