Кратко

  • RFC 2152 открывал знаком + Modified Base64 без заполнителя = над 16-битными величинами Unicode в порядке старшего байта; сдвиг завершался перед символом вне алфавита и не мог пересечь конец строки.
  • Пунктуация Set O могла идти напрямую, несмотря на риск шлюза, а любую последовательность Unicode разрешалось сдвинуть. Успешное декодирование подтверждало символы, но не исходные байты UTF-7, строки, маршрут или авторский замысел.

При переносе архива легче всего проверить то, что видно. Латинские темы писем читаются, фрагменты UTF-7 раскрываются без ошибки. Но если производный Unicode-текст заменил сырой объект, уже невозможно установить, какие знаки шли напрямую, где шлюз пересобрал строки и какие байты когда-то были подписаны.

David Goldsmith и Mark Davis опубликовали RFC 2152 в мае 1997 года как Informational-документ, заменивший RFC 1642. Это не был Internet Standard. Задачей служила семибитная US-ASCII-почта. UTF-8 поверх ещё одной MIME-кодировки мог означать две трансформации и сильное расширение не-ASCII текста. UTF-7 выдавал только ASCII-октеты и оставлял ASCII-фрагменты читаемыми.

Сам RFC ограничивал решение: обычно применять его только на семибитных каналах вроде почты; в других средах выбирать прямой Unicode или UTF-8.

Прямые символы имели разный риск

Set D включал буквы, цифры и девять знаков, исключая + и =. Знаки Set O разрешалось передавать напрямую по выбору, но RFC предупреждал: многие незаконны в заголовках или неверно проходят некоторые шлюзы. Обратную косую черту и тильду исключили из-за частого переопределения в вариантах ASCII.

Приложение A показало один китайский текст двумя способами. Версия с прямым Set O была уязвимее для шлюзов; вторая избегала выбора. Читаемая форма не становилась гарантией прохождения.

Плюс открывал состояние

После + действовал Base64-алфавит RFC 2045 без =. Символ вне Set B закрывал сдвиг. Если это был , он поглощался; +- означал буквальный плюс. Плюс, за которым сразу следовал не Set B и не дефис, образовывал ошибочную последовательность.

До Base64 16-битные величины Unicode сериализовались старшим октетом вперёд. Половины суррогатной пары UTF-16 считались отдельными величинами. Нечётное число октетов было недопустимо; неполные хвостовые биты можно было отбросить лишь при нулевом значении.

Грамматика проверяла синтаксис, а не происхождение. Пример Hi Mom +Jjo-! возвращает улыбку при целой входной строке, но не подтверждает выбор первого кодировщика, неизменность релеев или изображение у автора.

Конец строки закрывал коридор

Сдвинутая последовательность всегда завершалась на конце строки и не могла перейти через него. Поэтому строки разбивали до UTF-7 либо одновременно с кодированием. Если результат оставался длинным, требовалась подходящая MIME content-transfer encoding, а не разрыв внутри блока.

RFC также советовал короткие SMTP-строки с CRLF и преобразование Unicode-разделителей строки и абзаца для читаемости старых систем. Такое изменение могло быть корректным для совместимости, но менять исходную последовательность. Операционная нормализация не равна побайтовому хранению.

Декодирование сводило разные истории в один результат

Rule 2 позволяла сдвигать любую Unicode-последовательность, а Rules 1 и 3 оставляли некоторые символы прямыми. Поэтому разные потоки UTF-7 могли дать одинаковый Unicode. Декодер выполнял текстовую задачу, даже потеряв историю выбора.

Приёмка должна разделять сырой хеш и окончания строк, строгое синтаксическое решение, декодированные единицы Unicode и отображение клиента. Для подписи, расследования или спора нужны исходный объект и хеши каждой границы.

IANA сохраняет UTF-7, MIBenum 1012 и csUTF7. Запись доказывает имя, не внедрение или безопасность. UTF-7-IMAP — другое кодирование, ограниченное именами почтовых ящиков IMAP и не предназначенное для внешнего применения.

RFC 2152 не обсуждал безопасность. Позднейшие материалы Unicode описывали риск разных сравнений и преобразований между компонентами, но сегодня отмечают, что UTR 36 стабилизирован, не поддерживается и частично имеет преемников. Ни молчание 1997 года, ни позднее предупреждение не заменяют измерение продукта.

Проверены два errata: значение 96 соответствует grave accent, а во фразе о конце строки отсутствовало слово. Третье предложение отклонено. Статус важнее общего числа.

Принцип минимальной спецификации Heng Lu удерживает правильный масштаб: общая грамматика решает узкую задачу координации. Running-Code Primacy требует наблюдать реальный шлюз; Reality Layers не даёт превратить charset-метку или читаемый слой в выполненный результат хранения.

Источники