UTF-7

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

• 1 Мотивация
• 2 Описание
• 3 Примеры
• 4 Алгоритм кодирования и декодирования
  • 4.1 Кодирование
  • 4.2 Декодирование
• 5 Подпись Unicode
• 6 Использование в Интернете
• 7 Безопасность
• 8 Ссылки
• 9 См. Также

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

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

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

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

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

UTF-7 был впервые предложен в качестве экспериментального протокола в RFC 1642, безопасном для почты формате преобразования Unicode. Этот RFC устарел в соответствии с RFC 2152, информационным RFC, который так и не стал стандартом. Как четко указано в RFC 2152, RFC «не определяет никаких стандартов Интернета». Несмотря на это, RFC 2152 цитируется как определение UTF-7 в списке кодировок IANA. Также UTF-7 не является стандартом Unicode. В стандарте 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. Начало этих блоков измененного кодированного Base64 UTF-16 обозначается знаком +. Конец обозначается любым символом, не входящим в модифицированный набор Base64. Если символ после измененного Base64 - это -(ASCII дефис-минус ), то он используется декодером, и декодирование возобновляется со следующего символа. В противном случае декодирование возобновляется с символа после base64.

• "Hello, World!"кодируется как" Hello, World + ACE-"
• "1 + 1 = 2"кодируется как" 1 + - 1 + AD0- 2"
• "£1"кодируется как" + AKM-1". Кодовая точка Unicode для знака фунта - U + 00A3 (что равно 00A316в UTF-16), который преобразуется в модифицированный Base64, как в таблице ниже. Осталось два бита, которые дополняются до 0.

Encoding

Сначала кодировщик должен решить какие символы представлять непосредственно в форме ASCII, какие символы +должны быть экранированы как + -, а какие - помещать в блоки символов Unicode. Простой кодировщик может кодировать все символы, которые он считает безопасно для прямого кодирования. Однако стоимость завершения последовательности Unicode, вывода одного символа непосредственно в ASCII и последующего запуска другой последовательности Unicode составляет от 3 до 3 ⁄ 3 байтов. Это больше, чем 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 → AKMgIA

Декодирование

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

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

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

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

По оценкам, в декабре 2018 года UTF-7 использовалась менее чем на 0,003% сайтов в World Wide Web, где UTF-8 с 2009 года является доминирующей кодировкой символов (и даже был описан как "обязательный... для всех вещей" WHATWG ).

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

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

• Сравнение кодировок Unicode