UTF-7 - UTF-7

UTF-7
Язык (и)Международный
СтандартRFC  2152
КлассификацияФормат преобразования Unicode, ASCII броня, кодирование с переменной шириной, кодирование с сохранением состояния
Преобразует / кодируетUnicode
ПредшествуетHZ-GB-2312
ПреемникUTF-8 над 8BITMIME

UTF-7 (7-кусочек Формат преобразования Unicode ) - устаревшая кодировка символов переменной длины для представления Unicode текст с использованием потока ASCII символы. Первоначально он был предназначен для обеспечения средств кодирования Unicode текст для использования в Интернет Электронное письмо сообщений, которые были более эффективными, чем комбинация UTF-8 с цитируемый-печатный.

UTF-7 (согласно его RFC) не является "Формат преобразования Unicode ", поскольку определение может кодировать только кодовые точки в BMP (первые 65536 кодовых точек Unicode, не включая смайлики и многие другие персонажи). Однако, если переводчик UTF-7 находится в / из UTF-16 тогда он может (и, вероятно, делает) кодировать каждую суррогатную половину, как если бы это была 16-битная кодовая точка, и, таким образом, может кодировать все кодовые точки. Неясно, поддерживает ли это другое программное обеспечение UTF-7 (например, переводчики в UTF-32 или UTF-8).

UTF-7 никогда не был официальным стандартом Консорциум Unicode. Известно, что у него есть проблемы с безопасностью, поэтому программное обеспечение было изменено, чтобы отключить его использование.

Мотивация

MIME, современный стандарт формата электронной почты, запрещает кодирование заголовки с использованием байтовых значений выше диапазона ASCII. Хотя MIME позволяет кодировать тело сообщения в различных наборы символов (шире, чем ASCII), базовая инфраструктура передачи (SMTP, основной стандарт передачи электронной почты) по-прежнему не гарантируется 8-битный чистый. Следовательно, в случае сомнений необходимо применять нетривиальное кодирование передачи контента. к несчастью base64 имеет недостаток в том, чтобы уравнять US-ASCII символы, нечитаемые в клиентах, не поддерживающих MIME. С другой стороны, UTF-8 в сочетании с цитируемый-печатный создает очень неэффективный по размеру формат, требующий 6–9 байтов для символов, отличных от ASCII, из BMP и 12 байтов для символов вне BMP.

Если при кодировании соблюдаются определенные правила, UTF-7 можно отправлять по электронной почте без использования базового MIME. кодирование передачи, но все же должен быть явно идентифицирован как набор текстовых символов. Кроме того, при использовании в заголовках электронной почты, таких как «Тема:», UTF-7 должен содержаться в MIME. закодированные слова определение набора символов. Поскольку закодированные слова заставляют использовать либо цитируемый-печатный или же base64, UTF-7 был разработан, чтобы избежать использования знака = в качестве escape-символа, чтобы избежать двойного экранирования, когда он сочетается с quoted-printable (или его вариантом, RFC 2047 / 1522? Q? -Кодирование заголовков).

UTF-7 обычно не используется в качестве собственного представления в приложениях, так как его очень неудобно обрабатывать. Несмотря на преимущество в размере по сравнению с комбинацией UTF-8 с цитируемой печатью или base64, ныне несуществующий Консорциум Интернет-почты не рекомендуется его использование.[1]

8BITMIME также было введено, что снижает необходимость кодирования тела сообщения в 7-битном формате.

Модифицированная форма UTF-7 (иногда называемая mUTF-7)[нужна цитата ]) в настоящее время используется в IMAP протокол получения электронной почты для имен почтовых ящиков.[2]

Описание

UTF-7 был впервые предложен в качестве экспериментального протокола в RFC 1642, Безопасный для почты формат преобразования Unicode. Этот RFC устарел RFC 2152, информационный RFC, который так и не стал стандартом. В качестве RFC 2152 четко сказано, что RFC «не определяет никаких стандартов Интернета». Несмотря на это, RFC 2152 цитируется как определение UTF-7 в списке кодировок IANA. Также UTF-7 не является стандартом Unicode. Стандарт Юникода 5.0 перечислены только UTF-8, UTF-16 и UTF-32. Существует также модифицированная версия, указанная в RFC 2060, который иногда обозначается как UTF-7.

Некоторые символы могут быть представлены непосредственно как отдельные байты ASCII. Первая группа, известная как «прямые символы», состоит из 62 буквенно-цифровых символов и 9 символов: ' ( ) , - . / : ?. Прямых персонажей безопасно включать буквально. Другая основная группа, известная как «необязательные прямые символы», содержит все остальные печатаемые символы в диапазоне U + 0020–U + 007E кроме ~ \ + и космос. Использование дополнительных прямых символов уменьшает размер и повышает удобочитаемость, но также увеличивает вероятность поломки из-за таких вещей, как плохо спроектированные почтовые шлюзы, и может потребовать дополнительного экранирования при использовании в закодированных словах для полей заголовка.

Пробел, табуляция, возврат каретки и перевод строки также могут быть представлены непосредственно как отдельные байты ASCII. Однако, если закодированный текст будет использоваться в электронной почте, необходимо позаботиться о том, чтобы эти символы использовались способами, не требующими дальнейшего кодирования передачи контента, чтобы они подходили для электронной почты. Знак плюс (+) май быть закодировано как +-.

Другие символы должны быть закодированы в UTF-16 (следовательно, U + 10000 и выше будут закодированы в два суррогата), а затем в модифицированный Base64. Начало этих блоков измененного UTF-16 в кодировке Base64 обозначается значком + знак. Конец обозначается любым символом, не входящим в модифицированный набор Base64. Если символ после измененного Base64 является - (ASCII дефис-минус ), затем он используется декодером, и декодирование возобновляется со следующего символа. В противном случае декодирование возобновляется с символа после base64.

Примеры

  • "Привет, мир!"кодируется как"Привет, мир + ACE-"
  • "1 + 1 = 2"кодируется как"1 + - 1 + AD0- 2"
  • "£1"кодируется как"+ АКМ-1". Кодовый код Unicode для знак фунта стерлингов это U + 00A3 (который 00A316 в UTF-16), который преобразуется в модифицированный Base64 как в таблице ниже. Остались два бита, которые дополняются до 0.
Шестнадцатеричная цифра00А3 
Битовый шаблон000000001010001100
Индекс01012
Кодировка Base64АKM

Алгоритм кодирования и декодирования

Кодирование

Во-первых, кодировщик должен решить, какие символы представлять непосредственно в форме ASCII, а какие + должен быть спасен как +-, и которые помещать в блоки символов Юникода. Простой кодировщик может напрямую кодировать все символы, которые он считает безопасными для прямого кодирования. Однако стоимость завершения последовательности Unicode, вывода одного символа непосредственно в ASCII и последующего запуска другой последовательности Unicode составляет от 3 до3 2⁄3 байтов. Это больше, чем2 2⁄3 байтов, необходимых для представления символа как части последовательности Unicode. Каждая последовательность Unicode должна быть закодирована с использованием следующей процедуры, а затем окружена соответствующими разделителями.

На примере последовательности символов £ † (U + 00A3 U + 2020):

  1. Выразите числа Unicode символа (UTF-16) в двоичном формате:
    • 0x00A3 → 0000 0000 1010 0011
    • 0x2020 → 0010 0000 0010 0000
  2. Соедините двоичные последовательности:
    0000 0000 1010 0011 и 0010 0000 0010 0000 → 0000 0000 1010 0011 0010 0000 0010 0000
  3. Перегруппируйте двоичный файл в группы по шесть бит, начиная слева:
    0000 0000 1010 0011 0010 0000 0010 0000 → 000000 001010 001100 100000 001000 00
  4. Если в последней группе меньше шести бит, добавьте нули в конце:
    000000 001010 001100 100000 001000 00 → 000000 001010 001100 100000 001000 000000
  5. Замените каждую группу из шести бит на соответствующий код Base64:
    000000 001010 001100 100000 001000 000000 → АКМГИА

Расшифровка

Сначала закодированные данные должны быть разделены на фрагменты простого текста ASCII (включая +es, за которым следует дефис) и непустые блоки Unicode, как указано в разделе описания. Как только это будет сделано, каждый блок Unicode должен быть декодирован с помощью следующей процедуры (используя результат приведенного выше примера кодирования в качестве нашего примера)

  1. Выразите каждый код Base64 как битовую последовательность, которую он представляет:
    АКМГИА → 000000 001010 001100 100000 001000 000000
  2. Перегруппируйте двоичный файл в группы по шестнадцать бит, начиная слева:
    000000 001010 001100 100000 001000 000000 → 0000000010100011 0010000000100000 0000
  3. Если в конце стоит неполная группа, содержащая только нули, отбросьте ее (если неполная группа содержит какие-либо единицы, код недействителен):
    0000000010100011 0010000000100000
  4. Каждая группа из 16 бит является номером символа в Юникоде (UTF-16) и может быть выражена в других формах:
    0000 0000 1010 0011 0x00A3 16310

Подпись Unicode

Подпись Unicode (часто называемая «BOM») - это необязательная специальная последовательность байтов в самом начале потока или файла, которая, не являясь самими данными, указывает кодировку, используемую для следующих данных; подпись используется при отсутствии метаданных, обозначающих кодировку. Для данной схемы кодирования подпись - это представление этой схемы кодовой точки Unicode. U + FEFF, так называемой Спецификация (знак порядка байтов) [символ].

В то время как подпись Unicode обычно представляет собой одну фиксированную байтовую последовательность, природа UTF-7 требует 5 вариантов: последние 2 бита 4-го байта кодировки UTF-7 U + FEFF принадлежат к следующий в результате получается 4 возможных битовых шаблона и, следовательно, 4 различных возможных байта в 4-й позиции. Пятый вариант необходим для устранения неоднозначности в случае, когда за подписью не следуют никакие символы. См. Запись UTF-7 в таблица подписей Unicode.

Использовать в сети

По оценкам, в ноябре 2020 года UTF-7 использовали менее 0,0015% сайтов Всемирная паутина,[3] куда UTF-8 с 2009 года была доминирующей кодировкой символов (и даже была описана как «обязательная ... для всех» WHATWG[4]).

Безопасность

UTF-7 позволяет несколько представлений одной и той же исходной строки. В частности, символы ASCII могут быть представлены как часть блоков Unicode. Таким образом, если стандартные процессы экранирования или проверки на основе ASCII используются для строк, которые позже могут быть интерпретированы как UTF-7, тогда блоки Unicode могут использоваться для пропуска вредоносных строк мимо них. Чтобы смягчить эту проблему, системы должны выполнять декодирование перед проверкой и избегать попыток автоматического определения UTF-7.

Старые версии Internet Explorer можно обманом интерпретировать страницу как UTF-7. Это можно использовать для межсайтовый скриптинг атаковать как < и > знаки могут быть закодированы как + ADw- и + AD4- в UTF-7, который большинство валидаторов пропускают как простой текст.[5]

UTF-7 считается устаревшим, по крайней мере, для программного обеспечения Microsoft (.NET), при этом пути кода, ранее поддерживающие его, намеренно нарушены (для предотвращения проблем с безопасностью) в .NET 5 в 2020 году.[6]

Рекомендации

  1. ^ «Использование международных символов в интернет-почте». Консорциум Интернет-почты. 1 августа 1998 г. Архивировано с оригинал 7 сентября 2015 г.
  2. ^ RFC 3501 раздел 5.1.3
  3. ^ «Статистика использования UTF-7 для веб-сайтов, ноябрь 2020 г.». w3techs.com. Получено 11 ноября 2018.
  4. ^ «Стандарт кодирования». encoding.spec.whatwg.org. Получено 15 ноября 2018. Проблемы, описанные здесь, исчезают при использовании исключительно UTF-8, что является одной из многих причин, по которым теперь кодирование является обязательным для всех вещей.
  5. ^ «ArticleUtf7 - doctype-mirror - UTF-7: случай с отсутствующей кодировкой - Зеркало Google Doctype - Хостинг Google Project». Code.google.com. 14 октября 2011 г.. Получено 29 июн 2012.
  6. ^ gewarren. «Критические изменения библиотеки базовых классов - .NET Core». docs.microsoft.com. Получено 11 ноября 2020.

Смотрите также