Язык (и) | Международный |
---|---|
Стандартный | RFC 2152 |
Классификация | Формат преобразования Unicode, ASCII armor, кодирование переменной ширины, кодирование с отслеживанием состояния |
Преобразования / Кодирует | Unicode |
, которому предшествует | HZ-GB-2312 |
, затем | UTF-8 вместо 8BITMIME |
|
UTF-7 (7- бит Формат преобразования Unicode ) - это кодировка символов переменной длины для представления текста Unicode с использованием потока символов ASCII. Первоначально он был предназначен для обеспечения средств кодирования текста Unicode для использования в сообщениях Internet электронной почты, которые были более эффективными, чем комбинация UTF -8 с quoted-printable.
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 (что равно 00A3
16в UTF-16), который преобразуется в модифицированный Base64, как в таблице ниже. Осталось два бита, которые дополняются до 0.Шестнадцатеричная цифра | 0 | 0 | A | 3 | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Битовый шаблон | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 0 |
Индекс | 0 | 10 | 12 | |||||||||||||||
Base64-Encoded | A | K | M |
Сначала кодировщик должен решить какие символы представлять непосредственно в форме ASCII, какие символы +
должны быть экранированы как + -
, а какие - помещать в блоки символов Unicode. Простой кодировщик может кодировать все символы, которые он считает безопасно для прямого кодирования. Однако стоимость завершения последовательности Unicode, вывода одного символа непосредственно в ASCII и последующего запуска другой последовательности Unicode составляет от 3 до 3 ⁄ 3 байтов. Это больше, чем 2 ⁄ 3 байтов, необходимых для представления символа как части последовательности Unicode. Каждая последовательность Unicode должна быть закодирована с использованием следующей процедуры, а затем окружена соответствующими разделителями.
Использование последовательности символов £ † (U + 00A3 U + 2020) в качестве примера:
Сначала закодированные данные должны быть разделены на фрагменты простого текста ASCII (включая + es, за которыми следует тире) и непустые блоки Unicode, как указано в разделе описания. Как только это будет сделано, каждый блок Unicode должен быть декодирован с помощью следующей процедуры (используя результат приведенного выше примера кодирования в качестве нашего примера)
Подпись 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, который большинство валидаторов пропускают как простой текст.