Кодировщик и декодировщик Base64

Base64 появился потому, что значительная часть инфраструктуры, построенной вокруг текста — электронная почта, JSON, XML, URL, — не может надёжно передавать произвольные двоичные данные: в них могут встречаться управляющие символы, нулевые байты или последовательности байтов, которые преждевременно обрывают строку или вовсе ломают парсер. Base64 отображает каждые три байта произвольных двоичных данных на четыре символа из фиксированного набора 64 символов, с которыми безопасно работает любая текстовая система, — буквы, цифры и два дополнительных символа. Благодаря этому закодированный результат можно встроить в JSON, отправить как вложение письма или включить в документ, не рискуя, что что-то по пути ошибочно примет его не за обычный текст.

Издержки этой безопасности фиксированы и неизбежны: четыре символа на выходе на каждые три байта на входе — то есть увеличение объёма примерно на 33%, независимо от того, что именно представляют собой исходные данные. Это цена гарантированной безопасной передачи через исключительно текстовые каналы, а не недостаток какой-то конкретной реализации.

Встроенная функция браузера `btoa`, к которой напрямую обращаются многие быстрые реализации Base64, выбрасывает ошибку в тот момент, когда встречает любой символ с кодом выше U+00FF — а это практически все эмодзи, китайские, японские, корейские, кириллические, греческие и арабские символы, а также немало символов с диакритикой, используемых во французском, немецком, испанском и других языках. Это не какой-то редкий крайний случай, затрагивающий только необычные данные, — он касается очень большой доли реального текста, и именно поэтому так много самодельных инструментов для Base64 прекрасно работают в тестах с обычным английским текстом, а затем ломаются, как только пользователь вставляет что-то с эмодзи или именем не на латинице.

Решение — сначала преобразовать текст в байты UTF-8, а затем закодировать уже эти байты в Base64. Именно так работают правильно реализованные кодировщики и именно так работает этот инструмент — вместо попытки напрямую передать кодовые точки Unicode в кодировку, рассчитанную на последовательности байтов от 0 до 255.

В набор символов обычного Base64 входят `+` и `/`, причём оба этих символа имеют особое значение в URL — `+` иногда интерпретируется как пробел, а `/` служит разделителем пути. Поэтому обычная строка Base64, вставленная прямо в строку запроса или имя файла, может незаметно повредиться или обрезаться при прохождении через то, что её разбирает. Base64URL заменяет эти два символа на `-` и `_`, ни один из которых не несёт особого смысла в URL, а также обычно отбрасывает завершающие символы `=`, которые нужны лишь для обозначения длины и не требуются, если декодер и так знает, чего ожидать.

JSON Web Token используют Base64URL именно по этой причине: JWT рассчитан на передачу в HTTP-заголовке Authorization, а иногда и в URL, и зарезервированные символы обычного Base64 сделали бы это ненадёжным.

Об этом стоит сказать прямо, потому что такое заблуждение встречается часто: Base64 не даёт никакой конфиденциальности. В процессе нет никакого секретного ключа, поэтому любой, кто получит строку Base64, может мгновенно декодировать её обратно в исходные данные — с помощью обычного вызова стандартной библиотеки или инструмента вроде этого. Кодирование пароля или API-ключа в Base64 перед сохранением или передачей не даёт никакой защиты — оно лишь скрывает значение от беглого взгляда, а это совсем не то же самое, что настоящая безопасность.