Зачем нужен Base64
Base64 существует для того, чтобы передавать двоичные данные по каналам, рассчитанным на текст. Электронная почта, JSON, XML, атрибуты HTML, переменные окружения и HTTP-заголовки ожидают печатаемые символы, и многие из них ломаются на «сырых» байтах вроде нулевого, перевода строки или значений больше 127. Base64 переписывает любую последовательность байтов, используя всего 64 безопасных символа: A–Z, a–z, 0–9, + и /, а = служит дополнением.
Где он встречается чаще всего:
- В базовой HTTP-аутентификации, где
user:passwordпередаётся какdXNlcjpwYXNzd29yZA==. - В JSON Web Token, три части которого, разделённые точками, закодированы в URL-safe Base64.
- Во вложениях электронной почты, которые передаются в Base64 внутри MIME-сообщений.
- В data URI, которые встраивают маленькую иконку или шрифт прямо в HTML или CSS.
- В API-запросах и конфигурационных файлах, где сертификат, ключ или небольшой двоичный объект нужно передать строкой.
Base64 — это кодирование, а не шифрование. Любой раскодирует его за секунду, так что строка Base64 в конфиге ничего не защищает. Если нужно проверить, что данные не изменились, используйте хеш.
Как устроено кодирование
Кодировщик берёт входные данные по три байта, то есть по 24 бита, и разбивает их на четыре группы по 6 бит. Каждое 6-битное значение от 0 до 63 выбирает один символ из алфавита. На входе три байта, на выходе четыре символа — поэтому результат Base64 всегда примерно на 33% больше исходных данных: изображение на 30 КБ превращается примерно в 40 КБ текста.
Если длина входных данных не кратна трём, последняя группа оказывается неполной. Кодировщик дополняет её и отмечает недостачу одним или двумя знаками =. Поэтому Man кодируется в TWFu, Ma — в TWE=, а M — в TQ==.
Прежде чем текст можно закодировать, его нужно превратить в байты, и для этого шага инструмент всегда использует UTF-8. Слово café в UTF-8 занимает пять байтов (на é уходит два), а эмодзи — четыре. При декодировании байты снова читаются как UTF-8, так что текст на любом языке проходит туда и обратно без изменений.
Вариант URL-safe
Два символа стандартного алфавита создают проблемы за пределами обычного текста. В URL + может быть прочитан как пробел, а / — как разделитель пути; в имени файла / вообще запрещён. Алфавит URL-safe из RFC 4648 заменяет их на - и _.
Если отмечен флажок URL-safe, инструмент делает эту замену и заодно убирает завершающие знаки =, — именно в таком виде их ожидают JWT и большинство веб-API. Декодер принимает обе формы: он сам возвращает - и _ обратно и восстанавливает недостающее дополнение, так что можно вставить сегмент JWT напрямую и прочитать его JSON. Если этот JSON выходит одной длинной строкой, JSON-форматировщик сделает его читаемым.
Кодирование файлов в data URI
Кнопка «Закодировать файл…» читает файл в браузере и выдаёт готовый data URI вида data:image/png;base64,iVBORw0KGgo…. MIME-тип берётся из того, что браузер сообщает о файле; если определить его не удаётся, используется общий application/octet-stream. Результат можно вставить в <img src>, в CSS-правило background-image: url(...) или в @font-face.
Data URI имеют смысл для небольших ресурсов: SVG-иконки, заглушки на 1–2 КБ, логотипа в HTML-подписи письма. Для всего, что крупнее, они работают против вас. Текст на треть больше исходного файла, его нельзя закэшировать отдельно от содержащей его страницы, и он раздувает HTML или CSS, которые должны загрузиться до начала отрисовки. Разумный потолок — несколько килобайт на ресурс.
Файл целиком читается в память и конвертируется за один раз, поэтому очень большие файлы могут замедлить вкладку или исчерпать память. Файл никуда не загружается.
Если декодирование не удаётся
Декодер показывает «Некорректный Base64», когда во входных данных есть символы вне алфавита или длина невозможна. Частые причины:
- Префикс data URI. Перед декодированием удалите всё до запятой включительно в
data:image/png;base64,. - Переносы строк внутри строки. MIME-кодировщики переносят Base64 через каждые 76 символов. Если текст с переносами не декодируется, сначала соедините его в одну строку.
- Ошибки копирования. Достаточно потерянного последнего символа или лишней кавычки из JSON-строки, чтобы всё сломалось.
Декодер всегда превращает результат в текст. Если исходные данные были двоичным файлом, например изображением или ZIP-архивом, на выходе будут случайные символы и вопросительные знаки; это ожидаемо, ведь эти байты никогда не были текстом.