Заголовок блока Bzip2: 1AY&SY

Это вопрос о формате архива bzip2. Любой архив Bzip2 состоит из заголовка файла, одного или нескольких блоков и хвостовой структуры. Все блоки должны начинаться с «1AY&SY», 6 байт двоично-десятичных цифр числа Пи, 0x314159265359. Согласно источник bzip2:

/*--
  A 6-byte block header, the value chosen arbitrarily
  as 0x314159265359 :-).  A 32 bit value does not really
  give a strong enough guarantee that the value will not
  appear by chance in the compressed datastream.  Worst-case
  probability of this event, for a 900k block, is about
  2.0e-3 for 32 bits, 1.0e-5 for 40 bits and 4.0e-8 for 48 bits.
  For a compressed file of size 100Gb -- about 100000 blocks --
  only a 48-bit marker will do.  NB: normal compression/
  decompression do *not* rely on these statistical properties.
  They are only important when trying to recover blocks from
  damaged files.
--*/

Вопрос: правда ли, что все архивы bzip2 будут иметь блоки, начало которых выровнено по границе байта? Я имею в виду все архивы, созданные эталонной реализацией bzip2, утилитой bzip2-1.0.5+.

Я думаю, что bzip2 может анализировать поток не как поток байтов, а как поток битов (сам блок кодируется Хаффманом, который по дизайну не выровнен по байтам).

Итак, другими словами: если grep -c 1AY&SY больше (хаффман может генерировать 1AY&SY внутри блока) или равно количеству блоков bzip2 в файле?


person osgx    schedule 15.08.2013    source источник


Ответы (1)


BZIP2 смотрит на битовый поток.

Из http://blastedbio.blogspot.com/2011/11/random-access-to-bzip2.html:

В любом случае, важно то, что файл BZIP2 содержит один или несколько «потоков», выровненных по байтам, каждый из которых содержит один (ноль?) или более «блоков», которые не выровнены по байтам, за которыми следует маркер конца потока ( шесть байтов 0x177245385090, которые представляют собой квадратный корень из числа пи в виде двоично-десятичного числа (BCD), четырехбайтовую контрольную сумму и пустые биты для выравнивания байтов).

В статье bzip2 википедии также упоминается выравнивание по битам (см. раздел "Формат файла"), что кажется чтобы быть встроенным из того, что я помню из школы (пришлось реализовать алгоритм...).

person Ryan    schedule 15.08.2013
comment
Это была какая-то жестокая школа? - person osgx; 16.08.2013
comment
Не то чтобы жестоко, нет :) Это был курс по сжатию данных, который читал приглашенный профессор. Этот парень: webhome.cs.uvic.ca/~nigelh - person Ryan; 16.08.2013
comment
Итак, я могу выполнить поиск 0x314159265359 и всех вариантов смещенной константы, чтобы найти блоки? - person osgx; 17.08.2013
comment
Это кажется интуитивно понятным. Однако не уверен в соображениях реализации. Вы можете взглянуть на этот проект: bitbucket.org/james_taylor/seek-bzip2 - person Ryan; 18.08.2013
comment
И мы видим, что этот проект на самом деле распаковывается без вычисления CRC: ="nofollow noreferrer">bitbucket.org/james_taylor/seek-bzip2/src/ (это не полностью распаковывает данные, поэтому не выполняет проверки CRC, * (ускорение примерно на 60%)), они выбрал медленный путь. Я все еще хочу выбросить seek-bzip2, как это было 3 года назад: stackoverflow.com/a/3701268/196561 - person osgx; 18.08.2013
comment
seek-bzip выполняет расчеты распаковки без создания распакованного выходного потока. Это делается для определения того, какое смещение байтов в несжатом потоке соответствует каждому отмеченному смещению битов в сжатом потоке. - person hippietrail; 09.06.2021