Кодування двійкових даних у вигляді тексту — це кодування даних у вигляді звичайного тексту. Точніше, це кодування двійкових даних у вигляді послідовності друкованих символів. Таке кодування необхідне для передачі даних, коли канал зв’язку не дозволяє передавати двійкові дані (наприклад, електронна пошта чи NNTP) або не є суто 8-бітовим. Документація PGP () використовує на позначення кодування двійкових даних у вигляді тексту термін «броня ASCII», коли мова йде про Base64.

Огляд Основа потреби в кодуванні двійкового формату в текст виникає через потребу передавати довільні двійкові дані через наявні протоколи зв’язку, які були розроблені для передачі лише зрозумілого людям тексту англійською мовою. Ці протоколи зв’язку можуть бути безпечними лише на рівні 7 бітів (а отже, упускати частину керівних кодів ASCII), можуть вимагати розривів рядків з певною мінімальною частотою, і можуть не підтримувати пробіли. Таким чином, лише 94 друковані символи ASCII є "безпечними" для використання в передачі даних.

Опис Стандарт кодування тексту ASCII використовує 7 бітів для кодування символів. Завдяки цьому можна закодувати 128 (тобто 27) унікальних значень (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 11012 0x0D (158).

На противагу цьому, більшість комп’ютерів зберігають дані в пам’яті, організованій у восьмибітових байтах. Файли, які містять машинно-виконуваний код і нетекстові дані, зазвичай містять усі 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 тощо.Base32Arbitrary62.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, який ще більше уникає використання символів 'i' та 'o', щоб мінімізувати ризик шахрайства та людської помилки.Base58Ціле число~73%C++, Python, C#, JavaПодібний до Base64, але модифікований для уникання як нелітерно-цифрових символів (+ і /), так і літер, що можуть мати неоднозначний вигляд при друку (0 нуль, I велика i, O велика o й l мала L). Base58 використовується для представлення адрес біткойну. Частина систем спілкування та соціальних мереж додає розриви рядків у рядках, що не є літерно-цифровими. Цього уникли, не використовуючи символи, зарезервовані в URI, наприклад, +. У SegWit це кодування замінили Bech32, дивіться нижче.Base62Довільний~74%RustПодібний до 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Специфікація. Використовується у Біткойні та Lightning Network. Порція даних кодується як Base32 з можливістю перевірити та скоригувати до 6 хибних символів, завдяки 6 символам коду БЧХ у кінці, що також перевіряє та виправляє частину для людського прочитання. Варіант Bech32m має незначні зміни, завдяки яким він більш стійкий до змін довжини.BinHexДовільний75%Perl, C, C (2)MacOS ClassicДесятковеЦіле число~42%Більшість мовЗазвичай усталене представлення для введення чи виведення при взаємодії з людськими істотами.Шістнадцяткове (Base16)Довільний50%Більшість мовІснує у варіантах з великими та малими літерамиIntel HEXДовільний≲50%Бібліотека C, C++Здебільшого використовується для програмування мікросхем пам'яті EPROM і флешпам'яті типу NORMIMEДовільнийДив. Quoted-printable і Base64Див. Quoted-printable і Base64Контейнер кодування для форматування, що нагадує форматування листів електронної поштиВідсоткове кодуванняТекст (URI), Довільний (RFC1738)~40% (33–70%)C, Python, можливо, чимало інших Quoted-printableТекст~33–100%Можливо, чималоЗберігає розриви рядків; обрізає рядки після 76 символівS-record (шістнадцяткове Motorola)Довільний49.6%Бібліотека C, C++Здебільшого використовується для програмування мікросхем пам'яті EPROM і флешпам'яті типу NOR. Ефективність 49,6% обчислена виходячи з розміру запису 255 двійкових байтів.Tektronix hexДовільнийЗдебільшого використовується для програмування мікросхем пам'яті EPROM і флешпам'яті типу NOR.UuencodingДовільний~60% (до 70%)Perl, C, Delphi, Java, Python, можливо, чимало іншихДавнє кодування, розроблене в 1980 році для Unix-to-Unix Copy. Здебільшого замінене MIME та yEncXxencodingДовільний~75% (подібна до Uuencoding)C, DelphiКодування, запропоноване (та подекуди використовується) як заміна для Uuencoding, щоб уникати проблем перекладу наборів символів між ASCII і системами EBCDIC, що можуть пошкоджувати дані, закодовані Uuencodingz85 (ZeroMQ spec:32/Z85)Двійковий та ASCII80% (подібна до Ascii85/Base85)C (оригінал), C#, Dart, Erlang, Go, Lua, Ruby, Rust та іншіЗадає підмножину ASCII, подібно до Ascii85, пропускаючи кілька символів, що можуть призводити до вад програм (` \ " ' _ , ;). Цей формат відповідає ZeroMQ spec:32/Z85. (S/KEY)Довільний33%C, "The S/KEY One-Time Password System". Python"Домовленість щодо 128-бітових ключів, доступних для прочитання людьми". Послідовність невеликих англійських слів людям легше читати, запам'ятовувати та друкувати, ніж десяткові числа чи інші системи кодування двійкових даних у вигляді тексту."A Convention for Human-Readable 128-bit Keys" Кожне 64-бітове число відображене у вигляді шести коротких слів, кожне з яких має від одного до чотирьох символів, з публічного словника з 2048 слів. Коди isprint 95 від 32 до 126 відомі як друковані символи ASCII.

Серед старіших та нині вже непоширених форматів – кодування BOO, BTOA та USR.

Більшість цих кодувань генерує текст, що містить лише підмножину всіх друкованих символів ASCII: наприклад, кодування base64 генерує текст, який містить лише великі та малі літери (A–Z, a–z), цифри (0–9), а також символи «+», «/» і «=».

Деякі з цих кодувань (quoted-printable і відсоткове кодування) базуються на наборі дозволених символів і одному символі екранування. Дозволені символи залишаються незмінними, тоді як усі інші символи перетворюються з додаванням перед ними символу екранування. Такий вид перетворення дає змогу отримати текст, який майже можна читати, оскільки серед дозволених символів є літери та цифри, тож вони залишаються такими, як вони є в закодованому тексті. Ці кодування створюють найкоротший звичайний вивід ASCII для введення, яке здебільшого складається з друкованих символів ASCII.

Деякі інші кодування (base64, uuencoding) засновані на відображенні всіх можливих послідовностей із шести бітів на різні друковані символи. Оскільки друкованих символів більше 26 = 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 (графіка).http://sta.c64.org/cbm64pet.html et al Це теоретично дозволяє кодування, наприклад base128, між машинами, що спілкуються на PETSCII.

Дивіться також

Літерно-цифровий шеллкод Кодування символів Компіляція Системи числення

Примітки

Джерела