Кодирование и декодирование Base64
Кодируйте текст или файлы в Base64 и декодируйте строки обратно в байты в браузере. Примеры padding, алфавит RFC 4648 и URL-safe вариант.
Все расчёты выполняются в браузере. Ничего из введённого не отправляется на сервер.
Результаты обновляются при вводе. Ctrl/Cmd+Enter копирует основной результат.
Результат
—
Просмотр битов
Показать решение
Кодирование и декодирование Base64 переводит произвольные байты в ASCII-строку по алфавиту RFC 4648 и обращает эту строку обратно в исходные байты. Текстовый режим принимает кодировку символов вроде UTF-8; файловый режим читает загрузку через FileReader браузера и может выдать URI data: для встраивания. Кодирование это не шифрование. Любой, кто получил строку, может её декодировать.
Всё кодирование и декодирование выполняется в браузере. Ничего из вставленного не отправляется на сервер.
Кодирование текста или файла в Base64
Кодирование берёт сырые байты и записывает строку из A-Z, a-z, 0-9, плюс, слэш и padding =. Вставьте текст или выберите файл, укажите кодировку символов для текстового источника и прочитайте вывод.
Файловый режим подходит для небольших изображений и документов, которые должны путешествовать внутри JSON, XML или email без двоичного канала.
Вывод безопасен для транспорта через системы, портящие произвольные двоичные данные, вроде старых почтовых шлюзов или копирования в XML. Он длиннее входа по замыслу. Пустой или недопустимый ввод не даёт строки; инструмент ждёт байты перед выводом символов.
Декодирование Base64-строки обратно в данные
Декодирование обращает поиск по алфавиту, восстанавливает исходный битовый поток и возвращает текст или скачиваемый файл. Символы padding = в конце значимы: они отмечают, сколько байтов было в финальной неполной группе. Символы вне алфавита вызывают явную ошибку, а не тихое частичное декодирование.
Пробелы часто игнорируются, чтобы строки, скопированные из PEM-сертификатов или MIME-тел, всё равно работали. Строка, похожая на Base64, но с URL-safe алфавитом, требует URL-safe режима декодирования, иначе дефис и подчёркивание будут отклонены как недопустимые в стандартном алфавите.
Как работает кодирование Base64
Base64 обрабатывает вход блоками по три байта (24 бита). Эти 24 бита делятся на четыре группы по 6 бит. Каждое 6-битное значение это индекс от 0 до 63 в 64-символьном алфавите. Три входных байта поэтому становятся четырьмя выходными символами.
Байты: [ byte1 ][ byte2 ][ byte3 ]
Биты: aaaaaaaa bbbbbbbb cccccccc
Группы: aaaaaa aabbbb bbbbcc cccccc
Симв.: Char1 Char2 Char3 Char4Когда остаётся меньше трёх байтов, кодировщик всё равно выдаёт четыре символа, но добавляет padding, чтобы декодер знал исходную длину. Перегруппировка битов это весь алгоритм; контрольной суммы и ключа нет.
Пошаговое кодирование слова Dog
Слово Dog это три ASCII-байта, поэтому оно заполняет одну Base64-группу и кодируется без символов padding. Тестовый вывод RG9n. Проход байтов к битам, перегруппировка в 6-битные индексы и чтение алфавита RFC 4648 показывают, почему появляются эти четыре символа и как любой трёхбайтовый блок следует тому же пути.
1. Запишите байты. D = 0x44 = 01000100 o = 0x6F = 01101111 g = 0x67 = 01100111
2. Сцепите 24 бита. 01000100 01101111 01100111
3. Разделите на 6-битные группы. 010001 000110 111101 100111
4. Переведите каждую группу в десятичный индекс. 17, 6, 61, 39
5. Найдите в алфавите. Индекс 17 = R, 6 = G, 61 = 9, 39 = n
Результат: RG9n. Декодирование RG9n возвращает три исходных байта и текст Dog в UTF-8 или ASCII.
Padding со знаком равенства
Padding появляется, когда число байтов не кратно трём. Один оставшийся байт даёт два символа алфавита и два знака =. Два оставшихся байта дают три символа и один =. Примеры Do → RG8= и Dogs → RG9ncw== показывают оба случая остатка рядом с словом Dog без padding.
| Ввод | Байтов | Закодировано | Padding |
|---|---|---|---|
| Dog | 3 | RG9n | нет |
| Do | 2 | RG8= | один = |
| Dogs | 4 | RG9ncw== | два = |
Do это два байта: 01000100 01101111. После 6-битной группировки хватает бит только на три значимых символа (RG8), и один padding = заполняет четвёртый слот. Dogs это четыре байта: полная трёхбайтовая группа кодируется как RG9n, затем однобайтовый остаток как cw==. Удаление padding вручную без корректировки длины битов ломает декодирование; оставляйте символы = на месте при вставке.
Алфавит Base64
RFC 4648 определяет 64 символа плюс знак padding =. Индексы 0-25 это A-Z, 26-51 a-z, 52-61 0-9, индекс 62 это +, индекс 63 /.
Индекс 0 это A, а не 0, что сбивает тех, кто ожидает, что цифры начнут алфавит.
| Диапазон индексов | Символы |
|---|---|
| 0-25 | A-Z |
| 26-51 | a-z |
| 52-61 | 0-9 |
| 62 | + |
| 63 | / |
| padding | = |
Панель алфавита калькулятора перечисляет ту же таблицу, что использует кодировщик, чтобы подозрительный символ можно было сверить со стандартным набором. Полная строка: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/.
URL-safe вариант Base64
URL-safe алфавит (base64url) заменяет + на - и / на _. Padding может опускаться в некоторых протоколах. JSON Web Tokens используют этот вариант, чтобы сегменты токена могли сидеть в URL и HTTP-заголовках без percent-encoding плюса и слэша.
Стандартные и URL-safe строки не взаимозаменяемы. Декодирование JWT payload стандартным алфавитом падает на дефисах. Инструмент предлагает явный URL-safe режим для кодирования и декодирования. Percent-encoding URL это другая задача; используйте страницу Кодирование и декодирование URL, когда цель это экранирование RFC 3986, а не Base64.
Увеличение размера
Каждые три байта становятся четырьмя символами, поэтому длина закодированного примерно 4/3 от входа, рост на 33 процента до переносов строк. Padding может добавить один или два лишних символа в финальной группе. Data URI и вложения email быстро чувствуют эту цену: изображение 300 KB становится примерно 400 KB текста.
encoded_length ≈ 4 × ceil(byte_length / 3)Перенос строк каждые 76 символов, типичный в MIME, добавляет байты перевода строк сверху. Предпочитайте двоичные вложения или сжатые форматы, когда важен размер; используйте Base64, когда канал действительно не может нести сырые байты.
Выбор кодировки символов
Base64 кодирует байты, а не абстрактные символы. Одни и те же буквы дают разные байты в UTF-8, UTF-16, Shift JIS или Big5. Декодирование с неверной charset даёт кракозябры, даже когда слой Base64 был идеален, поэтому charset текстового режима должен совпадать с производителем при кодировании и с потребителем при декодировании.
| Кодировка | Типичное применение |
|---|---|
| UTF-8 | По умолчанию для современного текста и API |
| Windows-1252 | Унаследованный западноевропейский текст |
| UTF-16 LE / BE | Некоторые Windows и Java данные |
| Shift JIS | Старый японский текст |
| Big5 | Старый традиционный китайский текст |
Для слова Dog ASCII и UTF-8 дают те же три байта, поэтому RG9n идентичен. Не-ASCII текст расходится. Выберите charset, совпадающий с производителем перед кодированием, и тот же charset после декодирования, иначе цикл будет выглядеть как баг Base64, когда ошибка выше по цепочке.
Часто задаваемые вопросы
Base64 это шифрование?
Нет. Base64 это кодирование, которое любой может обратить с публичным алфавитом. Оно ничего не скрывает. Используйте настоящий криптографический алгоритм, когда нужна конфиденциальность; Base64, когда каналу нужны ASCII-безопасные байты.
Почему вывод Base64 заканчивается знаками равенства?
Символы = это padding. Они отмечают, что финальная группа входа имела один или два байта вместо трёх. Do кодируется в RG8=, а Dogs в RG9ncw==. Сохраняйте padding при декодировании, если протокол не документирует его удаление.
Во что кодируется Dog?
Dog кодируется в RG9n без padding, потому что три байта точно заполняют одну Base64-группу. Пошаговая перегруппировка битов показана в разобранном примере на этой странице.
В чём разница между стандартным и URL-safe Base64?
URL-safe Base64 использует - и _ вместо + и /. JWT и некоторые встраивания имён файлов используют URL-safe алфавит. Декодирование неверным алфавитом падает на этих заменённых символах.
Насколько Base64 больше исходника?
Примерно на треть. Три байта становятся четырьмя символами, соотношение 4/3 до padding и переносов строк. Payload 3 000 байт становится 4 000 символами Base64.
Может ли Base64 кодировать файл, а не только текст?
Да. Файловый режим читает загрузку в браузере и кодирует сырые байты. Обратный путь декодирует в скачиваемый blob. Большие файлы увеличивают использование памяти во вкладке; держите загрузки скромными.
Почему декодированный текст выглядит неверно после правильного декодирования?
Слой Base64 восстановил байты, но кодировка символов для интерпретации этих байтов не совпадает с производителем. Попробуйте UTF-8 первым, затем charset, который реально использует исходная система.
Загружает ли этот инструмент вставленные секреты?
Нет. Кодирование и декодирование выполняются локально. API-ключи, токены и фрагменты сертификатов, вставленные в поле, не отправляются на сервер. Это обещание совпадает с правилом дизайна для всех страниц кодирования на Quick Calculators.
Base64 это то же самое, что URL-кодирование?
Нет. Base64 отображает двоичные данные на 64-символьный алфавит для транспорта. URL-кодирование (percent-encoding) экранирует зарезервированные символы внутри URI по RFC 3986. Они решают разные задачи и не заменяют друг друга.
Какой RFC определяет алфавит?
RFC 4648 определяет стандартный и URL-safe алфавиты Base64 и правила padding, используемые здесь. Старые документы вроде RFC 2045 описывают Base64 в контексте MIME с похожей механикой.
Итог
Кодирование и декодирование Base64 отображает байты на алфавит RFC 4648 в 6-битных группах и обращает процесс локально в браузере. Dog становится RG9n, Do становится RG8=, а Dogs становится RG9ncw==, иллюстрируя padding для остатков в один и два байта.
URL-safe алфавит меняет +// на -/_, вывод растёт примерно на треть, а выбор charset определяет, какие байты текстовый режим подаёт кодировщику. Ничего из вставленного не загружается.