Таблица алфавита Base64

64 символа

Base64 читает входные данные по 3 байта (24 бита) и делит их на четыре 6-битных числа. Каждое число от 0 до 63 – это индекс в таблице ниже. Порядок закреплён в RFC 4648: заглавные буквы для 0–25, строчные для 26–51, цифры для 52–61, затем + и /. В последнем столбце указан ASCII-код символа: именно он в итоге хранится или передаётся.

Два диапазона стоит запомнить. Все символы от A до P (0–15) начинаются с битов 00, а все символы от w до / (48–63) – с 11. Этого хватает, чтобы разобрать символ в уме, когда проверяете префикс вручную. Подробный пример разбиения на биты есть в статье как работает Base64.

Порядок алфавита не совпадает с порядком ASCII. В ASCII сначала идут + и /, потом цифры, потом заглавные и строчные буквы. Поэтому сортировка строк Base64 не сортирует исходные байты: +A== (байт F8) окажется раньше AA== (байт 00). Если нужны закодированные значения, которые сортируются так же, как сырые байты, берите base32hex из RFC 4648 или обычный hex.

URL-safe алфавит

У + и / в URL особый смысл. В строке запроса и данных формы + декодируется в пробел, а / разделяет сегменты пути. Base64URL, описанный в разделе 5 RFC 4648, оставляет индексы 0–61 как есть и меняет два последних:

Всё остальное, включая раскладку битов, совпадает, поэтому перевод из одного варианта в другой – это замена символов плюс добавление или удаление дополнения. Base64URL, обычно без =, используют JWT, многие API-токены и идентификаторы, которые должны годиться для имён файлов. Кодировщик Base64URL выдаёт его сразу. Полное сравнение приведено в статье Base64 и Base64URL.

Символ дополнения

= (ASCII 0x3D) не входит в алфавит из 64 символов и никогда не кодирует данные. Он только заполняет последнюю группу из 4 символов, когда длина входных данных не кратна 3:

• остался 1 байт: 2 символа данных плюс ==;
• осталось 2 байта: 3 символа данных плюс =;
• лишних байтов нет: дополнения нет.

Поэтому длина строки с дополнением всегда кратна 4, а === не бывает. Без дополнения остаток от деления длины на 4 равен 0, 2 или 3, но никогда 1. Когда = можно опустить и как его восстановить, рассказано в статье про дополнение.

Какие символы где встречаются

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

Перед == бывают только A, Q, g или w. Когда остаётся один байт, второй символ несёт 2 бита данных и 4 нулевых бита, так что его индекс равен 0, 16, 32 или 48. Перед одиночным = у третьего символа в конце 2 нулевых бита, поэтому это один из 16 символов: A E I M Q U Y c g k o s w 0 4 8. Любой другой символ на этом месте означает неканоническую кодировку, и строгие декодеры такую строку отвергают.

Случайные байты используют все 64 символа поровну. Каждая 6-битная группа случайных данных распределена равномерно, поэтому у зашифрованных данных, ключей и сжатых файлов распределение символов плоское. Перекос в распределении подсказывает, что внутри текст или данные со структурой.

В ASCII-тексте первым символом группы не бывает строчных от g до z, цифр, + и /. Первый символ каждой 4-символьной группы содержит старшие 6 бит байта. У 7-битного ASCII старший бит равен 0, так что этот символ всегда лежит между A и f (индексы 0–31). В SGVsbG8gd29ybGQh (Hello world!) группы начинаются с S, b, d и b.

В Base64 от ASCII-текста + и / редки. Для байтов меньше 0x80 символ + может появиться только четвёртым в группе, когда третий байт – > или ~. / может стоять там же, только если этот байт – ? или управляющий символ DEL. Вот почему Hi?> кодируется в SGk/Pg==, а <b> – в PGI+.

Цепочки A – это нулевые байты, цепочки / – байты 0xFF. AAAA – три байта 00, //// – три байта FF. Длинные отрезки из A типичны для разреженных двоичных форматов, текста в UTF-16 (Hello – это SABlAGwAbABvAA==) и полей длины в начале SSH-ключей. Другие узнаваемые шаблоны собраны в статье частые префиксы Base64.

Другие алфавиты Base64

Некоторые системы сохранили идею 64 символов на 6 бит, но выбрали другие символы:

• IMAP заменяет / на ,, потому что / часто служит разделителем иерархии в именах ящиков. Папка Entwürfe хранится как Entw&APw-rfe.
• bcrypt переносит . и / в начало и ставит буквы перед цифрами. Его соли и хеши – это Base64 в таком алфавите без дополнения, поэтому стандартный декодер выдаёт для них не те байты.
• crypt(3) использует ./0-9A-Za-z, то есть порядок ASCII. К тому же он упаковывает биты начиная с младших, так что даже с перекодированным алфавитом стандартный декодер не восстановит байты хеша.
• uuencode и xxencode старше MIME. Инструменты uuencode и xxencode умеют и кодировать, и декодировать.

Про кодировки с алфавитами другого размера, такие как Base32, Base58 и Base85, читайте в статье Base64, hex, Base32, Base58 и Base85. Определения терминов с этой страницы – в глоссарии.

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