Инструменты разработчика · Кодер и декодер Base64
Base64 против hex против base32: сравнение трех способов записи байтов в виде текста
· Фон
base64 кодирование
Hex, base32 и Base64 решают одну и ту же проблему, но с разными компромиссами в размере, читаемости и безопасности. В этом посте они сравниваются по плотности, чувствительности к регистру, URL безопасности и человеческим ошибкам.
Ключ API был набран с ошибкой из-за l, 1, I и O — конкретная ошибка читаемости, которой не было бы в шестнадцатеричном формате.
Три распространенных способа представления байтов в виде текста: шестнадцатеричный, base32 и base64. Все они решают одну и ту же проблему (выражение произвольных байтов в печатной форме ASCII), но с разными компромиссами в размере, читаемости и устойчивости к ошибкам. Hex — это 2 символов на байт (F3 A2 B1 ...), поэтому 16 bytes становится 32 символов. Base32 составляет 1.6 символов на байт (приблизительно 5 символов на 3 bytes), поэтому 16 bytes становится 26 символов.
Base64 составляет 1.33 символов на байт (ровно 4 символов на 3 bytes), поэтому 16 bytes становится 24 символов или меньше. Если размер файла имеет значение, то base64 является наиболее компактным. Если человеческая транскрипция имеет значение, то hex и base32 безопаснее. Разница в читаемости имеет решающее значение при вводе, копировании или произнесении значения. В шестнадцатеричном формате используются 0-9 и a-f (в большинстве контекстов без учета регистра). Канал транскрипции меняет решение, потому что представление, оптимизированное для машин, может быть неудобным для людей. Base64 чувствителен к регистру и использует два символа пунктуации; hex использует меньший визуальный словарь. Приведенная здесь реализация проверяет точные строки, а не частоту человеческих ошибок, поэтому не прилагается никакой выдуманной вероятности.
Плотность: 2×, 1.6× и 1.33× — сколько символов требуется для каждой кодировки на байт и почему
Base32 использует A-Z и 2-7, избегая 0, 1, O и I, которые легко спутать на бумаге. Base64 использует A-Z, a-z, 0-9, + и /,, включая как прописные, так и строчные буквы, что делает его чувствительным к регистру и смешивает цифры, которые выглядят одинаково (0 вместо O, 1 вместо I вместо нижнего регистра l). Шестнадцатеричный ключ API может иметь вид f3a2b1e4; одни и те же байты в base64 могут иметь вид 86KrvE== (с заполнением) или в base32 6VEV7FI= (с заполнением).
Если пользователю необходимо ввести значение вручную, шестнадцатеричное или base32 безопаснее, чем base64. Зарезервированные символы в URL-адресах имеют значение. Hex и base32 безопасны для URL-адресов; оба используют только буквенно-цифровые символы (в шестнадцатеричном формате также используются 0-9, в base32 также используются 2-7). Base64 использует плюс и косую черту, которые зарезервированы URL (плюс представляет пробел в данных, закодированных в форме, косая черта — это разделитель пути). Плотность Base64 напрямую зависит от шести полезных битов на выходной символ и заполнения четырехсимвольных блоков. Hex содержит четыре бита на символ, что составляет два символа на байт. Base32 обсуждается как контекст сравнения только потому, что этот репозиторий не предоставляет ни своего алфавита, ни кодировщика для проверки выходных данных.
Плотность по разрядности — точная Base64 и шестнадцатеричная арифметика, при этом Base32 рассматривается как контекст сравнения.
Строка base64 в параметре URL должна быть закодирована в процентах (плюс становится %2B, косая черта становится %2F), добавляя 4 дополнительных символов для каждого вхождения. Base64url (RFC 4648 раздел 5) заменяет плюс на тире, а косую черту на подчеркивание, что делает его URL безопасным без процентного кодирования. Большинство API, использующих base64 в URL-адресах, на самом деле используют base64url, но в документации это различие часто не указывается явно.
Секреты TOTP (коды, используемые приложениями-аутентификаторами) обычно распространяются в формате base32. На экране регистрации TOTP отображается секретный код Base32, поскольку его легче вводить и расшифровывать, чем те же байты в формате Base64 или шестнадцатеричном формате. Хэш-дайджесты SHA часто отображаются в шестнадцатеричном формате, поскольку это традиционный формат и поскольку шестнадцатеричный формат не учитывает регистр, что снижает вероятность опечаток. Чувствительность к регистру имеет значение, когда кто-то читает значение вслух или печатает его повторно, поскольку изменение регистра одной буквы приводит к изменению ее индекса. ToolAcre точно сохраняет регистр и будет декодировать полученные разные байты, не зная, что человек допустил ошибку транскрипции. Само представление не имеет контрольной суммы.
Зарезервированные символы и безопасность URL — где + и /bit и как base32 и hex позволяют избежать проблемы
JWT используют base64url. Контрольные суммы файлов могут быть шестнадцатеричными или base64; оба общие. Выбор обусловлен исторической условностью, а не технической необходимостью. Устойчивость к ошибкам — тонкое, но важное отличие. Base32 избегает цифр 0, 1, 8 и 9 (которые выглядят как буквы), уменьшая количество ошибок транскрипции. Base64 включает все цифры, что делает 1 неоднозначным (это буква I, строчная буква l или цифра 1?).
Шестнадцатеричный формат еще более подвержен ошибкам: 0 выглядит как O, l выглядит как 1. Контрольная сумма, которую необходимо ввести или прочитать с распечатки, безопаснее в base32. Ключ API, вставленный непосредственно с компьютера, безопасен в любом формате; читаемость имеет значение только тогда, когда задействованы человеческие глаза. Байты те же, но кодировка другая: последовательность 16 байтов [0xf3, 0xa2, 0xb1, ...] становится f3a2b1... Стандартные плюс и косая черта в Base64 требуют обработки с учетом канала; В безопасном режиме URL они заменяются дефисом и подчеркиванием. Hex позволяет избежать этих разделителей, используя только цифры и буквы. Соглашения Base32 различаются, поэтому в этой статье избегаются многообещающие свойства безопасности, которые репозиторий не реализует и не тестирует.
Рабочий пример: один и тот же 16 bytes во всех трёх кодировках — сравнение длин и визуальный осмотр.
в шестнадцатеричном формате 6VEV7FI=... в base32 и 86KrvE== в base64. Ни одна из этих строк не является взаимозаменяемой. Приложение, получающее f3a2b1... ожидает шестнадцатеричного значения и попытается проанализировать его как шестнадцатеричное. Получение 86KrvE== завершится неудачей, если приложение ожидает шестнадцатеричный код. Формат кодирования является частью контракта данных: отправитель и получатель должны договориться о том, какая кодировка будет использоваться. Заполнение — еще одно отличие.
В шестнадцатеричном формате не используются дополнения (4 bytes всегда представляют собой шестнадцатеричные символы 8, без исключений). Base32 и base64 используют заполнение равенствами для выравнивания вывода по множеству символов (8 для base32, 4 для base64). Заполнение необходимо математически; он гарантирует, что каждый входной n-байт создает детерминированное количество символов. Правила заполнения различаются: некоторые приложения требуют заполнения, другие позволяют его опустить. В рабочем сравнении используется фиксированная последовательность байтов и механические вычисления в формате Base64 и шестнадцатеричном формате. Его длину в Base32 можно определить с помощью пятибитной группировки, но точное текстовое значение Base32 опущено, поскольку ни одна рассмотренная реализация не создала его. Арифметика длины и проверка вывода сохраняются отдельно.
Каждый из них является традиционным — хеши в шестнадцатеричном формате, секреты TOTP в base32, JWT и данные: URI в Base64.
При вставке значения base32 или base64 без заполнения декодеры могут принять или отклонить его в зависимости от реализации. Криптографические ключи и токены показывают разницу в кодировке.
Ключ HMAC — это 32 bytes, который становится 64 шестнадцатеричными символами, 52 символами base32 (с заполнением) или 44 символами base64 (с заполнением). При распространении ключа кодировка должна быть документирована. Если в документации указано, что ключ состоит из 44 символов base64, а вы получаете 52 символов, что-то не так. Конвенция может служить ориентиром для читателей, но не доказывает ее пригодность. Хэш-дайджесты обычно отображаются в шестнадцатеричном виде, а сегменты JWT используют Base64url. Правильный выбор по-прежнему зависит от правил канала, от того, копируют ли люди значение и зафиксировал ли уже другой протокол представление.
Что здесь не распространяется — кодировки base58, base85 и контрольные суммы.
Более короткая кодировка base64 облегчает размещение токенов в системах с ограничениями на количество символов (например, QR-коды или URL-адреса). Выбор кодировки значения определяется экосистемой, из которой оно получено. Веб-API часто используют base64url. Криптографическая документация часто использует шестнадцатеричный формат. Приложения для аутентификации используют base32. При построении системы выберите одну кодировку, четко задокументируйте ее и придерживайтесь ее.
Смешение кодировок (например, base64 или base32) приводит к путанице. При отладке первым шагом является определение того, какую кодировку использует значение; Инструмент кодирования и декодера Base64 может помочь, попытавшись декодировать его несколькими способами и определив, какой из них дает разумный результат. Никакое кодирование не является универсально лучшим. Base64 наиболее компактен для хранения необработанных данных. Hex наиболее знаком криптографам и наиболее удобен для чтения человеком для небольших последовательностей. Кодировки Base58, Base85 и контрольные суммы имеют разные компромиссы и отсутствуют на панели Base64 ToolAcre. Их алфавиты, правила неоднозначности и контрольные суммы следует оценивать с помощью специальных источников и реализаций, а не экстраполировать на основе протестированного поведения этого инструмента.
Вывод: выберите кодировку для канала и читателя — как кодировщик и декодер Base64 покрывает случай Base64 в браузере, а также хеш-калькулятор SHA в том же продукте.
Base32 наиболее устойчив к ошибкам транскрипции. Выбор зависит от контекста: где находится ценность, как она распределяется и какие системы будут ее потреблять.
Понимание компромиссов поможет вам сделать мудрый выбор при проектировании API или системы. Инструмент кодирования и декодера Base64 демонстрирует кодировку Base64; использование его вместе с шестнадцатеричным инструментом или инструментом base32 позволяет вам видеть одни и те же байты во всех трех форматах и понимать их размер и различия в читаемости. Для случая Base64 закодируйте образец, запишите точное количество UTF-8 байтов и выходных символов и проверьте стандартную и URL-безопасную пунктуацию. Для работы с дайджестом используйте отдельную панель SHA. Сохранение различий между этими операциями предотвращает ошибочный выбор кодировки за хеширование или защиту целостности.