Раздувать успешную операцию распаковки без обработки полных сжатых данных

Question

Я использую методы Software Inflate (метод Raw deflate, а не варианты GZIP / ZLIB) для операций декомпрессии.

Странно, но я заметил следующие замечания

1.) Когда я передаю один сжатый буфер (поля poss_in и next_in) в качестве исходных данных и один целевой буфер (vend_out и next_out) для вывода декомпрессии, операции раздувания с раздувом завершены успешно с положительным статусом Z_STREAM_END. Я также сравнил это с исходными несжатыми данными и соответствием.

2.) Однако, когда я разделяю сжатые данные на два буфера, 1 буфер со сжатыми данными минус один байт (размер сжатых данных -1), Во втором буфере размером 1 байт и одном целевом буфере размером, равном исходной несжатой длине, операция распаковки завышена успешно с положительным статусом Z_OK, заполняющим мой полный целевой буфер (vend_out = 0 и total_out = исходный несжатый размер). Я также сравнил это с исходными несжатыми данными и их соответствием.

Я очень запутался, почему операции inflate () удалось создать все исходные данные без обработки второго исходного буфера.? Это ожидаемое поведение при операции надувания?

3.) Я также попробовал описанный выше метод 2, разделив исходные данные на 2 буфера, где последний буфер имеет длину 2 байта, а 1 размер исходного буфера - сжатые данные -2 и с один буфер назначения. Видел то же поведение, что и в 2.

Answer 1

Такое поведение ожидается.

Завышенные данные представляют собой поток кодов с переменной длиной битов, соединенных вместе в поток байтов. Отдельные единицы кода не выровнены по байту, и сжатый поток обычно не заканчивается на границе байта. Таким образом, последний байт сжатого потока может содержать несколько неиспользуемых битов.

Сжатый поток не сохраняет свою длину. Вместо этого одна из единиц кода используется в качестве индикатора окончания потока. Сами кодовые блоки по сути являются кодами Хаффмана, поэтому самые распространенные из них самые короткие. Индикатор конца потока появляется только один раз в потоке, поэтому его код, вероятно, будет больше 8 бит.

Таким образом, гарантируется, что последний байт в сжатом потоке содержит только конец конца. индикатор потока, и весьма вероятно, что индикатор конца потока также занимал весь второй-последний байт, а также несколько битов третьего-последнего байта. (Я почти уверен, что длина кода ограничена 16 битами, но я не проверял справочные материалы.)

Каждой единице кода соответствует один или несколько байтов в исходном сообщении, и эти байты может быть восстановлен без обращения к следующей единице кода. Если вы распаковываете до кодовой единицы, которая предшествует концу потока, вы распаковываете весь файл; единственное, что говорит вам индикатор конца потока, это то, что вы закончили.