Четыре способа записать байты как текст
Base16 (hex), Base32, Base64 и процентное кодирование решают одну задачу: представить данные с помощью символов, которые чисто текстовый канал перенесёт безопасно. Они различаются по двум осям, которые уравновешивают друг друга, размеру алфавита и накладным расходам на размер. Больший алфавит упаковывает больше бит на символ, поэтому вывод короче; меньший или более ограниченный алфавит легче читать или безопаснее в данном контексте, но вывод длиннее. Первые три определены вместе в RFC 4648; процентное кодирование происходит из RFC 3986 и работает иначе, чем остальные.
Накладные расходы на размер с первого взгляда
Для сырого двоичного ввода расширение трёх кодирований из RFC 4648 фиксированное и предсказуемое:
кодирование бит/симв соотношение накладные
Base16 4 2 симв / байт +100%
Base32 5 8 симв / 5 байт +60%
Base64 6 4 симв / 3 байта +33%
Base64 самое компактное, Base16 наименее. Процентное кодирование — это исключение: это вовсе не фиксированное соотношение. Оно оставляет незарезервированные символы в покое и расширяет лишь остальное до трёх символов каждый, поэтому его накладные расходы целиком зависят от содержимого. Для текста, состоящего в основном из букв и цифр, оно почти бесплатно; для сырых двоичных данных, где почти каждый байт нужно экранировать, оно подскакивает примерно до +200%, хуже всех остальных.
Алфавит и читаемость
- Base16 / hex использует
0-9иA-F. Байт — это всегда два символа, поэтому границы байт совершенно чёткие. Его легче всего читать и сравнивать глазом, поэтому хеши, ключи и шестнадцатеричные дампы используют его. - Base32 использует
A-Zи2-7, нечувствительный к регистру, с удалёнными путаемыми символами0,1и8. Он создан для значений, которые человек будет набирать, диктовать или хранить без учёта регистра, как секреты и onion-адреса. - Base64 использует
A-Z,a-z,0-9,+и/, чувствительный к регистру. Это самое плотное из трёх, но+и/небезопасны в URL и именах файлов, что исправляет URL-безопасный вариант. - Процентное кодирование сохраняет читаемый текст читаемым и экранирует лишь то, что URL не может перенести буквально. Это схема экранирования, а не полное перекодирование.
Какое выбрать
Выбор следует за каналом и аудиторией. Если человеку нужно прочитать, набрать или сравнить значение, предпочтите hex (чтобы инспектировать байты) или Base32 (чтобы набирать или диктовать). Если машине нужно перемещать произвольные байты через текстовый канал и размер имеет значение, используйте Base64 или Base64URL, когда значение путешествует внутри URL, имени файла или токена. Если вы помещаете текст в URL и небезопасны лишь несколько символов, закодируйте его процентами вместо перекодирования всего.
Быстрое правило: Base64 для компактности, Base32 для набора, hex для чтения, процентное кодирование для URL.
Попробуйте их
Инструмент codec выполняет все четыре. Вставьте любой текст, переключите кодирование и сравните вывод бок о бок, с декодированием для каждого, целиком в вашем браузере.