Кодирование двоичных данных в текст

Введение

Преобразование компьютерных данных в текст

Кодирование бинарных данных в текст — это представление данных в виде обычного текста. Более точно, это кодирование двоичных данных в последовательность печатаемых символов. Такие кодировки необходимы для передачи данных, когда канал связи не поддерживает двоичные данные (например, электронная почта или NNTP) или не является 8-битным чистым каналом. В документации PGP термин "ASCII armor" используется для обозначения кодирования бинарных данных в текст применительно к Base64.

Обзор

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

Описание

Стандарт кодирования текста ASCII использует 7 бит для кодирования символов. С помощью этого можно кодировать 128 (то есть 2 в 7-й степени) уникальных значений (от 0 до 127) для представления букв, цифр и знаков препинания, обычно используемых в английском языке, а также набор управляющих символов, которые не представляют собой печатные символы. Например, заглавная буква A представлена в 7 битах как 1000001, 0x41 (65 в десятичной системе), цифра 2 – 0110010, 0x32 (50 в десятичной системе), символ } – 1111101, 0x7D (125 в десятичной системе), а управляющий символ RETURN – 0001101, 0x0D (13 в десятичной системе). В отличие от этого, большинство компьютеров хранят данные в памяти, организованной в восьмибитные байты. Файлы, содержащие машинный код и нетекстовые данные, как правило, содержат все 256 возможных восьмибитных байтовых значений. Многие компьютерные программы стали полагаться на это различие между семибитовым текстом и восьмибитовыми двоичными данными и не будут работать правильно, если в данных, которые должны содержать только текст ASCII, появятся символы, не входящие в ASCII. Например, если значение восьмого бита не сохраняется, программа может интерпретировать байтовое значение выше 127 как флаг, указывающий на выполнение какой-либо функции. Однако часто желательно иметь возможность отправлять нетекстовые данные через текстовые системы, например, прикреплять файл изображения к электронному письму. Для этого данные кодируются таким образом, чтобы восьмибитные данные были преобразованы в семибитные символы ASCII (обычно используются только буквенно-цифровые символы и знаки препинания – печатаемые символы ASCII). По безопасному прибытию в пункт назначения данные затем декодируются обратно в восьмибитный формат. Этот процесс называется кодированием двоичных данных в текст. Многие программы выполняют это преобразование для обеспечения передачи данных, такие как PGP и GNU Privacy Guard.

Кодирование простого текста

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

Некоторые системы поддерживают более ограниченный набор символов; они не только не поддерживают полную 8-битную кодировку, но и не могут обрабатывать все печатные символы ASCII. Другие системы имеют ограничения на количество символов, допустимых между разрывами строк, например, ограничение в "1000 символов на строку" в некоторых реализациях протокола Simple Mail Transfer Protocol, как это предусмотрено. Некоторые малоизвестные, но всё ещё используемые протоколы используют внутриполосную сигнализацию, что может приводить к путанице при появлении определенных шаблонов в сообщении. Наиболее известным примером является строка "From " (включая завершающий пробел) в начале строки, используемая для разделения почтовых сообщений в формате файла mbox. Используя кодирование бинарных данных в текст для сообщений, которые уже являются обычным текстом, а затем декодируя их на другом конце, можно сделать такие системы полностью прозрачными. Это иногда называют «ASCII-бронированием». Например, компонент ViewState в ASP.NET использует кодирование Base64 для безопасной передачи текста через HTTP POST, чтобы избежать коллизий разделителей.

Стандарты кодирования

В таблице ниже приведено сравнение наиболее распространенных форм кодирования бинарных данных в текст. Эффективность, указанная в таблице, представляет собой отношение количества битов во входных данных к количеству битов в закодированном выходном потоке. Кодирование Тип данных Эффективность Реализации на языках программирования Комментарии Ascii85 Произвольные 80% awk, C, C (2), C#, F#, Go, Java, Perl, Python, Python (2) Существует несколько вариантов этого кодирования, таких как Base85, btoa и другие. Base32 Произвольные 62,5% ANSI C, Delphi, Go, Java, C#, F#, Python Base36 Целые числа ~64% bash, C, C++, C#, Java, Perl, PHP, Python, Visual Basic, Swift, многие другие Использует арабские цифры 0–9 и латинские буквы A–Z (базовый латинский алфавит ISO). Часто используется в системах перенаправления URL, таких как TinyURL или SnipURL/Snipr, в качестве компактных буквенно-цифровых идентификаторов. Base45 Произвольные ~67% (97%) Go, Python Определено в спецификации IETF RFC 9285 для компактного включения бинарных данных в QR-код. Base56 Целые числа — PHP, Python, Go Вариант кодирования Base58, который дополнительно исключает символы '1' и строчную 'o' для минимизации риска мошенничества и ошибок при вводе данных. Base58 Целые числа ~73% C, C++, Python, C#, Java Похоже на Base64, но модифицировано для исключения не буквенно-цифровых символов (+ и /), а также букв, которые могут выглядеть неоднозначно при печати (0 – ноль, I – заглавная i, O – заглавная o и l – строчная l). Base58 используется для представления адресов Bitcoin. Некоторые системы обмена сообщениями и социальных сетей разбивают строки на не буквенно-цифровых символах. Этого можно избежать, не используя зарезервированные символы URI, такие как +. Для SegWit оно было заменено на Bech32, см. ниже. Base62 Произвольные ~74% Rust, Python Похоже на Base64, но содержит только буквенно-цифровые символы. Base64 Произвольные 75% awk, C, C (2), Delphi, Go, Python, многие другие Раннее и до сих пор популярное кодирование, впервые определенное в 1987 году. Base85 Произвольные 80% C, Python, Python (2) Пересмотренная версия Ascii85. Base91 Произвольные 81% C#, F# Вариант фиксированной ширины basE91 Произвольные 81% C, Java, PHP, 8086 Assembly, AWK, C#, F#, Rust Вариант переменной ширины Base94 Произвольные 82% Python, C, Rust Base122 Произвольные 87,5% JavaScript, Python, Java Base125 Python и Javascript, Go, C BaseXML Произвольные 83,5% C, Python, JavaScript Bech32 Произвольные 62,5% + минимум 8 символов (метка, разделитель, 6 символов ECC) C, C++, JavaScript, Go, Python, Haskell, Ruby, Rust Спецификация. Используется в Bitcoin и Lightning Network. Данные кодируются как Base32 с возможностью проверки и исправления до 6 опечаток с помощью 6-символьного BCH-кода в конце, который также проверяет/исправляет удобочитаемую человеком часть. Вариант Bech32m имеет небольшое изменение, которое делает его более устойчивым к изменениям длины. BinHex Произвольные 75% Perl, C, C (2) MacOS Classic Decimal Целые числа ~42% Большинство языков Обычно используется для представления входных/выходных данных для людей. Hexadecimal (Base16) Произвольные 50% Большинство языков Существует в вариантах с заглавными и строчными буквами. Intel HEX Произвольные ≲50% C library, C++ Обычно используется для программирования EPROM и NOR flash-памяти. MIME Произвольные См. Quoted printable и Base64 См. Quoted printable и Base64 Контейнер кодирования для форматирования электронной почты. Percent encoding Текст (URI), Произвольные (RFC1738) ~40% (33–70%) C, Python, вероятно, многие другие Quoted printable Текст ~33–100% Вероятно, многие Сохраняет переносы строк; обрезает строки до 76 символов. S record (Motorola hex) Произвольные 49,6% C library, C++ Обычно используется для программирования EPROM и NOR flash-памяти. 49,6% предполагает 255 двоичных байт на запись. Tektronix hex Произвольные Обычно используется для программирования EPROM и NOR flash-памяти. Uuencoding Произвольные ~60% (до 70%) Perl, C, Delphi, Java, Python, вероятно, многие другие Раннее кодирование, разработанное в 1980 году для Unix to Unix Copy. В значительной степени заменено MIME и yEnc. Xxencoding Произвольные ~75% (похоже на Uuencoding) C, Delphi Предложено (и иногда используется) в качестве замены Uuencoding для устранения проблем с преобразованием наборов символов между ASCII и системами EBCDIC, которые могут повредить закодированные данные Uuencoding. z85 (ZeroMQ spec:32/Z85) Двоичные и ASCII 80% (похоже на Ascii85/Base85) C (оригинальный), C#, Dart, Erlang, Go, Lua, Ruby, Rust и другие Определяет подмножество ASCII, похожее на Ascii85, исключая некоторые символы, которые могут вызывать ошибки в программе (`\ " ' , ;). Формат соответствует спецификации ZeroMQ:32/Z85. (S/KEY) Произвольные 33% C, Каждое 64-битное число отображается в шесть коротких слов, каждое из одного-четырех символов, из общедоступного словаря 2048 слов. Коды от 32 до 126 из 95 являются известными как печатаемые символы ASCII. Некоторые старые и сегодня редко используемые форматы включают BOO, BTOA и USR. Большинство этих кодировок генерируют текст, содержащий только подмножество всех печатаемых символов ASCII: например, кодирование base64 генерирует текст, который содержит только буквы верхнего и нижнего регистра (A–Z, a–z), цифры (0–9) и символы "+", "/" и "=". Некоторые из этих кодировок (quoted printable и percent encoding) основаны на наборе разрешенных символов и одном управляющем символе. Разрешенные символы остаются неизменными, а все остальные символы преобразуются в строку, начинающуюся с управляющего символа. Этот тип преобразования позволяет получить почти читаемый текст, поскольку буквы и цифры являются частью разрешенных символов и, следовательно, остаются неизменными в закодированном тексте. Эти кодировки создают самый короткий вывод ASCII для входных данных, которые в основном состоят из печатаемых символов ASCII. Другие кодировки (base64, uuencoding) основаны на отображении всех возможных последовательностей из шести битов в различные печатаемые символы. Поскольку печатаемых символов больше 26 = 64, это возможно. Данная последовательность байтов преобразуется путем просмотра ее как потока битов, разбиения этого потока на фрагменты по шесть битов и создания последовательности соответствующих символов. Различные кодировки различаются отображением между последовательностями битов и символами, а также способом форматирования результирующего текста. Некоторые кодировки (оригинальная версия BinHex и рекомендуемое кодирование для CipherSaber) используют четыре бита вместо шести, отображая все возможные последовательности из 4 битов на 16 стандартных шестнадцатеричных цифр. Использование 4 битов на закодированный символ приводит к выходу на 50% длиннее, чем base64, но упрощает кодирование и декодирование — расширение каждого байта в источнике независимо до двух закодированных байтов проще, чем расширение 3 исходных байтов до 4 закодированных байтов в base64. Из первых 192 кодов PETSCII 164 имеют видимые представления при цитировании: 5 (белый), 17–20 и 28–31 (цвета и элементы управления курсором), 32–90 (эквивалент ascii), 91–127 (графика), 129 (оранжевый), 133–140 (функциональные клавиши), 144–159 (цвета и элементы управления курсором) и 160–192 (графика). Теоретически это позволяет создавать кодировки, такие как base128, между машинами, говорящими на PETSCII.

The table below compares the most used forms of binary to text encodings. The efficiency listed is the ratio between the number of bits in the input and the number of bits in the encoded output. Encoding Data type Efficiency Programming language implementations Comments Ascii85 Arbitrary 80% awk , C, C (2), C#, F#, Go, Java Perl, Python, Python (2) There exist several variants of this encoding, Base85, btoa, etc. Base32 Arbitrary 62.5% ANSI C, Delphi, Go, Java, C# F#, Python Base36 Integer ~64% bash, C, C++, C#, Java, Perl, PHP, Python, Visual Basic, Swift, many othersUses the Arabic numerals 0–9 and the Latin letters A–Z (the ISO basic Latin alphabet). Commonly used by URL redirection systems like TinyURL or SnipURL/Snipr as compact alphanumeric identifiers. Base45 Arbitrary ~67% (97%) Go, Python Defined in IETF Specification RFC 9285 for including binary data compactly in a QR code. Base56 Integer — PHP, Python, Go A variant of Base58 encoding which further sheds the '1' and the lowercase 'o' characters in order to minimise the risk of fraud and human error. Base58 Integer ~73% C, C++, Python, C#, Java Similar to Base64, but modified to avoid both non alphanumeric characters (+ and /) and letters that might look ambiguous when printed (0 zero, I capital i, O capital o and l lower case L). Base58 is used to represent bitcoin addresses. Some messaging and social media systems break lines on non alphanumeric strings. This is avoided by not using URI reserved characters such as +. For SegWit, it was replaced by Bech32, see below. Base62 Arbitrary ~74% Rust, Python Similar to Base64, but contains only alphanumeric characters. Base64 Arbitrary 75% awk , C, C (2), Delphi, Go, Python, many others An early and still popular encoding, first specified as part of in 1987 Base85 Arbitrary 80% C, Python, Python (2) Revised version of Ascii85. Base91 Arbitrary 81% C# F# Constant width variant basE91 Arbitrary 81% C, Java, PHP, 8086 Assembly, AWK C#, F#, Rust Variable width variant Base94 Arbitrary 82% Python, C, Rust Base122 Arbitrary 87.5% JavaScript, Python, Java, Base125 Python and Javascript, Go, C BaseXML Arbitrary 83.5% C Python JavaScript Bech32 Arbitrary 62.5% + at least 8 chars (label, separator, 6 char ECC) C, C++, JavaScript, Go, Python, Haskell, Ruby, Rust Specification. Used in Bitcoin and the Lightning Network. The data portion is encoded like Base32 with the possibility to check and correct up to 6 mistyped characters using the 6 character BCH code at the end, which also checks/corrects the Human Readable Part. The Bech32m variant has a subtle change that makes it more resilient to changes in length. BinHex Arbitrary 75% Perl, C, C (2) MacOS Classic Decimal Integer ~42% Most languages Usually the default representation for input/output from/to humans. Hexadecimal (Base16) Arbitrary 50% Most languages Exists in uppercase and lowercase variants Intel HEX Arbitrary ≲50% C library, C++ Typically used to program EPROM, NOR flash memory chips MIME Arbitrary See Quoted printable and Base64 See Quoted printable and Base64 Encoding container for e mail like formatting Percent encoding Text (URIs), Arbitrary (RFC1738) ~40% (33–70%) C, Python, probably many others Quoted printable Text ~33–100% Probably many Preserves line breaks; cuts lines at 76 characters S record (Motorola hex) Arbitrary 49.6% C library, C++ Typically used to program EPROM, NOR flash memory chips. 49.6% assumes 255 binary bytes per record. Tektronix hex Arbitrary Typically used to program EPROM, NOR flash memory chips. Uuencoding Arbitrary ~60% (up to 70%) Perl, C, Delphi, Java, Python, probably many others An early encoding developed in 1980 for Unix to Unix Copy. Largely replaced by MIME and yEnc Xxencoding Arbitrary ~75% (similar to Uuencoding) C, Delphi Proposed (and occasionally used) as replacement for Uuencoding to avoid character set translation problems between ASCII and the EBCDIC systems that could corrupt Uuencoded data z85 (ZeroMQ spec:32/Z85) Binary & ASCII 80% (similar to Ascii85/Base85) C (original), C#, Dart, Erlang, Go, Lua, Ruby, Rust and others Specifies a subset of ASCII similar to Ascii85, omitting a few characters that may cause program bugs (` \ " ' , ;). The format conforms to ZeroMQ spec:32/Z85. (S/KEY) Arbitrary 33% C, Each 64 bit number is mapped to six short words, of one to four characters each, from a public 2048 word dictionary. The 95 isprint codes 32 to 126 are known as the ASCII printable characters. Some older and today uncommon formats include BOO, BTOA, and USR encoding. Most of these encodings generate text containing only a subset of all ASCII printable characters: for example, the base64 encoding generates text that only contains upper case and lower case letters, (A–Z, a–z), numerals (0–9), and the "+", "/", and "=" symbols. Some of these encoding (quoted printable and percent encoding) are based on a set of allowed characters and a single escape character. The allowed characters are left unchanged, while all other characters are converted into a string starting with the escape character. This kind of conversion allows the resulting text to be almost readable, in that letters and digits are part of the allowed characters, and are therefore left as they are in the encoded text. These encodings produce the shortest plain ASCII output for input that is mostly printable ASCII. Some other encodings (base64, uuencoding) are based on mapping all possible sequences of six bits into different printable characters. Since there are more than 26 = 64 printable characters, this is possible. A given sequence of bytes is translated by viewing it as a stream of bits, breaking this stream in chunks of six bits and generating the sequence of corresponding characters. The different encodings differ in the mapping between sequences of bits and characters and in how the resulting text is formatted. Some encodings (the original version of BinHex and the recommended encoding for CipherSaber) use four bits instead of six, mapping all possible sequences of 4 bits onto the 16 standard hexadecimal digits. Using 4 bits per encoded character leads to a 50% longer output than base64, but simplifies encoding and decoding—expanding each byte in the source independently to two encoded bytes is simpler than base64's expanding 3 source bytes to 4 encoded bytes. Out of PETSCII's first 192 codes, 164 have visible representations when quoted: 5 (white), 17–20 and 28–31 (colors and cursor controls), 32–90 (ascii equivalent), 91–127 (graphics), 129 (orange), 133–140 (function keys), 144–159 (colors and cursor controls), and 160–192 (graphics). This theoretically permits encodings, such as base128, between PETSCII speaking machines.