Почему кодировка Ascii85 не позволяет динамическое сжатие?

encoding compression ascii ascii85 base85

130 просмотра

2 ответа

7941 Репутация автора

Согласно Википедии:

[Ascii85 использует] символы ASCII с 33 (!) По 117 (u) включительно (для представления цифр от 0 до 84 от 85 до 85) вместе с буквой z (как особый случай для представления 32-битного значения 0).

[btoa] Версия 4.2 добавила исключение "y" для группы всех символов пробела ASCII

В то время как данные 0 могут быть довольно распространенными, такое использование zдля сжатия 0 кажется произвольной оптимизацией, которая не всегда будет полезна.

Аналогично, менее частое использование yимеет смысл только в том случае, если необработанные байты содержат соседние пробелы. Unicode-кодировка пространства на самом деле не 20 00так 0x20202020уж распространена в текстах Unicode.

Двоичные данные часто имеют смежные 00, но также часто содержат смежные FF.

Текстовые данные часто содержат соседние пробелы, но они также часто содержат символы смежной табуляции или соседние символы новой строки.

Казалось бы, частотный анализ и использование 9 или 10 символов (символы Ascii 118-126 / 127 или vчерез ~/ DEL) для представления наиболее часто используемых 32-разрядных значений 9/10 могут привести к лучшему сжатию.

Возможно, отображение символа сжатия в 32-битное значение может находиться в начале закодированной строки, заключенной между <[и ]>. Для 32-разрядных значений, которые представляют собой 4 повторных байта, 32-разрядное значение может быть сокращено до повторных шестнадцатеричных значений.

Например:

Двоичные данные (192 байта):

00 00 00 00 FF FF FF FF 20 20 20 20 2D 2D 2D 2D 09 09 09 09 0D 00 0A 00

00 00 00 00 FF FF FF FF 20 20 20 20 2D 2D 2D 2D 09 09 09 09 0D 00 0A 00

00 00 00 00 FF FF FF FF 20 20 20 20 2D 2D 2D 2D 09 09 09 09 0D 00 0A 00

00 00 00 00 FF FF FF FF 20 20 20 20 2D 2D 2D 2D 09 09 09 09 0D 00 0A 00

00 00 00 00 FF FF FF FF 20 20 20 20 2D 2D 2D 2D 09 09 09 09 0D 00 0A 00

00 00 00 00 FF FF FF FF 20 20 20 20 2D 2D 2D 2D 09 09 09 09 0D 00 0A 00

00 00 00 00 FF FF FF FF 20 20 20 20 2D 2D 2D 2D 09 09 09 09 0D 00 0A 00

00 00 00 00 FF FF FF FF 20 20 20 20 2D 2D 2D 2D 09 09 09 09 0D 00 0A 00

Обратите внимание на наличие пробелов 20, дефисов 2D, табуляций 09и Unicode Carriage Return-Line Feeds0D 00 0A 00

Может быть закодирован как (79 байт)

<[00;FF;20;2D;09;0D000A00]><~vxyz{|vxyz{|vxyz{|vxyz{|vxyz{|vxyz{|vxyz{|vxyz{|~>

Есть ли смысл в подходе кодирования, в котором используется такое сжатие? Почему различные спецификации Ascii85 не более агрессивны в отношении сжатия?

Автор: ThunderFrame Источник Размещён: 19.07.2016 01:02

Ответы (2)


2 плюса

63156 Репутация автора

Решение

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

Автор: Mark Adler Размещён: 19.07.2016 01:09

3 плюса

60842 Репутация автора

Есть некоторые приложения, для которых полезно иметь возможность найти N-й октет закодированной строки без необходимости сканировать все это. Сжатие будет мешать этому. Однако существуют другие приложения, для которых могут быть полезны определенные формы сжатия. Если можно использовать более 85 различных символов, кодировка base-85 позволит легко сжимать символы за пределами основного набора. Даже если один из них ограничен набором из 85 символов, число последовательностей из пяти базовых 85 символов больше, чем объединенное количество последовательностей из одного, двух, трех и четырех базовых 256 байтов, поэтому в нем будет место. использовать некоторые специальные комбинации символов, чтобы указать, например, серии определенных значений символов.

Автор: supercat Размещён: 12.09.2016 10:12
32x32