GZipStream машинная зависимость

Question

Я сталкиваюсь с каким-то странным поведением 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, но не знаю, почему.

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

1F8B0800000000000400ECBD07601C499625262F6DCA7B7F4AF54AD7E074A10880601324D8904010ECC188CDE692EC1D69472329AB2A81CA6556655D661640CCED9DBCF7DE7BEFBDF7DE7BEFBDF7BA3B9D4E27F7DFFF3F5C6664016CF6CE4ADAC99E2180AAC81F3F7E7C1F3F229ED579FEF6FF090000FFFF1A1C515C05000000

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

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

РЕДАКТИРОВАТЬ:

разные времена выполнения?

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

Answer 4

В отличие от Абеля ответа , я получаю результат

1F8B08000000000004004B2B4A4DCD06001E33909D05000000

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

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

1F8B0800000000000400EDBD07601C499625262F6DCA7B7F4AF54AD7E074A10880601324D8904010ECC188CDE692EC1D69472329AB2A81CA6556655D661640CCED9DBCF7DE7BEFBDF7DE7BEFBDF7BA3B9D4E27F7DFFF3F5C6664016CF6CE4ADAC99E2180AAC81F3F7E7C1F3F22CEEB3C7FFBFF001E33909D05000000

на той же машине / ОС.

Answer 5

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