Кодувальник і декодувальник Base64

Кодуйте текст у Base64 або декодуйте Base64 назад у читабельний текст. Підтримує чотири режими формату: рядок, JSON, XML і YAML. JSON/XML/YAML автоматично форматуються під час декодування. Також: Конвертер зображень Base64 | Файл у Base64 | Hex ↔ Base64.
Уся обробка відбувається локально у вашому браузері — ваші дані ніколи не завантажуються на жоден сервер.
Формат: Напрямок:
Алфавіт: Перенесення рядка:
What is Base64? Base64 is a binary-to-text encoding scheme that represents data using 64 ASCII characters (A-Z, a-z, 0-9, +, /). It is commonly used to transmit binary data over text-based protocols like HTTP, JSON, or XML.
String mode: Direct encode/decode of any text.
JSON/XML/YAML modes: When decoding, the result is validated, parsed, and pretty-printed for readability. When encoding, the input is validated before being Base64-encoded.
URL-safe: Replaces + with - and / with _, and strips trailing = padding — safe to use in URLs and filenames without percent-encoding.
Що таке Base64?

Base64 переписує байти, використовуючи шістдесят чотири читабельні символи, щоб дані витримали канал, створений для тексту: тіло електронного листа, рядок JSON, атрибут XML, URL. Кожні три байти стають чотирма символами — звідси назва: алфавіт має шістдесят чотири символи, і кожен несе рівно шість біт.

Це транспортне кодування, а не захід безпеки і не крок стиснення. Вивід приблизно на третину більший за вхід, і будь-хто, хто має рядок, може його одразу повернути. Якщо ви хочете знати, чи змінено дані, для цього хеш (Генератор гешів); якщо хочете, щоб вони лишалися таємними, — шифрування. Base64 не робить ні того, ні іншого.

Одне число, яке варто запам'ятати: три вхідні байти стають чотирма вихідними символами. Усе інше на цій сторінці випливає з цього. Чотири символи несуть двадцять чотири біти, а двадцять чотири біти — рівно три байти, тож дані ніколи не втрачаються і не вигадуються — крім самого кінця, де вхід може не заповнити останню групу з трьох.
П'ять алфавітів, які може використовувати ця сторінка

Перші два рядки — стандарти, а останні три — конвенції, що виросли навколо Unix. Усі п'ять несуть ті самі шість біт на символ і відрізняються лише тим, які шістдесят чотири символи їх несуть, тож ті самі байти стають п'ятьма різними рядками. Усередині рядка ніщо не каже, який алфавіт його створив, тому вибір алфавіту за замовчуванням — стандартний, а прапорець безпечного для URL — це скорочення для другого рядка.

Як сторінка обирає кандидата: перемикач є типовим для обох напрямків. Під час декодування панель праворуч також читає сам рядок — - і _ можуть походити лише з безпечного для URL алфавіту, + або / — лише зі стандартного, а / чи . на початку вказують на два алфавіти Unix. Там перелічено кожен алфавіт, який може прочитати поточний вхід, із причиною, чому кожен є кандидатом або ні.
Розбиття рядків: 76 і 64 символи

MIME вимагав Base64, який вміщується в електронний лист без надмірного подовження рядків, і зупинився на 76 символах у рядку, розділених CRLF. Файли PEM, що обгортають сертифікати й ключі, використовують 64. Розриви рядків не є частиною даних: декодувальник їх прибирає і з'єднує рядки назад, перш ніж щось робити, тож розбитий і нерозбитий рядок декодуються в рівно ті самі байти. Кожен рядок, крім останнього, містить ціле число груп по чотири символи, що й робить безпечним їх з'єднання назад.

Ця сторінка лишає вивід в одному рядку, якщо ви не оберете ширину, а декодувальник приймає вхід із розривами рядків і без них. Розриви, які пише ця сторінка, — звичайні переноси рядків, які може вмістити текстове поле; тіла листів MIME традиційно використовують повернення каретки перед кожним переносом, і кожен декодувальник, що використовується, приймає обидва варіанти.

Доповнення і чому його можна прибрати

Коли вхід не кратний трьом байтам, остання група з чотирьох символів неповна, і один або два символи = доповнюють її. Вони взагалі не несуть даних: лише показують, скільки з чотирьох символів справжні. Декодувальник може обчислити це з довжини, тому Base64 для URL традиційно залишає доповнення вимкненим — = незручний в URL чи назві файлу, а деякі системи кодують його відсотками.

Прапорець у рядку параметрів зберігає доповнення, коли обрано безпечний для URL алфавіт. Нічого іншого не змінюється; символи, що несуть дані, в обох випадках однакові.

Поширені хибні уявлення
  • "Base64 приховує дані." Ні. Це заміна без ключа, і вся суть у тому, що будь-який читач може її скасувати. Загортання пароля чи токена в Base64 нічого не змінює щодо того, хто може його прочитати.
  • "Base64 стискає." Навпаки: кожні три вхідні байти стають чотирма вихідними символами, тож текст на третину більший за дані, які він несе.
  • "Розриви рядків — частина значення." Вони є оформленням. Додавання чи видалення їх ніколи не змінює байти, які повертаються.
  • "Безпечний для URL означає інше кодування." Це те саме кодування з двома поміненими символами: + стає -, а / стає _, тож рядок може стояти в шляху URL або значенні запиту без екранування.
  • "Рядок, що декодується, мусить бути дійсним Base64." Будь-який рядок із символів алфавіту є дійсним Base64, бо кожна комбінація шестибітних значень — дійсна послідовність байтів. Рядок виявляється невірним лише на наступному кроці, коли ці байти перевіряються за форматом, якому вони мали відповідати.
  • "Доповнення каже, який алфавіт використано." Ні, і в більшості випадків символи теж ні: стандартний і безпечний для URL алфавіти збігаються в шістдесяти двох з шістдесяти чотирьох символів, тож короткий рядок часто читається однаково в обох.
Поширені запитання

Чому рядок Base64 іноді закінчується одним =, а іноді двома? Один означає, що в останній групі три справжні символи, тобто два вхідні байти; два означають, що там два символи, тобто один вхідний байт. Без = означає, що довжина вхідних даних кратна трьом.

Чи може Base64 представляти довільні бінарні файли? Так, і це його головне призначення. Ця сторінка розглядає вхід як текст UTF-8; спеціальний інструмент Файл у Base64 читає сирі байти, коли потрібно закодувати щось, що не є текстом.

Який алфавіт використовувати в API? Той, який задокументовано на боці отримувача. Якщо там сказано безпечний для URL — беріть його; якщо там не сказано нічого, а значення передається всередині URL, безпечний для URL із прибраним доповненням — безпечний вибір.

Чи чутливий вивід до регістру? Повністю. a і A — різні значення, тому Base64 набагато гірше переживає помилково набрану літеру, ніж Base32 чи Crockford Base32.