stringtranslate.com

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

Кодирование двоичного текста в текст — это кодирование данных в виде обычного текста . Точнее, это кодирование двоичных данных в последовательность печатных символов . Эти кодировки необходимы для передачи данных, когда канал связи не допускает двоичных данных (например, электронная почта или NNTP ) или не является 8-битным . В документации PGP ( RFC  4880) используется термин « броня ASCII » для кодирования двоичного кода в текст при обращении к Base64 .

Обзор

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

Описание

Стандарт кодирования текста ASCII использует 7 бит для кодирования символов. При этом можно закодировать 128 (т.е. 2 7 ) уникальных значений (0–127) для представления буквенных, цифровых символов и символов пунктуации, обычно используемых в английском языке , а также набор управляющих символов , которые не представляют собой печатные символы. Например, заглавная буква A представлена ​​7 битами как 100 0001 2 , 0x41 (101 8 ), цифра 2 — 011 0010 2 0x32 (62 8 ), символ } — 111 1101 2 0x7D (175 8 ), и Управляющий символ RETURN — 000 1101 2 0x0D (15 8 ).

Напротив, большинство компьютеров хранят данные в памяти, организованной в восьмибитные байты . Файлы, содержащие машинно-исполняемый код и нетекстовые данные, обычно содержат все 256 возможных восьмибитных байтовых значений. Многие компьютерные программы стали полагаться на это различие между семибитным текстом и восьмибитными двоичными данными и не работали должным образом, если символы, отличные от ASCII, появлялись в данных, которые, как ожидалось, должны были включать только текст ASCII. Например, если значение восьмого бита не сохраняется, программа может интерпретировать значение байта выше 127 как флаг, указывающий ей выполнить некоторую функцию.

Однако часто желательно иметь возможность отправлять нетекстовые данные через текстовые системы, например, когда можно прикрепить файл изображения к сообщению электронной почты. Для этого данные каким-либо образом кодируются, например, восьмибитные данные кодируются в семибитные символы ASCII (обычно с использованием только буквенно-цифровых символов и знаков препинания — печатных символов ASCII). После благополучного прибытия в пункт назначения он затем декодируется обратно в восьмибитную форму. Этот процесс называется кодированием двоичного текста в текст. Многие программы выполняют это преобразование для обеспечения транспортировки данных, например PGP и GNU Privacy Guard .

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

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

Используя двоичное кодирование сообщений, которые уже являются обычным текстом, а затем декодируя их на другом конце, можно сделать такие системы полностью прозрачными . Иногда это называют «бронированием ASCII». Например, компонент ViewState ASP.NET использует кодировку base64 для безопасной передачи текста через HTTP POST во избежание коллизии разделителей .

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

В таблице ниже сравниваются наиболее используемые формы кодирования двоичного текста в текст. Указанная эффективность представляет собой соотношение между количеством бит на входе и количеством бит в закодированном выходе.

95 кодов isprint от 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, но упрощает кодирование и декодирование — независимое расширение каждого байта в источнике до двух закодированных байтов проще, чем расширение 3 исходных байтов в Base64 до 4 закодированных байтов.

Из первых 192 кодов PETSCII 164 имеют видимое представление в кавычках: 5 (белый), 17–20 и 28–31 (цвета и элементы управления курсором), 32–90 (эквивалент ascii), 91–127 (графика) , 129 (оранжевый), 133–140 (функциональные клавиши), 144–159 (цвета и управление курсором) и 160–192 (графика). [13] Это теоретически допускает кодировку, такую ​​как base128, между машинами, говорящими на PETSCII.

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

Примечания

  1. ^ Кодировка для генерации QR-кода автоматически выбирает кодировку, соответствующую входному набору символов, кодируя 2 буквенно-цифровых символа в 11 бит, а Base45 кодирует 16 бит в 3 таких символа. Таким образом, эффективность составляет 32 бита двоичных данных, закодированных в 33 бита: 97%.
  2. ^ Для произвольных данных; кодирование всех 189 незарезервированных символов тремя байтами, а остальных 66 символов - одним.
  3. ^ Для текста; кодирует только каждый из 18 зарезервированных символов.
  4. ^ Один байт хранится как =XX. Кодирование всех символов, кроме 94, которые в этом не нуждаются (включая пробел и табуляцию).

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

  1. ^ Фельтстрем, Патрик; Юнггрен, Фрейк; Гулик, Дирк-Виллем ван (11 августа 2022 г.). «Кодировка данных Base45». Даже в байтовом режиме типичное устройство для чтения QR-кода пытается интерпретировать последовательность байтов как текст, закодированный в UTF-8 или ISO/IEC 8859-1. ... Такие данные необходимо преобразовать в соответствующий текст, прежде чем этот текст можно будет закодировать в виде QR-кода. ... Base45 ... предлагает более компактное кодирование QR-кода.
  2. Дагган, Росс (18 августа 2009 г.). «Целочисленное кодирование Base-56 в PHP».
  3. ^ Дэйк Хэ; Ю Сун; Чжэнь Цзя; Сюин Юй; Вэй Го; Вэй Хэ; Чао Ци; Сяньхуэй Лу. «Предложение по замене Base85/64 – Base91» (PDF) . Международный институт информатики и системики .
  4. ^ «Двоичное кодирование текста в ASCII» . базаE91 . СоурсФордж . Проверено 20 марта 2023 г.
  5. ^ «Преобразуйте двоичные данные в текст с наименьшими затратами». Записки Воракла . 18 апреля 2020 г.
  6. Альбертсон, Кевин (26 ноября 2016 г.). «Кодировка Base-122».
  7. ^ «BaseXML — для XML1.0+». Гитхаб . 16 марта 2019 г.
  8. ^ "Биткойн/бипс". Гитхаб . 8 декабря 2021 г.
  9. ^ Расти Рассел ; и другие. (15 октября 2020 г.). «Кодирование платежей в репозитории Lightning RFC». Гитхаб .
  10. ^ «Формат Bech32m для адресов-свидетелей v1+» . Гитхаб . 5 декабря 2021 г.
  11. ^ ab RFC  1760 «Система одноразовых паролей S/KEY».
  12. ^ RFC  1751 «Соглашение об удобочитаемых 128-битных ключах»
  13. ^ http://sta.c64.org/cbm64pet.html и др.