Кратко

  • RFC 3548 занялся малозаметной причиной несовместимости: спецификации писали «base64», не определяя алфавит, переносы строк, заполнение и реакцию на символы вне алфавита.
  • Главный вывод: правила MIME для передачи почтовых сообщений — это отдельный профиль, а не универсальный контракт для любого декодера.

Строку Base64 можно открыть в текстовом редакторе. Отсюда возникает ложное ощущение простоты: на вход подаются байты, на выходе появляются печатные знаки, и любой декодер должен обратить преобразование. История RFC 3548 показывает, что всё было не так однозначно. Реализации накапливали мелкие различия, тогда как протоколы ссылались на «base64», будто самого названия достаточно.

Различия касались не арифметики шестибитных групп, а окружающих её правил. Добавляет ли кодировщик переводы строк? Обязателен ли конечный символ заполнения =? Отклоняет ли декодер неожиданный знак или просто пропускает его? Какие символы занимают 64 позиции алфавита? Ответ, заимствованный у соседнего формата, может работать в его контексте и не совпасть с ожиданиями другой стороны.

RFC 3548 вышел в июле 2003 года как информационный документ. Его вступление отмечает распространённый упрощённый подход: спецификации протоколов упоминали «base64» без точного описания или ссылки и нередко брали за ориентир MIME, не учитывая последствия переноса строк и обработки символов вне алфавита. Документ собрал распространённые схемы Base16, Base32 и Base64 и сделал эти параметры явными.

MIME стал источником путаницы именно потому, что задаёт конкретный контекст. RFC 2045 определяет Base64 как Content-Transfer-Encoding для тела сообщения. Ограничение в 76 символов на строку относится к почтовой среде; PEM использовал 64 символа в близком историческом контексте. Общее правило RFC 3548 для ссылающейся спецификации — не добавлять переводы строк, если она прямо этого не требует. Перенос перестаёт быть оформлением, когда другая сторона считает его данными или отклоняет.

Заполнение и терпимость — тоже решения профиля. RFC 3548 требует добавлять корректные символы заполнения, если ссылающаяся спецификация не предписывает иное. Символы вне алфавита следует отклонять, кроме явно установленного исключения. MIME вправе игнорировать такие символы, включая CRLF, но это его собственное исключение. Перенос такой терпимости в другой протокол меняет множество допустимых входов. RFC упоминает скрытый канал и ошибки реализации как основания для осторожности, а не сообщает о конкретной атаке на названный продукт.

Алфавитам также нужны точные имена. Обычный Base64 использует + и / для значений 62 и 63. RFC 3548 описывает URL- и файлово-безопасный вариант с и _. Документ подчёркивает, что это не тот же формат и называть его просто «base64» нельзя. Поля пути, имени файла и идентификатора живут под иными ограничениями, чем почтовое тело.

В октябре 2006 года RFC 4648 заменил RFC 3548 и получил статус Standards Track. Он сохранил подход с явным профилем и добавил правила канонического кодирования: биты заполнения в Base64 и Base32 должны быть нулевыми, иначе разные строки могут декодироваться в одни и те же байты. Это отдельный вопрос от почтовых переносов MIME. Вместе документы показывают, почему «декодирование прошло» ещё не завершает спецификацию протокола: стороны должны согласовать форму, заполнение, допустимую терпимость и уровень интерпретации значения.

Базовое кодирование не шифрует данные и не удостоверяет их подлинность. Оно лишь представляет октеты текстом для некоторых транспортов. Исторический вклад RFC 3548 скромен, но долговечен: знакомая метка — это ещё не полный набор правил.

Источники