Ascii85 - Ascii85

Ascii85, также называемый Base85, это форма двоичное кодирование текста разработан Полом Э. Раттером для btoa полезность. Используя пять ASCII символы для представления четырех байтов двоичные данные (делая закодированный размер1⁄4 больше оригинала, предполагая восемь бит на символ ASCII), он более эффективен, чем uuencode или же Base64, которые используют четыре символа для представления трех байтов данных (1⁄3 увеличиваются, предполагая восемь бит на символ ASCII).

Его основные современные виды использования находятся в Adobe с PostScript и Формат переносимого документа форматы файлов, а также в пластырь кодирование для двоичные файлы использован Git.[1]

Обзор

Основная потребность в кодировании двоичного кода в текст возникает из необходимости передавать произвольные двоичные данные над ранее существовавшим протоколы связи которые были разработаны, чтобы нести только английский язык человек читаемый текст. Эти протоколы связи могут быть только 7-битными (и в этом случае избегать определенных управляющих кодов ASCII) и могут потребовать разрывы строк через определенные максимальные интервалы и может не поддерживать пробел. Таким образом, только 95 печатаемые символы ASCII «безопасны» для передачи данных.

Четыре байта могут представлять 232 = 4 294 967 296 возможных значений. Пять основание -85 цифр дают 855 = 4 437 053 125 возможных значений, достаточно, чтобы обеспечить уникальное представление для каждого возможного 32-битного значения. Поскольку пять цифр системы счисления -84 дают только 845 = 4 182 119 424 представимых значения, 85 - это минимально возможная основа целого числа, которая будет представлять четыре байта в пяти символах, отсюда и его выбор.

При кодировании каждая группа из 4 байтов принимается как 32-битное двоичное число, начиная со старшего байта (Ascii85 использует прямой порядок байтов соглашение). Он преобразуется путем многократного деления на 85 и взятия остатка на 5 цифр с основанием системы счисления 85. Затем каждая цифра (опять же, наиболее значимая первая) кодируется как печатный символ ASCII путем добавления к ней 33, что дает символам ASCII 33 ("!") через 117 ("ты").

Поскольку данные с нулевым значением являются довольно распространенным явлением, сделано исключение ради Сжатие данных, а группа "все нули" кодируется как один символ "z" вместо "!!!!!".

Группы символов, которые декодируются до значения больше, чем 232 − 1 (закодировано как "s8W-!") вызовет ошибку декодирования, как и"z"символы в середине группы. Пробелы между символами игнорируются и могут находиться где угодно, чтобы учесть ограничения на длину строки.

Одним из недостатков Ascii85 является то, что закодированные данные могут содержать escape-символы такие как обратная косая черта и кавычки, которые имеют особое значение во многих языках программирования и в некоторых текстовых протоколах. Другие кодировки base-85, такие как Z85 и RFC 1924 разработаны так, чтобы быть безопасными в исходном коде.[2]

История

версия btoa

Исходная программа btoa всегда кодировала полные группы (при необходимости добавляя исходный код), с префиксом «xbtoa Begin» и суффиксной строкой «xbtoa End», за которым следует исходная длина файла (в десятичном и шестнадцатеричный ) и три 32-битных контрольные суммы. Декодер должен использовать длину файла, чтобы увидеть, какая часть группы была заполнена. Первоначальное предложение для кодирования btoa использовало алфавит кодирования, начинающийся с символа пробела ASCII до символа «t» включительно, но он был заменен алфавитом кодирования «!» на «u», чтобы избежать «проблем с некоторыми почтовыми программами (удаление конечных пробелов)».[3] Эта программа также представила специальный "z"краткая форма для группы" все нули ". Версия 4.2 добавила"у"исключение для группы всех ASCII Космос символы (0x20202020).

ZMODEM версия

«Кодировка ZMODEM Pack-7» кодирует группы из 4 октетов в группы из 5 печатаемых символов ASCII аналогичным или, возможно, тем же способом, что и Ascii85. Когда ZMODEM программы отправляют предварительно сжатые 8-битные файлы данных по 7-битные каналы данных, он использует "кодировку ZMODEM Pack-7".[4]

Версия Adobe

Adobe приняла базовую кодировку btoa, но с небольшими изменениями, и дала ей имя Ascii85. Используемые символы - это символы ASCII с 33 (!) По 117 (u) включительно (для представления цифр от 0 до 84 по основанию 85) вместе с буквой z (в качестве особого случая для представления 32-битного значения 0), и пустое пространство игнорируется. Adobe использует разделитель "~>", чтобы отметить конец строки в кодировке Ascii85, и представляет длину путем усечения последней группы: если последний блок исходных байтов содержит менее 4 байтов, перед кодированием в блок добавляется до трех нулевых байтов. После кодирования , столько байтов, сколько было добавлено, поскольку заполнение удаляется из конца вывода.

При декодировании применяется обратное: последний блок дополняется до 5 байтов символом Ascii85 "ты", и столько байтов, сколько было добавлено в качестве заполнения, не указывается в конце вывода (см. пример).

ПРИМЕЧАНИЕ: отступы не являются произвольными. Преобразование из двоичного в базовый 64 только перегруппирует биты и не меняет их или их порядок (старший бит в двоичном формате не влияет на младшие биты в представлении base64). При преобразовании двоичного числа в base85 (85 - это нет степень двойки) старших битов влияет на младшие цифры base85 и наоборот. Заполнение двоичного низкого уровня (с нулевыми битами) при кодировании и заполнение высокого значения base85 (с помощью 'u) при декодировании гарантирует, что биты высокого порядка сохраняются (нулевое заполнение в двоичном файле дает достаточно места, чтобы небольшое добавление было захвачено и нет "переноса" в старшие биты).


В блоках с кодировкой Ascii85 пробелы и символы разрыва строки могут присутствовать где угодно, в том числе в середине 5-символьного блока, но они должны игнорироваться.

Спецификация Adobe не поддерживает "у" исключение.

Пример для Ascii85

Цитата из Томаса Гоббса Левиафан:

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

Если он изначально закодирован с использованием US-ASCII, его можно перекодировать в Ascii85 следующим образом:

<~9jqo^BlbD-BleB1DJ+*+F(f,q/0JhKF<GL>[email protected]$d7F!,L7@<6@)/0JDEF<G%<+EV:2F!,O<DJ+*.@<*K0@<6L(Df-\0Ec5e;DffZ(EZee.Bl.9pF"AGXBPCsi+DGm>@3BB/F*&OCAfu2/AKYi(DIb:@FD,*)+C]U=@3BN#EcYf8ATD3s@q?d$AftVqCh[NqF<G:8+EV:.+Cf>-FD5W8ARlolDIal(DId<j@<?3r@:F%a+D58'ATD4$Bl@l3De:,-DJs`8ARoFb/0JMK@qB4^F!,R<AKZ&-DfTqBG%G>uD.RTpAKYo'+CT/5+Cei#DII?(E,9)oF*2M7/c~>
Текстовое содержаниеMап...sтыре
ASCII779711032...115117114101
Битовый шаблон01001101011000010110111000100000...01110011011101010111001001100101
32-битное значение1,298,230,816 = 24×854 + 73×853 + 80×852 + 78×85 + 61...1,937,076,837 = 37×854 + 9×853 + 17×852 + 44×85 + 22
База 85 (+33)24 (57)73 (106)80 (113)78 (111)61 (94)...37 (70)9 (42)17 (50)44 (77)22 (55)
ASCII9jqо^...F*2M7

Поскольку последний 4-кортеж неполный, он должен быть дополнен тремя нулевыми байтами:

Текстовое содержание.\0\0\0
ASCII46000
Битовый шаблон00101110000000000000000000000000
32-битное значение771,751,936 = 14×854 + 66×853 + 56×852 + 74×85 + 46
База 85 (+33)14 (47)66 (99)56 (89)74 (107)46 (79)
ASCII/cYkО

Поскольку нужно было добавить три байта заполнения, три последних символа «YkO» не выводятся.

Декодирование выполняется в обратном порядке, за исключением того, что последний кортеж из 5 дополняется символами 'u':

ASCII/cтытыты
База 85 (+33)14 (47)66 (99)84 (117)84 (117)84 (117)
32-битное значение771,955,124 = 14×854 + 66×853 + 84×852 + 84×85 + 84
Битовый шаблон00101110000000110001100110110100
ASCII46325180
Текстовое содержание.[ ETX ][EM]´ (Расширенный ASCII )

Поскольку ввод должен был быть дополнен тремя байтами «u», последние три байта вывода игнорируются, и мы получаем исходную точку.

Входное предложение не содержит 4 последовательных нулевых байта, поэтому в примере не показано использование сокращения «z».

Совместимость

Кодировка Ascii85 совместима с 7-битными и 8-битными MIME, имея меньше накладных расходов, чем Base64.

Одна потенциальная проблема совместимости Ascii85 заключается в том, что «одинарные» и «двойные» кавычки, скобки и амперсанды (&) не могут использоваться без экранирования в таких языках разметки, как XML или SGML.

RFC 1924 версия

Опубликован в 1 апреля 1996 г. информационная RFC  1924: «Компактное представление адресов IPv6» от Роберт Эльз предлагает кодировку base-85 IPv6 адреса. Это отличается от схемы, использованной выше, тем, что он предлагает другой набор из 85 символов ASCII и предлагает выполнять всю арифметику над 128-битным числом, преобразовывая его в одно 20-значное число с основанием 85 (внутренние пробелы не допускаются) , а не разбивать его на четыре 32-битные группы.

Предлагаемый набор символов по порядку: 0–9, А–Z, а–z, а затем 23 символа !#$%&()*+-;<=>?@^_`{|}~. Максимально возможный представимый адрес, 2128−1 = 74×8519 + 53×8518 + 5×8517 + ..., будет закодирован как = r54lj & NUUO ~ Hi% c2ym0.

Этот набор символов исключает символы "',./:[\] , что делает его пригодным для использования в JSON струны (где " и \ потребует побега). Однако для SGML протоколы, в том числе XML, по-прежнему могут потребоваться escape-символы (для размещения <, > и &).

Смотрите также

Рекомендации

  1. ^ Хунио Хамано (5 мая 2006 г.). "двоичный патч".
  2. ^ «Z85 - алгоритм кодирования ZeroMQ Base-85»
  3. ^ Орост, Джо. "Re: СЖАТИЕ двоичных данных в почтовый ASCII Re: Кодирование двоичных данных в почтовый ASCII". Группы Google. Получено 11 апреля 2015.
  4. ^ Чак Форсберг. «Последние разработки в ZMODEM». Архивировано из оригинал на 2015-09-24. Получено 2013-05-14.. «ZMODEM Pack-7 упаковывает 4 байта в 5 печатных символов».

внешняя ссылка