 | Эта статья поднимает множество проблем. Пожалуйста, помогите улучшить его или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалить эти сообщения-шаблоны ) ( Узнайте, как и когда удалить этот шаблон сообщения )
|
Кодирования двоичного в текст является кодирующими из данных в виде простого текста . Точнее, это кодирование двоичных данных в последовательности печатаемых символов . Эти кодировки необходимы для передачи данных, когда канал не позволяет передавать двоичные данные (например, электронная почта или NNTP ) или не является 8-битным чистым . В документации PGP ( RFC 4880 ) используется термин « броня ASCII » для двоичного кодирования текста при обращении к Base64 .
Описание [ править ]
Стандарт кодирования текста ASCII использует 128 уникальных значений (0–127) для представления алфавитных, цифровых и знаков пунктуации, обычно используемых в английском языке , а также набор управляющих кодов, которые не представляют печатные символы. Например, заглавная буква A - это символ ASCII 65, цифра 2 - это ASCII 50, символ } - это ASCII 125, а возврат каретки метасимвола - ASCII 13. Системы, основанные на ASCII, используют семь битов для представления этих значений в цифровом виде.
Напротив, большинство компьютеров хранят данные в памяти, организованные в восьмиразрядные байты . Файлы, содержащие машинно-исполняемый код и нетекстовые данные, обычно содержат все 256 возможных восьмибитовых байтовых значений. Многие компьютерные программы стали полагаться на это различие между семибитным текстом и восьмиразрядными двоичными данными и не могли бы работать должным образом, если бы не-ASCII-символы появлялись в данных, которые, как ожидалось, должны были включать только текст ASCII. Например, если значение восьмого бита не сохраняется, программа может интерпретировать значение байта выше 127 как флаг, указывающий на выполнение некоторой функции.
Однако часто бывает желательно иметь возможность отправлять нетекстовые данные через текстовые системы, например, когда можно прикрепить файл изображения к сообщению электронной почты. Для этого данные каким-то образом кодируются, так что восьмибитовые данные кодируются в семибитные символы ASCII (обычно с использованием только буквенно-цифровых символов и знаков пунктуации - печатаемых символов ASCII ). После безопасного прибытия в пункт назначения он затем декодируется обратно в свою восьмибитную форму. Этот процесс называется двоичным кодированием текста. Многие программы выполняют это преобразование для передачи данных, например PGP и GNU Privacy Guard (GPG).
Кодирование обычного текста [ править ]
Методы двоичного кодирования в текст также используются в качестве механизма кодирования обычного текста . Например:
- Некоторые системы имеют более ограниченный набор символов, с которым они могут работать; они не только не являются 8-битными чистыми , некоторые даже не могут обрабатывать каждый печатаемый символ ASCII.
- В других системах есть ограничения на количество символов, которые могут появляться между разрывами строки , например ограничение «1000 символов на строку» для некоторых программ SMTP , как разрешено RFC 2821 .
- Третьи добавляют к тексту заголовки или трейлеры .
- Несколько плохо известных, но все еще используемых протоколов используют внутриполосную сигнализацию , вызывая путаницу, если в сообщении появляются определенные шаблоны. Наиболее известной является строка «От» (включая конечный пробел) в начале строки, используемой для разделения почтовых сообщений в формате файла mbox .
Используя двоичное кодирование в сообщениях, которые уже представляют собой обычный текст, а затем декодируя на другом конце, можно сделать такие системы полностью прозрачными . Иногда это называют «бронированием ASCII». Например, компонент ViewState в ASP.NET использует кодировку base64 для безопасной передачи текста через HTTP POST, чтобы избежать коллизии разделителей .
Стандарты кодирования [ править ]
В таблице ниже сравниваются наиболее часто используемые формы двоичного кодирования текста. Указанная эффективность - это соотношение между количеством бит на входе и количеством бит в закодированном выходе.
| Кодирование | Тип данных | Эффективность | Реализации языков программирования | Комментарии |
|---|---|---|---|---|
| ASCII | Произвольный | 12,5% | Большинство языков | |
| Ascii85 | Произвольный | 80% | awk , C , C (2) , C # , F # , Go , Java Perl , Python , Python (2) | Существует несколько вариантов этой кодировки, Base85 , btoa и так далее. |
| Base32 | Произвольный | 62,5% | ANSI C , Java , Python | |
| Base36 | Целое число | ~ 64% | bash , C , C ++ , C # , Java , Perl , PHP , Python , Visual Basic , Swift и многие другие | Используются арабские цифры 0–9 и латинские буквы A – Z ( основной латинский алфавит ISO ). Обычно используется системами перенаправления URL-адресов, такими как TinyURL или SnipURL / Snipr, в качестве компактных буквенно-цифровых идентификаторов. |
| Base58 | Целое число | ~ 73% | C ++ , Python | Аналогичен Base64, но изменен, чтобы избежать использования не буквенно-цифровых символов (+ и /) и букв, которые могут выглядеть неоднозначно при печати (0 - ноль, I - заглавная i, O - заглавная o и l - строчная L). Сатоши Накамото изобрел схему кодирования base58 при создании биткойнов . [1] Некоторые системы обмена сообщениями и социальных сетей прерывают строку не буквенно-цифровыми строками. Этого можно избежать, если не использовать зарезервированные символы URI, такие как +. Для segwit его заменили на Bech32, см. Ниже. Base58 в исходном исходном коде биткойнов |
| Base62 | Аналогичен Base64, но содержит только буквенно-цифровые символы. | |||
| Base64 | Произвольный | 75% | awk , C , C (2) , Python , многие другие | |
| Base85 ( RFC 1924 ) | Произвольный | 80% | C , Python Python (2) | Доработанная версия Ascii85 . |
| Bech32 | 1 бит (основная или тестовая) плюс от 3 до 40 байт | не простой процент, так как имеет 6-байтовый код исправления ошибок | C, C ++, JavaScript, Go, Python, Haskell, Ruby, Rust | Спецификация . Используется в биткойнах и сети Lightning . [2] |
| BinHex | Произвольный | 75% | Perl , C , C (2) | MacOS Classic |
| Десятичный | Целое число | ~ 42% | Большинство языков | Обычно представление по умолчанию для ввода / вывода от / для людей. |
| Шестнадцатеричный (Base16) | Произвольный | 50% | Большинство языков | Существует в вариантах верхнего и нижнего регистра |
| Intel HEX | Произвольный | ~ <50% | Библиотека C , C ++ | Обычно используется для программирования микросхем памяти EPROM , NOR-Flash. |
| MIME | Произвольный | Смотрите Quoted-printable и Base64 | Смотрите Quoted-printable и Base64 | Контейнер кодирования для форматирования электронной почты |
| Формат файлов MOS Technology | Произвольный | Обычно используется для программирования микросхем памяти EPROM , NOR-Flash . | ||
| Процентное кодирование | Текст ( URI ), произвольный ( RFC1738 ) | ~ 40% [а] (33–70% [б] ) | C , Python , возможно, многие другие | |
| Цитата для печати | Текст | ~ 33–100% [c] | Наверное, многие | Сохраняет разрывы строк; обрезает строки по 76 символов |
| S-запись (Motorola hex) | Произвольный | 49,6% | Библиотека C , C ++ | Обычно используется для программирования микросхем памяти EPROM , NOR-Flash . 49,6% предполагает 255 двоичных байтов на запись. |
| Tektronix шестнадцатеричный | Произвольный | Обычно используется для программирования микросхем памяти EPROM , NOR-Flash . | ||
| Uuencoding | Произвольный | ~ 60% ( до 70% ) | Perl , C , Java , Python , возможно, многие другие | В значительной степени заменен на MIME и yEnc |
| Xxencoding | Произвольный | ~ 75% (аналогично Uuencoding) | C | Предлагается (и иногда используется) в качестве замены Uuencoding, чтобы избежать проблем с преобразованием набора символов между системами ASCII и EBCDIC, которые могут повредить данные Uuencoded. |
| yEnc | Произвольные, в основном нетекстовые | ~ 98% | C | Включает контрольную сумму CRC |
| RFC 1751 ( S / KEY ) | Произвольный | 33% | C, [3] Python , ... | «Соглашение о 128-битных ключах, удобочитаемых человеком ». Ряд маленьких английских слов легче читать, запоминать и набирать, чем десятичные или другие системы кодирования двоичного текста. [4] Каждое 64-битное число сопоставляется с шестью короткими словами от одного до четырех символов каждое из общедоступного словаря на 2048 слов. [3] |
95 кодов печати с 32 по 126 известны как печатаемые символы ASCII .
Некоторые старые и сегодня необычные форматы включают кодировку BOO, BTOA и USR.
Большинство этих кодировок генерируют текст, содержащий только подмножество всех печатаемых символов ASCII : например, кодировка base64 генерирует текст, который содержит только прописные и строчные буквы (A – Z, a – z), цифры (0–9) , а также символы «+», «/» и «=».
Некоторые из этих кодировок (кавычки-печать и процентное кодирование) основаны на наборе разрешенных символов и одном escape-символе . Разрешенные символы остаются неизменными, а все остальные символы преобразуются в строку, начинающуюся с escape-символа. Такое преобразование позволяет полученному тексту быть почти читаемым, поскольку буквы и цифры являются частью разрешенных символов и, следовательно, остаются такими, как они есть в закодированном тексте. Эти кодировки обеспечивают самый короткий простой вывод ASCII для ввода, который в основном является печатаемым ASCII.
Некоторые другие кодировки ( base64 , uuencoding ) основаны на отображении всех возможных последовательностей из шести битов в различные печатаемые символы. Поскольку имеется более 2 6 = 64 печатных символа, это возможно. Данная последовательность байтов транслируется, рассматривая ее как поток битов, разбивая этот поток на блоки по шесть бит и генерируя последовательность соответствующих символов. Различные кодировки различаются отображением между последовательностями битов и символов и форматированием результирующего текста.
Некоторые кодировки (исходная версия BinHex и рекомендуемая кодировка для CipherSaber ) используют четыре бита вместо шести, отображая все возможные последовательности из 4 бит на 16 стандартных шестнадцатеричных цифр. Использование 4 бита на кодированный символ приводит к увеличению длины вывода на 50% по сравнению с base64, но упрощает кодирование и декодирование - расширение каждого байта в источнике независимо до двух закодированных байтов проще, чем расширение base64 с 3 исходных байтов до 4 закодированных байтов.
Из первых 192 кодов PETSCII 164 имеют видимые изображения в кавычках: 5 (белый), 17–20 и 28–31 (цвета и элементы управления курсором), 32–90 (эквивалент ascii), 91–127 (графика), 129 (оранжевый), 133–140 (функциональные клавиши), 144–159 (цвета и элементы управления курсором) и 160–192 (графика). [5] Это теоретически разрешает кодирование, такое как base128, между машинами, говорящими на языке PETSCII.
Заметки [ править ]
- ^ Для произвольных данных; кодирует все 189 незарезервированных символов тремя байтами, а оставшиеся 66 символов - одним.
- ^ Для текста; кодирует только каждый из 18 зарезервированных символов.
- ^ Один байт хранится как = XX. Кодирует все, кроме 94 символов, которые в этом не нуждаются (включая пробел и табуляцию).
Ссылки [ править ]
- ^ «Схема кодирования Base58» . Инженерная группа Интернета . 27 ноября, 2019. Архивировано из оригинального 12 августа 2020 года . Проверено 12 августа 2020 года .
Спасибо Сатоши Накамото за изобретение формата кодирования Base58.
- ^ Расти Рассел ; и другие. (2020-10-15). « Кодирование платежей в репозитории Lightning RFC» .
- ^ a b RFC 1760 «Система одноразовых паролей S / KEY».
- ^ RFC 1751 «Соглашение о 128-битных ключах, удобочитаемых человеком»
- ^ http://sta.c64.org/cbm64pet.html и др.
