Сравнение методов кодирования: Base64, URL, HTML, Hex

Введение

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

Для практической работы у нас есть инструменты для всех четырёх методов: Base64 кодировщик, URL кодировщик, HTML кодировщик и текст в hex.

Зачем вообще нужно кодирование

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

Кодирование решает эту проблему: берёт «опасные» байты и представляет их в безопасном виде. После передачи получатель раскодирует данные обратно. Главное — чтобы обе стороны знали, какой метод кодирования использован, иначе получатся «кракозябры».

Краткий обзор четырёх методов

Base64

Превращает произвольные бинарные данные в строку из 64 печатных ASCII-символов. Используется в email, Data URI, JWT, JSON API. Главный плюс — универсальность: можно передавать вообще любые байты. Главный минус — увеличение размера на 33%. Подробнее — в нашей статье о Base64.

URL encoding (percent-encoding)

Превращает символы, недопустимые в URL, в последовательность %XX. Нужен, чтобы вставлять в URL кириллицу, пробелы, спецсимволы. Не предназначен для бинарных данных произвольного размера — для этого лучше подходит Base64. Подробнее — в статье о URL кодировании.

HTML entities

Экранирует символы, имеющие особое значение в HTML: <, >,&, ", '. Главная цель — защита от XSS и корректное отображение спецсимволов. Подробнее — в статье об HTML сущностях.

Hex (шестнадцатеричное)

Записывает каждый байт двумя hex-цифрами (0–9, A–F). Увеличивает размер ровно в два раза, но очень удобен для чтения отдельных байтов. Применяется для цветов, MAC-адресов, хешей, hex dump. Подробнее — в статье о hex кодировании.

Сравнительная таблица

Сравним на одном примере

Возьмём строку "Hello & привет" и закодируем её четырьмя способами.

Base64

"Hello & привет" (UTF-8: 18 байт)
→ "SGVsbG8gJiDQv9GA0LjQstC10YLRjA=="
Размер: 32 байта (с padding)

URL encoding

"Hello & привет"
→ "Hello%20%26%20%D0%BF%D1%80%D0%B8%D0%B2%D0%B5%D1%82"
Размер: 60 байт (пробелы и & закодированы как %20 и %26,
                кириллица — по 2 байта в %XX формате)

HTML entities

"Hello & привет"
→ "Hello & привет"
Размер: 22 байта (только & заменён на &,
                  кириллица в UTF-8 выводится напрямую)

Hex

"Hello & привет" (UTF-8)
→ "48656c6c6f20262020d0bfd180d0b8d0b2d0b5d182"
Размер: 70 байт (каждый байт — 2 hex-символа)

Когда что использовать

Нужно передать бинарный файл через JSON API

Решение: Base64. JSON не поддерживает бинарные данные напрямую, а Base64 превращает их в безопасную строку. Цена — 33% рост объёма.

POST /api/upload
{
  "filename": "photo.jpg",
  "data": "/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgK..."
}

Нужно вставить кириллицу в URL

Решение: URL encoding. Каждый символ кириллицы превращается в последовательность %XX%XX.

https://example.com/search?q=%D0%BF%D1%80%D0%B8%D0%B2%D0%B5%D1%82

Нужно вывести пользовательский текст в HTML

Решение: HTML entities. Особенно важно для защиты от XSS — экранируйте&, <, >, ", '.

<div>{userComment}</div>
<!-- userComment = "<script>alert(1)</script>" -->
<!-- Экранированный вывод: -->
<div>&lt;script&gt;alert(1)&lt;/script&gt;</div>

Нужно записать хеш или цвет

Решение: Hex. SHA-256, MD5, цвета в CSS, MAC-адреса — всё это традиционно записывается в hex.

color: #FF5733;
background: #1A2B3C;
SHA-256("hello"): 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
MAC-адрес: 00:1A:2B:3C:4D:5E

Размер и эффективность

Размер закодированного вывода — важный фактор, особенно для больших объёмов данных. Сравним, во что превратится 1000 байт исходных бинарных данных:

Для больших бинарных данных Base64 — самый экономный выбор. Hex в два раза больше, но удобнее для чтения отдельных байтов. URL и HTML encoding зависят от содержания и для произвольных бинарных данных не подходят.

Контекст применения: чек-лист

Выбирайте Base64, если…

• передаёте бинарные данные через текстовый канал;
• встраиваете изображение в HTML/CSS как Data URI;
• формируете JWT-токен;
• вкладываете файл в JSON API запрос;
• храните бинарные данные в cookie (с оговоркой про размер).

Выбирайте URL encoding, если…

• собираете URL с параметрами из пользовательского ввода;
• передаёте кириллицу или пробелы в адресе;
• формируете ссылку с ID, содержащим спецсимволы;
• кодируете данные для application/x-www-form-urlencoded.

Выбирайте HTML entities, если…

• выводите пользовательский текст в HTML;
• защищаете приложение от XSS;
• нужно показать на странице тег как текст (например, в обучающей статье);
• нужны типографские символы: —,  , «.

Выбирайте hex, если…

• записываете цвет в CSS;
• выводите хеш для отладки;
• показываете MAC- или IPv6-адрес;
• делаете hex dump для анализа бинарных данных;
• записываете UUID.

Частые ошибки

1. Использование не того метода

Распространённая ошибка — применить URL encoding к данным, которые пойдут в HTML, или наоборот. Каждый метод рассчитан на свой контекст. Если закодировать пользовательский ввод для HTML как URL encoding, защита от XSS не сработает, потому что URL encoding не экранирует угловые скобки.

2. Двойное кодирование

Если взять уже закодированную строку и пропустить через функцию ещё раз, получится мусор. Например, %20 превратится в %2520, а& — в &. Особенно часто встречается при наложении нескольких слоёв шаблонизаторов.

3. Путаница Base64 и Base64url

Обычный Base64 содержит «+» и «/», которые недопустимы в URL без экранирования. Если вставляете Base64-строку в URL, либо используйте Base64url (с «-» и «_»), либо дополнительно применяйте URL encoding.

4. Игнорирование кодировки символов

Прежде чем кодировать текст, нужно знать, в какой он кодировке. Строка «Привет» в UTF-8, Windows-1251 и KOI8-R — три разные последовательности байтов. Современные стандарты требуют UTF-8, но в legacy-системах встречаются и другие.

5. Использование кодирования как шифрования

Все четыре метода — обратимые и не используют ключ. Любой может раскодировать данные. Если нужно скрыть содержимое — используйте настоящую криптографию: AES для симметричного шифрования, RSA или ECC для асимметричного. Подробнее о хеш-функциях — в статье о SHA-256.

Связанные методы: Data URI и JWT

Data URI — это схема, которая позволяет встраивать ресурсы прямо в HTML или CSS. Она комбинирует MIME-тип и Base64-кодированное содержимое. Например, небольшое PNG-изображение можно вставить прямо в тег <img>. Подробнее — в статье о Data URI scheme.

JWT (JSON Web Token) — стандарт для аутентификации, в котором используются сразу три метода кодирования: JSON для структуры, Base64url для представления и HMAC или RSA для подписи. Подробнее — в статье о JWT токене.

Пример: полный путь данных

Представим, что пользователь отправляет на сервер комментарий, содержащий ссылку и эмодзи. Сервер сохраняет комментарий, генерирует HTML-страницу со списком комментариев и отдаёт её браузеру. Какие методы кодирования используются на этом пути?

Шаг 1. Отправка с клиента на сервер

Текст комментария вставляется в JSON-тело запроса. JSON автоматически экранирует кавычки и управляющие символы через \\-последовательности. Если в комментарии есть эмодзи, оно сохраняется как UTF-8 байты.

Шаг 2. Сохранение в базе

База данных хранит текст в UTF-8. Никакого дополнительного кодирования не требуется — UTF-8 поддерживает все символы Unicode.

Шаг 3. Генерация HTML

Серверный шаблонизатор экранирует пользовательский текст через HTML entities, чтобы предотвратить XSS. Если в тексте была ссылка, она выводится как обычный текст (или как ссылка, если прошла проверку).

Шаг 4. Отдача браузеру

HTML отправляется с заголовком Content-Type: text/html; charset=utf-8. Браузер декодирует UTF-8 и рендерит страницу.

Шаг 5. Если в комментарии была кириллица в URL

Если пользователь вставил URL с кириллицей, браузер автоматически применит URL encoding при отправке запроса. Сервер должен раскодировать его обратно, чтобы получить оригинальный URL.

Современные тренды

В последние годы разработчики всё чаще отказываются от кодирования там, где раньше оно было обязательным. Например:

• Multipart/form-data вместо Base64 для загрузки файлов. Это эффективнее — нет 33% роста объёма.
• Server-Sent Events и WebSocket вместо long polling. Бинарные протоколы компактнее, чем Base64-обёрнутый JSON.
• HTTP/2 и HTTP/3 с бинарным фреймингом. Современные протоколы не требуют, чтобы данные были текстовыми.
• SVG inline вместо Base64-encoded PNG. Векторная графика компактнее и масштабируется без потерь.

Тем не менее, Base64, URL encoding, HTML entities и hex остаются фундаментальными инструментами, без которых веб-разработка невозможна.

Заключение

Base64, URL encoding, HTML entities и hex — четыре разных метода кодирования, каждый со своим назначением. Base64 универсален для бинарных данных, URL encoding — для адресов с спецсимволами, HTML entities — для безопасного вывода текста в разметке, hex — для компактной записи байтов в человекочитаемом виде. Главное — выбрать правильный метод для каждой задачи и не путать их между собой.

Все необходимые инструменты собраны на ConvertHub: Base64, URL, HTML и Hex кодировщики. А если хотите глубже погрузиться в каждый метод — читайте наши отдельные статьи: Base64, URL, HTML, Hex.