Эти три имени описывают связанные схемы преобразования двоичного текста в текст, но они служат различным ограничениям. Base64 и Base64URL используют шестибитные группы. Стандарт Base32 использует пятибитовые группы и меньший алфавит. Правильный выбор — это тот, который ваше приложение для транспортировки, хранения и приема сможет точно сохранить.
Сравнивайте алфавиты перед длиной
Стандарт Base64 использует прописные и строчные буквы, цифры, плюс и косую черту. Base64URL заменяет последние два символа тире и подчеркиванием. Оба чувствительны к регистру. В стандартном RFC Base32 используются заглавные буквы A–Z и цифры 2–7. Декодер может принимать строчные буквы для удобства, но протокол должен указывать, разрешено ли это, и определять канонический вывод.
Канал без учета регистра может уничтожить значение Base64, сохранив при этом правильно указанное значение Base32. Токен URL имеет ограничения, отличные от ограничений кода, прочитанного вслух по телефону. Не делайте выбор исключительно по тому, насколько коротким выглядит образец.
Поймите компромисс размера
Игнорируя последнюю частичную группу, Base64 требуется около 1,33 символа на байт, а Base32 — 1,6. Стандартный дополненный Base32 генерирует группы из восьми символов по пять байтов. Для одного байта, содержащего букву f, общие векторы: Zg== в Base64 и MY====== в Base32. Маленькие входные данные увеличивают накладные расходы на заполнение, поэтому сравнивайте реалистичную длину полезной нагрузки.
Payload bytes: 66 (ASCII f)
Base64: Zg==
Base64URL: Zg== (or Zg when the protocol omits padding)
RFC Base32: MY======Не смешивайте варианты Base32
Crockford Base32 разработан на основе удобочитаемых идентификаторов и использует алфавит и правила неоднозначности, отличные от RFC Base32. Base32hex также отличается. Значение, полученное одним вариантом, не может быть передано вслепую другому декодеру. Назовите вариант, алфавит, политику заполнения и любое поведение контрольной суммы в своей документации.
Кодирование также не обеспечивает аутентификацию. Значение с ошибкой может оставаться синтаксически допустимым и декодироваться в разные байты. Если пользователи расшифровывают код, рассмотрите возможность использования контрольной суммы или этапа проверки, определяемого протоколом, а не предполагайте, что алфавит улавливает каждую ошибку.
Запишите полный договор
Укажите порядок входных байтов, где это необходимо, поведение при пустом вводе, сохранение начального нуля, максимальную длину, прием пробелов и обработку недопустимых символов. Включите тестовые векторы с байтами с высоким значением и частичными группами. Используйте выбранный вами кодер и декодер независимо от этих векторов, а не только друг против друга; в противном случае может показаться, что соответствующие ошибки проходят круговой путь. Стандартные формы и опорные векторы находятся в RFC 4648.