Борьба с алгоритмом надувания - PullRequest
Новая
       13

Борьба с алгоритмом надувания

1 голос
/ 12 сентября 2011

Мне трудно понять, как работает алгоритм надувания, даже после прочтения RFC и рассмотрения реализаций c и javascript. Я сжал файл с текстом «TestingTesting» и получил следующий результат в шестнадцатеричном виде: 0B 49 2D 2E C9 CC 4B 0F 81 50 00

Я попытался прочитать данные после 16- и 32-разрядных последовательных перестановок, но после прочтения первых 3 битов я не смогу продолжить, потому что следующие 5 бит не имеют смысла. Что я делаю не так и как это можно разобрать?

Ссылки, которые я использовал: RFC 1951 Javascript C

1 Ответ

10 голосов
/ 13 сентября 2011

Выход из компрессора представляет собой поток байтов. Почему вы делаете обмен по порядку байтов?

Просмотр первых нескольких байтов в двоичном виде: 

0B  = 00001011
49  = 01001001
2D  = 00101101  
2E  = 00101110
...

Из раздела 3.1.1 в RFC:

  • битов читаются справа налево, поэтому первый бит заголовка, BFINAL, равен 1: 

     00001011
        ^

  • числа сначала упаковываются в младший бит, и мы читаем справа налево, поэтому BTYPE равно 01: 

     00001011
      ^^

  • Это фиксированный тип блока кода Хаффмана, поэтому мы ожидаем следующий код Хаффмана. Коды Хаффмана сначала упаковываются в MSB, поэтому первый код 10000100 (мы переходим к следующему байту здесь): 

     00001011
 ^^^^^
 01001001
      ^^^

  • Глядя на таблицу в разделе 3.2.6, 00110000 до 10111111 представляют буквенные байты 0 - 143, поэтому 10000100 (= 0x84) - это буквальное значение 0x54, которое код ASCII для "T".

  • Продолжая, следующий код будет 10010101 (= 0x95), который является буквальным значением 0x65, который является "e".

... и т. Д.

...