Base64 кодер/декодер

Миттєво перетворюйте будь-який текст у кодування Base64. Наш інструмент працює з символами UTF-8, рядками JSON, HTML та будь-яким іншим текстовим входом.

Скопіюйте вихідні дані Base64 для використання в:

• API
• URI даних
• кодуванні електронної пошти
• файлах конфігурації

Декодуйте будь-який рядок Base64 назад у читабельний текст. Вставте вміст у форматі Base64 та миттєво побачте початковий текст.

Підтримує:

• стандартний Base64
• безпечний для URL Base64
• Base64 з символами заповнення або без них

Кодування Base64 перетворює двійкові дані на набір із 64 друкованих символів ASCII, як визначено в специфікації RFC 4648 від IETF.

Алгоритм бере вхідні байти та перегруповує їх з 8-бітних байтів у 6-бітні блоки, оскільки 2 у 6 степені дорівнює рівно 64 можливим значенням. Кожна 6-бітна група відповідає одному символу в алфавіті A-Z, a-z, 0-9, плюс і слеш.

Оскільки кожні 3 вхідні байти (24 біти) перетворюються на 4 вихідні символи, закодований текст приблизно на 33 відсотки більший за оригінал. Якщо довжина вхідних даних не кратна 3, додається один або два знаки рівності як заповнювачі згідно зі специфікацією RFC 4648.

Base64 — це кодування, а не шифрування, і воно забезпечує нульовий рівень безпеки чи конфіденційності. Будь-хто може миттєво розшифрувати рядок Base64, оскільки тут немає секретного ключа, а зворотне відображення є публічно документованим у RFC 4648.

OWASP чітко попереджає, що Base64 не є замінником криптографії та ніколи не повинен використовуватися для захисту паролів, токенів чи особистих даних. Його єдина мета — безпечне пересилання двійкових даних через виключно текстові канали, такі як електронна пошта, URL-адреси та JSON.

Для справжньої конфіденційності використовуйте стандартизоване шифрування, наприклад AES-256, як рекомендує NIST, а для цілісності використовуйте хешування, наприклад SHA-256. Ставтеся до будь-якого рядка Base64 у своїх логах як до повністю читабельного звичайного тексту.

Безпечний для URL Base64 — це варіант, визначений у розділі 5 RFC 4648, який замінює символ плюса на дефіс, а слеш — на підкреслення.

Ця заміна важлива, оскільки плюс і слеш мають зарезервовані значення в URL-адресах та шляхах файлів, де їх можуть хибно інтерпретувати або вони вимагатимуть відсоткування (percent-encoding). Безпечний для URL алфавіт дозволяє закодованим значенням передаватися в рядках запиту, сегментах шляху та іменах файлів без пошкодження.

У цьому контексті знаки рівності заповнення часто опускаються, оскільки декодер може сам визначити початкову довжину. Вебтоккени JSON, описані в RFC 7519, покладаються саме на це кодування base64url для своїх сегментів заголовка та корисного навантаження, тому рядки JWT ніколи не містять символів плюса чи слешу.

Base64 збільшує розмір даних приблизно на 33 відсотки, оскільки представляє кожні 3 байти вхідних даних за допомогою 4 символів на виході.

Три байти містять 24 біти, і Base64 розділяє ці 24 біти на чотири групи по 6 бітів, тому співвідношення 4 символів до 3 додає одну третину до довжини, як зазначено в RFC 4648. Заповнення (padding) додає ще до двох символів у фінальному блоці.

Ця надлишкова вага — усвідомлена плата за сумісність з ASCII: двійкові дані, які пошкодили б електронну пошту або JSON, стають повністю безпечними для тексту. Згідно з MDN Web Docs, саме тому вбудовування зображень як даних URI у форматі Base64 робить файли HTML і CSS помітно більшими, ніж пряме посилання на оригінальний двійковий файл.

Щоб закодувати файл або зображення в Base64, сирі байти зчитуються та пропускаються через стандартний алгоритм RFC 4648, створюючи текстовий рядок, який можна вбудувати безпосередньо в код.

Поширеним використанням є схема data URI, задокументована в MDN Web Docs, де зображення стає самодостатнім значенням src, наприклад data:image/png;base64, за яким слідують закодовані байти. Це усуває потребу в окремому запиті HTTP, що може прискорити завантаження крихітних іконок.

Проте, оскільки Base64 збільшує розмір на 33 відсотки і не може кешуватися окремо, його найкраще залишати для дуже маленьких активів. Більші зображення, шрифти та PDF зазвичай подаються як звичайні двійкові файли, а не вбудований Base64.

Base64 працює з Unicode, спочатку конвертуючи текст у байти UTF-8, а потім кодуючи ці байти за допомогою стандартного алфавіту Base64. Сам Base64 працює лише з сирими байти, тому етап кодування символів відбувається перед кодуванням і після декодування.

UTF-8, визначений у RFC 3629 і підтримуваний спільно зі Стандартом Unicode від Консорціуму Unicode, представляє емодзі, ієрогліфи CJK та букви з діакритичними знаками як багатобайтні послідовності, які Base64 потім точно зберігає. Цей двоетапний процес пояснює, чому наш інструмент коректно обробляє такі символи в обидва боки, як-от знак євро чи емодзі.

У JavaScript у MDN Web Docs зазначається, що застаріла функція btoa приймає лише Latin-1, тому сучасний код кодує дані в байти UTF-8 за допомогою TextEncoder перед викликом btoa.

Base64 використовується скрізь, де двійкові дані мають передаватися через системи, які працюють лише з текстом.

• Вкладення електронної пошти кодуються в Base64 за стандартом MIME, визначеним у RFC 2045, завдяки чому зображення та документи виживають під час транспортування звичайного текстового листу.
• Вебсторінки вбудовують невеликі зображення та шрифти як data URI у форматі Base64, як задокументовано в MDN Web Docs.
• Токени JSON Web Tokens згідно з RFC 7519 кодують свої claims як рядки base64url, а базова автентифікація HTTP, описана в RFC 7617, кодує в Base64 пару імені користувача та пароля через двокрапку.
• Base64 також з'являється у корисних навантаженнях API, сертифікатах TLS у форматі PEM та файлах конфігурації.

У кожному випадку мета полягає в безпечному транспортуванні без втрат, а не в стисненні чи захисті.

Найпоширеніша помилка з Base64 — сприймати його як захід безпеки, тоді як RFC 4648 визначає повністю зворотне, неключове перетворення, яке кожен може декодувати.

• Інша часта помилка — змішування стандартних алфавітів та алфавітів, безпечних для URL, що призводить до збоїв декодування, коли знаки плюс або слеш замінюються на дефіс і нижнє підкреслення.
• Відсутнє або неправильне заповнення знаком рівності також ламає суворі декодери, хоча багато хто, зокрема реалізації в MDN Web Docs, терпимо ставиться до відсутності заповнення.
• Розробники часто забувають про крок UTF-8 і отримують спотворений текст для вхідних даних, що не є ASCII.
• Нарешті, випадкове кодування вже закодованих у Base64 даних подвоює надлишковість.

Перевірка точного варіанту, правил заповнення та набору символів за специфікацією RFC 4648 запобігає майже всім таким збоям декодування.

Base64, Base32 та шістнадцяткове кодування — це все способи перетворення двійкових даних у текст, визначені разом у RFC 4648, але вони по-різному балансують між щільністю та зручністю читання.

• Шістнадцяткове кодування використовує 16 символів і подвоює розмір даних, що робить його найзручнішим для читання людиною та найпоширенішим у хешах і кодах кольорів.
• Base32 використовує 32 символи без урахування регістру, збільшує дані приблизно на 60 відсотків і уникає двозначних символів, що підходить для систем, які не чутливі до регістру, та секретів TOTP.
• Base64 є найкомпактнішим із трьох із приблизно 33 відсотками накладних витрат, використовуючи 64 символи.

Вибирайте шістнадцятковий формат для налагодження та коротких ідентифікаторів, Base32, коли проблема полягає в чутливості до регістру, і Base64, коли найбільше значення має компактність, як чітко зазначено в рекомендаціях IETF у RFC 4648.