Что может привести к сжатию данных GZipStream с избыточным заполнением нулями?

Question

Я сжимаю некоторые пакеты данных, используя класс GZipStream в рамках .NET. Все работает отлично, и степень сжатия в порядке, но когда я просматриваю сжатые данные с помощью шестнадцатеричного редактора, я заметил, что до трети каждого сжатого пакета заканчиваются нули. Это нормально?

Предположительно GZipStream - это блок-компрессор, и выход дополняется, чтобы выровнять его с некоторым размером блока? Существуют ли альтернативы, которые одинаково стабильны, а также поддерживаются, но без этой проблемы? (Я полагаю, что могу получить еще 10-30% сжатие, используя аналогичный алгоритм сжатия, который не так сильно нагружен).

Answer 1

Использование GZipStream не должно содержать чрезмерного количества завершающих нулей.

Но если вы неправильно используете MemoryStream, это может вызвать этот эффект. Он внутренне использует byte[] для хранения данных. Этот внутренний буфер может быть больше данных, записанных до сих пор, чтобы уменьшить количество распределений. Если вы используете GetBuffer(), вы получите полный массив, это ваша собственная ответственность использовать только первые байты Length.

В качестве альтернативы вы можете позвонить ToArray(), который возвращает новый массив байтов с точно Length байтами.

Процитируем документацию для GetBuffer():

Обратите внимание, что буфер содержит выделенные байты, которые могут быть неиспользованными. Например, если строка "test" записана в объект MemoryStream, длина буфера, возвращаемого с GetBuffer, равна 256, а не 4, а 252 байта не используется. Чтобы получить только данные в буфере, используйте метод ToArray; однако ToArray создает копию данных в памяти.

Answer 2

Формат gzip не имеет завершающих нулей. За исключением не более трех конечных нулевых байтов для небольших файлов, поскольку длина несжатых данных (по модулю 2) хранится в конце как четырехбайтовое малоконечное целое число.

Что-то еще помещает эти нули.