Зависимость машины от GZipStream

Я столкнулся с каким-то странным поведением GZipStream, зависящим от машины и ОС в .NET 4.0. Это соответствующий код:

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")));
    }
}

Запуск Compress ( "freek" ) дает мне

1F8B08000000000004004B2B4A4DCD06001E33909D05000000

в Windows 7 и

1F8B0800000000000400ECBD07601C499625262F6DCA7B7F4AF54AD7E074A10880601324D8904010ECC188CDE692EC1D69472329AB2A81CA6556655D661640CCED9DBCF7DE7BEFBDF7DE7BEFBDF7BA3B9D4E27F7DFFF3F5C6664016CF6CE4ADAC99E2180AAC81F3F7E7C1F3F22CEEB3C7FFBFF040000FFFF1E33909D05000000

в Windows Server 2008R2. Оба являются 64-битными. Я ожидаю, что результаты будут одинаковыми.

Обе машины дают правильный результат при распаковке результата. Я уже выяснил, что на W7 ms.Length == 25 пока на W2K8R2 ms.Length == 128, но не знаю почему.

Что происходит?

Ответы

Ответ 1

Было объявлено, что .NET 4.5 Beta включает улучшения сжатия zip для уменьшения размера:

Начиная с .NET Framework 4.5 RC, класс DeflateStream использует библиотеку zlib для сжатия. В результате он обеспечивает лучший алгоритм сжатия и, в большинстве случаев, меньший сжатый файл, чем он предлагает в более ранних версиях .NET Framework.

Возможно, у вас есть .Net 4.5+, установленный на машине Win7?

Ответ 2

Кажется, что в алгоритме используемом DeflateStream в .NET 4.5, изменилось:

Начиная с бета-версии .NET Framework 4.5, класс DeflateStream использует библиотеку zlib для сжатия. В результате он обеспечивает лучший алгоритм сжатия и, в большинстве случаев, меньший сжатый файл, чем он предлагает в более ранних версиях .NET Framework.

Так как я установил 4.5, это вызывало проблему.

Ответ 3

Я запустил ваш код на своей 64-разрядной машине под Windows 7 и получил следующее, что равно вашему Win2k8SP2:

1F8B0800000000000400ECBD07601C499625262F6DCA7B7F4AF54AD7E074A10880601324D8904010ECC188CDE692EC1D69472329AB2A81CA6556655D661640CCED9DBCF7DE7BEFBDF7DE7BEFBDF7BA3B9D4E27F7DFFF3F5C6664016CF6CE4ADAC99E2180AAC81F3F7E7C1F3F229ED579FEF6FF090000FFFF1A1C515C05000000

По существу, я думаю, что результат связан с длиной слова машины. Например, ваш компьютер с Windows-7, возможно, 32 бит?

ПРИМЕЧАНИЕ. Я написал небольшую декомпрессию для ваших строк, и я должен сказать, что они действительно декомпрессируются. Я запускал свою версию как в 32-битном, так и в 64-битном, и результат был равен. Остается только возможная разница: разные промежутки времени?

EDIT:

разные времена работы?

По-видимому, как Хенк Холтерман предложил ниже и Роберт Леви, формализованный в его ответ, это был действительно неочевидный случай здесь.

Ответ 4

В отличие от Abel answer, я получаю результат

1F8B08000000000004004B2B4A4DCD06001E33909D05000000

на моем Windows 7 x64 Ultimate SP1. Возможно, есть обновление .NET Framework, которое у вас нет в одном из полей? Версия моего mscorlib.dll - 4.0.30319.17379.

ETA: Если я перенастрою на .NET 2 (и сменив .NET-специфические конструкции на их эквиваленты .NET 2), я получаю результат

1F8B0800000000000400EDBD07601C499625262F6DCA7B7F4AF54AD7E074A10880601324D8904010ECC188CDE692EC1D69472329AB2A81CA6556655D661640CCED9DBCF7DE7BEFBDF7DE7BEFBDF7BA3B9D4E27F7DFFF3F5C6664016CF6CE4ADAC99E2180AAC81F3F7E7C1F3F22CEEB3C7FFBFF001E33909D05000000

на том же компьютере/ОС.

Ответ 5

Я подозреваю, что одна из операционных систем - 32 бит, а другая - 64 бит.