Кодирование полезно только в том случае, если обе стороны согласны с ним. Наименьшее представление не обязательно является лучшим выбором, когда получателю нужен знакомый алфавит, полезные данные должны быть набраны человеком или окружающий синтаксис обрабатывает определенные символы особым образом. Начните с протокола приема.
Hex многословен, но его легко проверить.
Шестнадцатеричный формат записывает каждый байт как две цифры. Последовательность байтов FF 00 41 становится ff0041. Каждая пара имеет видимую границу байта, что помогает при проверке подписей файлов, контрольных сумм и пакетов протоколов. Он удваивает количество символов, но его небольшой алфавит обычно легко помещается в журналы и инструменты отладки.
Base64 балансирует размер и совместимость
Base64 представляет три байта с четырьмя символами. Это обычное решение для двоичных полей внутри текстовых форматов. Стандартный Base64 включает плюс и косую черту; Base64URL заменяет эти символы, когда протоколу требуется другой алфавит. Правила заполнения и пробелов по-прежнему требуют согласования. Ни одна из форм не сообщает получателю, являются ли декодированные байты текстом, изображением или сжатым содержимым.
Процентное кодирование принадлежит компонентам URL.
Процентное кодирование записывает экранированный байт как %HH. Это не просто замена Base64. Компонент определяет, какие символы необходимо экранировать, а текст сначала должен быть закодирован как UTF-8. Косая черта может разделять сегменты пути, а вопросительный знак запускает запрос; рассмотрение всего URL как одного непрозрачного компонента меняет его смысл.
console.log(encodeURIComponent('a+b / 中文'));
// a%2Bb%20%2F%20%E4%B8%AD%E6%96%87Base85 нужен точный вариант
Многие схемы Base85 представляют четыре байта с пятью символами, но их алфавиты, разделители и особые случаи различаются. ASCII85 и Z85 не могут считаться взаимозаменяемыми. Z85 также предъявляет требования к размеру блока. Алфавит высокой плотности может содержать знаки препинания, которые необходимо снова экранировать в окружающем формате, что снижает очевидную выгоду.
Не путайте эти кодировки байтов с преобразованием целого числа 255 между системами счисления. Файл может начинаться с нулевых байтов, тогда как целочисленное представление может отбрасывать ведущие нули. Обратимый файловый кодек должен определять, как сохраняются длина и ведущие нули.
Используйте Hex для проверки байтов, указанный вариант Base64 для совместимого двоичного транспорта, компонентное кодирование URL для URL-адресов и специализированную схему только в том случае, если обе стороны реализуют один и тот же контракт. Сравните сквозной размер после экранирования и сжатия. RFC 4648 определяет стандартные семейства Base16, Base32 и Base64, включая их отдельные алфавиты.