Глоссарий Base64

A – C

Алфавит (alphabet)

Набор символов, которыми пишет кодировка, в порядке индексов. Стандартный Base64 использует A-Z, a-z, 0-9, + и /, так что A означает 0, а / – 63. См. таблицу алфавита.

ASN.1

Abstract Syntax Notation One – язык описания структур данных, который используют сертификаты X.509, ключи и многие телеком-протоколы. ASN.1 задаёт структуру, а правила кодирования, такие как DER, задают байты.

Base16

Название hex в RFC 4648: каждый байт превращается в два символа из 0-9 A-F. Размер удваивается. Попробуйте инструмент Base16.

Base32

Кодировка из 32 символов (A-Z и 2-7 в RFC 4648), которая превращает 5 байт в 8 символов, то есть на 60% больше входных данных. Алфавиты, нечувствительные к регистру, хорошо подходят для секретов TOTP и DNS-имён. Попробуйте кодировщик Base32.

Base45

Описана в RFC 9285: превращает 2 байта в 3 символа из набора в 45 символов, который QR-коды хранят в буквенно-цифровом режиме. Её использовал цифровой COVID-сертификат ЕС. Попробуйте кодировщик Base45.

Base58

Алфавит Bitcoin из 58 символов: Base64 без 0, O, I, l, + и /. Он переводит весь вход как одно большое число, а каждый ведущий нулевой байт превращается в 1. Попробуйте кодировщик Base58.

Base58Check

Base58 с байтом версии в начале и 4-байтовой контрольной суммой в конце. Контрольная сумма – первые 4 байта двойного SHA-256. Его используют старые адреса Bitcoin и закрытые ключи в формате WIF. См. инструмент Base58Check.

Base64

Двоично-текстовая кодировка, которая записывает каждые 3 байта четырьмя символами из алфавита в 64 символа и дополняет конец знаками =. Результат примерно на 33% больше входных данных. Начните с кодировщика и декодера или прочитайте, как работает Base64.

Base64URL

Base64 с - и _ вместо + и / из раздела 5 RFC 4648. Дополнение часто опускают. Используется в JWT и URL. См. Base64 и Base64URL и кодировщик Base64URL.

Base85

Семейство кодировок, которые записывают 4 байта пятью символами, с ростом размера на 25%. Распространённые варианты – Ascii85 (Adobe, используется в PDF и PostScript), Z85 (ZeroMQ) и алфавит RFC 1924, который использует git. Попробуйте инструмент Base85.

Base91

basE91, созданный Йоахимом Хенке, использует 91 печатный символ ASCII и упаковывает 13 или 14 бит в каждую пару символов. Поэтому рост размера у него примерно от 14% до 23%, меньше всех в этом списке. Платить за это приходится алфавитом, в который входят двойная кавычка и множество других знаков препинания. Попробуйте инструмент Base91.

Basic Auth

Базовая HTTP-аутентификация (RFC 7617) передаёт user:password в Base64 в заголовке Authorization: Aladdin:open sesame превращается в Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==. Это кодирование, а не защита, поэтому нужен HTTPS. Собрать или прочитать такой заголовок можно генератором Basic Auth и декодером.

Двоично-текстовая кодировка (binary-to-text encoding)

Любая схема, которая представляет произвольные байты только печатными символами, чтобы данные пережили системы, рассчитанные на текст: почту, JSON или URL. Hex, Base32, Base64, Base85, uuencode и quoted-printable – всё это двоично-текстовые кодировки. Сравнение есть в статье Base64, hex, Base32, Base58 и Base85.

BOM

Byte order mark, метка порядка байтов – символ U+FEFF в начале текстового файла. В UTF-8 это EF BB BF (в Base64 77u/), в UTF-16LE – FF FE. Декодеры, которые его не ждут, показывают его как  или как лишний невидимый символ.

Каноническая кодировка (canonical encoding)

Единственная «правильная» закодированная форма данных. В Base64 она требует, чтобы неиспользуемые биты перед дополнением были нулевыми (RFC 4648, раздел 3.5): SGk/Pg== – каноническая форма, а SGk/Ph== нестрогие декодеры переводят в те же байты, но эта форма неканоническая.

Кодировка символов (charset)

Кодировка, которая сопоставляет тексту байты, например UTF-8, UTF-16LE или Windows-1252. Base64 хранит байты, поэтому, чтобы декодировать Base64 в текст, нужно знать, в какой кодировке текст был сохранён. Неверная догадка даёт кракозябры вроде Café. В инструменте Base64 в текст кодировку можно переключать.

CRLF

Возврат каретки плюс перевод строки, байты 0D 0A. MIME требует CRLF между строками Base64, а утилиты Unix обычно пишут только LF (0A). Нестрогие декодеры игнорируют оба варианта, строгие отвергают.

CSP nonce

Случайное значение в заголовке Content-Security-Policy (script-src 'nonce-…'), которое разрешает только те встроенные скрипты, у которых такой же атрибут nonce. Записывается в Base64, должно быть новым для каждого ответа и содержать не меньше 128 бит случайности. Сгенерировать его можно генератором CSP nonce.

D – J

Data URI

URL, который несёт сами данные, а не указывает на них; описан в RFC 2397: data:image/png;base64,iVBORw0KGgo…. Полезен для небольших картинок и иконок в HTML и CSS. См. генератор data URI, парсер и статью о производительности data URI.

Deflate

Алгоритм сжатия (RFC 1951) внутри ZIP, gzip, zlib и PNG. «Сырой deflate» (raw deflate) – это сжатый поток без заголовка и контрольной суммы вокруг. Сжать и закодировать можно инструментом zlib и deflate.

DER

Distinguished Encoding Rules – строгая двоичная кодировка структур ASN.1, описанная в ITU-T X.690. Сертификаты и ключи – это байты DER. Структура DER обычно начинается с 30 (SEQUENCE), поэтому тела PEM начинаются с M, часто с MII.

gzip

Формат файлов (RFC 1952), который оборачивает сжатые deflate данные 10-байтовым заголовком и контрольной суммой CRC-32. Он начинается с байтов 1F 8B, поэтому gzip в Base64 начинается с H4sI. Сжать поможет инструмент gzip и Base64, а распаковать – декодер gzip Base64.

Hex

Шестнадцатеричная запись: каждый байт записывается двумя цифрами из 0-9 и a-f, например 48 65 6c 6c 6f для Hello. Её легко читать побайтно, но она вдвое больше входных данных. Конвертировать можно инструментами Base64 в hex и hex в Base64.

JWE

JSON Web Encryption (RFC 7516). Зашифрованный токен, компактная форма которого состоит из пяти частей в Base64URL: заголовок, зашифрованный ключ, вектор инициализации, шифротекст и тег аутентификации. В отличие от JWS, содержимое без ключа не прочитать.

JWS

JSON Web Signature (RFC 7515). Подписанное сообщение из трёх частей в Base64URL: заголовок, полезная нагрузка и подпись. Полезную нагрузку может прочитать кто угодно, подпись лишь доказывает, что её не меняли.

JWT

JSON Web Token (RFC 7519) – набор claims в JSON внутри JWS или JWE. Большинство JWT, которые вам попадутся, – это токены JWS, начинающиеся с eyJ. Декодировать токен можно декодером JWT, создать – кодировщиком JWT, а подробнее читайте в статье Base64 в JWT.

L – Q

Перенос строк (line wrapping)

Вставка переводов строк в длинный вывод Base64. MIME переносит строки не длиннее 76 символов, PEM – ровно по 64. GNU base64 по умолчанию переносит через 76 (-w 0 отключает перенос), openssl base64 – через 64 (-A отключает). Кодировщик MIME перенесёт строки за вас.

Магическое число (magic number)

Фиксированная последовательность байтов в начале файла, по которой определяется формат, например %PDF- у PDF или 89 50 4E 47 у PNG. Поскольку Base64 кодирует по 3 байта, магические числа превращаются в узнаваемые префиксы Base64. См. частые префиксы Base64 и Base64 в файл.

MIME

Multipurpose Internet Mail Extensions (RFC 2045–2049) – стандарт, благодаря которому письма могут нести вложения и текст не в ASCII. Через его Content-Transfer-Encoding base64 вложения передаются внутри чисто текстового сообщения. См. Base64 в почте и декодер EML.

Дополнение (padding)

Знаки = в конце Base64, которые заполняют последнюю группу из 4 символов: ==, когда остался 1 байт, и =, когда осталось 2. Некоторые форматы дополнение отбрасывают. Читайте статью про дополнение.

PEM

Privacy-Enhanced Mail – изначально стандарт защищённой почты (RFC 1421). Сегодня так называют его текстовый формат для ключей и сертификатов: Base64 от байтов DER между строками -----BEGIN CERTIFICATE----- и -----END CERTIFICATE-----, перенесённый по 64 символа (RFC 7468). Посмотреть содержимое можно декодером сертификатов.

Quoted-printable

Вторая кодировка передачи в MIME. Печатные символы ASCII она оставляет как есть, а остальные байты записывает как = и две hex-цифры, так что Café в UTF-8 превращается в Caf=C3=A9. Экономна для текста, почти целиком состоящего из ASCII, и расточительна для двоичных данных. Попробуйте инструмент quoted-printable.

R – Z

Radix-64

Так в OpenPGP называется ASCII armor: стандартный Base64 плюс необязательная строка контрольной суммы, которая начинается с = и содержит CRC-24 в Base64. См. стандарты Base64.

SRI

Subresource Integrity – механизм браузера, который сверяет загруженный скрипт или таблицу стилей с хешем в атрибуте integrity, записанным как имя алгоритма плюс дайджест в Base64: sha384-…. Поддерживаются SHA-256, SHA-384 и SHA-512. Сгенерировать значения можно генератором SRI-хешей.

uuencode

Unix-to-Unix encoding – двоично-текстовый формат старше MIME. Каждая строка начинается с символа длины, а символы данных берутся из ASCII от 32 до 95, так что в нём есть знаки препинания, которых избегает Base64 из MIME. См. инструмент uuencode.

UTF-8

Основная кодировка текста в вебе. Символы ASCII занимают один байт, остальные – от двух до четырёх. Когда инструмент обещает «текст в Base64», почти всегда имеются в виду байты UTF-8 в Base64: é – это C3 A9. См. UTF-8 в Base64.

UTF-16LE

UTF-16 с младшим байтом впереди – внутренний формат строк в Windows и .NET. В ASCII-тексте в UTF-16LE после каждого символа идёт нулевой байт, поэтому Hello превращается в SABlAGwAbABvAA==, где много A. Его ждёт -EncodedCommand в PowerShell. См. UTF-16 в Base64 и декодер PowerShell.

Z85

Вариант Base85 от ZeroMQ (ZeroMQ RFC 32). Он кодирует 4 байта пятью символами, обходится без кавычек и обратной косой черты, чтобы вывод можно было вставить в строку исходного кода, и требует входных данных длиной, кратной 4 байтам. Попробуйте инструмент Z85.

zlib

Тонкая обёртка (RFC 1950) вокруг данных deflate: 2-байтовый заголовок и контрольная сумма Adler-32. Заголовок обычно начинается с 78, поэтому данные zlib в Base64 начинаются с eJ, eN, eF или eA в зависимости от уровня сжатия. Воспользуйтесь инструментом zlib.

Вопросы и ответы