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

Question

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

[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"S.

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

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

Возможно, отображение символа сжатия в 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 Feeds 0D 00 0A 00

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

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

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

Answer 1

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

Answer 2

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