UTF-7
| Язык(и) | Международный |
|---|---|
| Стандартный | РФК 2152 |
| Классификация | Формат преобразования Unicode , броня ASCII , кодирование переменной ширины , кодирование с отслеживанием состояния |
| Преобразует/кодирует | ISO/IEC 10646 ( Юникод ) |
| Предшествует | ХЗ-ГБ-2312 |
| Преемник | UTF-8 через 8BITMIME |
UTF-7 (7- битный формат преобразования Юникода ) — устаревшая кодировка символов переменной длины для представления текста Юникода с использованием потока символов ASCII . Первоначально он был предназначен для предоставления средств кодирования текста Unicode для использования в Интернета сообщениях электронной почты , которые были более эффективными, чем комбинация UTF-8 с Quote-printable .
UTF-7 (согласно его RFC) не является « форматом преобразования Unicode », поскольку определение может кодировать только кодовые точки в BMP (первые 65536 кодовых точек Unicode, которые не включают смайлы и многие другие символы). Однако если переводчик UTF-7 работает в/из UTF-16 , он может (и, вероятно, так и делает) [ нужна цитата ] кодируйте каждую суррогатную половину, как если бы это была 16-битная кодовая точка, и, таким образом, можно кодировать все кодовые точки. Неясно, поддерживает ли это другое программное обеспечение UTF-7 (например, переводчики в UTF-32 или UTF-8).
UTF-7 никогда не был официальным стандартом Консорциума Unicode . Известно, что у него есть проблемы с безопасностью, поэтому в программное обеспечение было внесено изменение, запрещающее его использование. [1] Это запрещено в HTML 5 . [2] [3]
Мотивация [ править ]
MIME , современный стандарт форматов электронной почты, запрещает кодирование заголовков с использованием байтовых значений, превышающих диапазон ASCII. Хотя MIME позволяет кодировать тело сообщения в различных наборах символов (более широких, чем ASCII), базовая инфраструктура передачи ( SMTP , основной стандарт передачи электронной почты) по-прежнему не гарантирует 8-битной чистоты . Поэтому в случае сомнений необходимо применять нетривиальное кодирование передачи контента. К сожалению, у base64 есть недостаток: даже символы US-ASCII становятся нечитаемыми для клиентов, не поддерживающих MIME. С другой стороны, UTF-8 в сочетании с Quote-printable создает очень неэффективный по размеру формат, требующий 6–9 байтов для символов, отличных от ASCII, из BMP и 12 байтов для символов вне BMP.
При условии соблюдения определенных правил при кодировании UTF-7 можно отправлять по электронной почте без использования базовой кодировки передачи MIME , но он все равно должен быть явно идентифицирован как текстовый набор символов. Кроме того, если код UTF-7 используется в заголовках электронных писем, таких как «Тема:», он должен содержаться в словах в кодировке MIME , определяющих набор символов. Поскольку закодированные слова требуют использования либо Quote-printable , либо Base64 , UTF-7 была разработана таким образом, чтобы избежать использования знака = в качестве escape-символа, чтобы избежать двойного экранирования при его сочетании с Quote-printable (или его вариантом, RFC 2047/1522). «Q»-кодировка заголовков).
UTF-7 обычно не используется в качестве собственного представления в приложениях, поскольку его очень неудобно обрабатывать. Несмотря на преимущество в размере по сравнению с комбинацией UTF-8 с Quote-printable или Base64, ныне несуществующий Консорциум Интернет-почты рекомендовал не использовать его. [4]
Также был представлен 8BITMIME , что снижает необходимость кодирования тела сообщения в 7-битном формате.
Модифицированная форма UTF-7 (иногда называемая mUTF-7). [5] ) использовался в протоколе получения электронной почты протокола доступа к сообщениям Интернета (IMAP) , версия 4, версия 1, для «международных» имен почтовых ящиков. [6] В следующей версии, IMAP версии 4, ред. 2, вместо этого используется UTF-8. [7]
Описание [ править ]
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», таких как JIS-Roman ). Использование необязательных прямых символов уменьшает размер и повышает удобочитаемость для человека, но также увеличивает вероятность поломки из-за таких вещей, как плохо спроектированные почтовые шлюзы, и может потребовать дополнительного экранирования при использовании в закодированных словах для полей заголовка.
Пробел, табуляция, возврат каретки и перевод строки также могут быть представлены непосредственно в виде отдельных байтов ASCII. Однако если закодированный текст будет использоваться в электронной почте, необходимо позаботиться о том, чтобы эти символы использовались способами, не требующими дальнейшего кодирования передачи контента, чтобы они были пригодны для электронной почты. Плюсик ( +) может быть закодировано как +-.
Остальные символы должны быть закодированы в UTF-16 (следовательно, U+10000 и выше будут закодированы двумя суррогатами), а затем в модифицированном Base64 . Начало этих блоков модифицированного UTF-16 в кодировке Base64 обозначается значком +знак. Конец обозначается любым символом, не входящим в модифицированный набор Base64. Если символ после измененного Base64 является -(ASCII дефис-минус ), затем он используется декодером, и декодирование возобновляется со следующего символа. В противном случае декодирование возобновляется с символа после base64.
Примеры [ править ]
- "
Hello, World!"кодируется как"Hello, World+ACE-" - "
1 + 1 = 2"кодируется как"1 +- 1 +AD0- 2" - "
£1"кодируется как"+AKM-1". Кодовая точка Unicode для знака фунта — U + 00A3, которая преобразуется в модифицированный Base64, как показано в таблице ниже. Остаются два бита, которые дополняются до 0.
| Шестнадцатеричная цифра | 0 | 0 | А | 3 | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Битовый шаблон | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 0 |
| Индекс | 0 | 10 | 12 | |||||||||||||||
| Кодировка Base64 | А | К | М | |||||||||||||||
Алгоритм кодирования и декодирования [ править ]
Кодировка [ править ]
Во-первых, кодировщик должен решить, какие символы представлять непосредственно в форме ASCII, какие + нужно бежать как +-и что поместить в блоки символов Юникода. Стоимость расширения UTF-7 может быть высокой: например, последовательность символов U+10FFFF U+0077 U+10FFFF составляет 9 байтов в UTF-8, но 17 байтов в UTF-7. (В худшем случае обработка каждой кодовой точки как самостоятельной последовательности приводит к максимальному расширению в 5 раз, например, при кодировании @@ как +AEA-+AEA-.) Каждая последовательность Юникода должна быть закодирована с использованием следующей процедуры, а затем окружена соответствующими разделителями.
На примере последовательности символов £† (U+00A3 U+2020):
- Выразите номера символов в Юникоде (UTF-16) в двоичном виде:
- 0x00A3 → 0000 0000 1010 0011
- 0x2020 → 0010 0000 0010 0000
- Объедините двоичные последовательности:
0000 0000 1010 0011 и 0010 0000 0010 0000 → 0000 0000 1010 0011 0010 0000 0010 0000 - Перегруппируйте двоичный файл в группы по шесть бит, начиная слева:
0000 0000 1010 0011 0010 0000 0010 0000 → 000000 001010 001100 100000 001000 00 - Если последняя группа имеет менее шести бит, добавьте конечные нули:
000000 001010 001100 100000 001000 00 → 000000 001010 001100 100000 001000 000000 - Замените каждую группу из шести битов соответствующим кодом Base64:
000000 001010 001100 100000 001000 000000 → АКМгИА
Расшифровка [ править ]
Сначала закодированные данные необходимо разделить на простые текстовые фрагменты ASCII (включая + es, за которыми следует тире) и непустые блоки Unicode, как указано в разделе описания. Как только это будет сделано, каждый блок Юникода необходимо декодировать с помощью следующей процедуры (используя результат приведенного выше примера кодирования в качестве нашего примера).
- Выразите каждый код Base64 как битовую последовательность, которую он представляет:
АКМгИА → 000000 001010 001100 100000 001000 000000 - Перегруппируйте двоичный файл в группы по шестнадцать бит, начиная слева:
000000 001010 001100 100000 001000 000000 → 0000000010100011 0010000000100000 0000 - Если в конце есть неполная группа, содержащая только нули, отбросьте ее (если неполная группа содержит какие-либо единицы, код недействителен):
0000000010100011 0010000000100000 - Каждая группа из 16 бит представляет собой номер символа в Юникоде (UTF-16) и может быть выражена в других формах:
0000 0000 1010 0011 ≡ 0x00A3 ≡ 163 10
Знак порядка байтов [ править ]
Метка порядка байтов (BOM) — это необязательная специальная последовательность байтов в самом начале потока или файла, которая, не будучи сама по себе данными, указывает кодировку, используемую для последующих данных; его можно использовать при отсутствии метаданных, обозначающих кодировку. Для данной схемы кодирования это представление этой схемы кодовой точки Юникода. U+FEFF. [8]
Хотя обычно это одна фиксированная последовательность байтов, в UTF-7 могут появиться четыре варианта, поскольку последние 2 бита 4-го байта кодировки UTF-7 U+FEFFпринадлежат следующему символу , что приводит к 4 возможным битовым комбинациям и, следовательно, к 4 различным возможным байтам в 4-й позиции. См. запись UTF-7 в таблице знаков порядка байтов Юникода . [9]
Безопасность [ править ]
UTF-7 допускает несколько представлений одной и той же исходной строки. В частности, символы ASCII могут быть представлены как часть блоков Юникода. Таким образом, если стандартные процессы экранирования или проверки на основе ASCII используются для строк, которые позже могут быть интерпретированы как UTF-7, то блоки Unicode могут использоваться для пропуска вредоносных строк мимо них. Чтобы решить эту проблему, системы должны выполнять декодирование перед проверкой и избегать попыток автоматического определения UTF-7.
Более старые версии Internet Explorer можно обмануть, интерпретируя страницу как UTF-7. Это можно использовать для атаки с использованием межсайтовых сценариев , поскольку < и > метки могут быть закодированы как +ADw- и +AD4- в UTF-7, который большинство валидаторов воспринимают как простой текст. [10]
UTF-7 считается устаревшим, по крайней мере, для программного обеспечения Microsoft (.NET), поскольку пути кода, ранее поддерживавшие его, намеренно нарушены (во избежание проблем безопасности) в .NET 5 в 2020 году. [1]
См. также [ править ]
Ссылки [ править ]
- ^ Перейти обратно: а б «Критическое изменение: пути кода UTF-7 устарели» . docs.microsoft.com . Проверено 8 января 2021 г.
- ^ «8.2.2.3. Кодировки символов» . Стандарт HTML 5.1 . W3C.
- ^ «12.2.3.3 Кодировки символов» . HTML Уровень жизни . ЧТОРГ.
- ^ «Использование международных символов в интернет-почте» . Консорциум Интернет-почты . 1 августа 1998 года. Архивировано из оригинала 7 сентября 2015 года.
- ^ «Руководство по настройке» . Документация Dovecot . 8 февраля 2023 г. Разд. «Настройки расположения почты» . Проверено 28 февраля 2023 г.
Сохраняйте имена почтовых ящиков на диске, используя UTF-8 вместо модифицированной UTF-7 (mUTF-7).
- ^ Криспин, Марк (март 2003 г.). ПРОТОКОЛ ДОСТУПА К СООБЩЕНИЯМ В ИНТЕРНЕТЕ – ВЕРСИЯ 4rev1 . Сетевая рабочая группа. дои : 10.17487/RFC3501 . РФК 3501 . Предлагаемый стандарт. сек. 5.1.3 «Международное соглашение об именах почтовых ящиков». Устарело RFC 9051. Updated by RFC 7817, 8437, 8474, 4551, 4469, 5182, 4466, 5032 and 5738. Obsoletes РФК 2060 .
В модифицированной UTF-7 печатные символы US-ASCII, за исключением «&», представляют собой…. Символ «&» (0x26) представлен двухбайтовой последовательностью «&-». Все остальные символы… представлены в модифицированном BASE64….
- ^ Мельников, Алексей; Лейба, Барри (август 2021 г.). Протокол доступа к сообщениям в Интернете (IMAP) — версия 4rev2 . IETF . дои : 10.17487/RFC9051 . ISSN 2070-1721 . РФК 9051 . Предлагаемый стандарт. сек. 5.1. «Именование почтового ящика». Устаревшие RFC 3501
В IMAP4rev2 имена почтовых ящиков кодируются в Net-Unicode (это отличается от IMAP4rev1).
- ^ «Часто задаваемые вопросы — UTF-8, UTF-16, UTF-32 и спецификация» .
- ^ «Уточнить рекомендации по использованию спецификации в качестве подписи кодировки UTF-8» (PDF) . Проверено 17 января 2024 г.
- ^ «ArticleUtf7 — doctype-mirror — UTF-7: случай отсутствия кодировки — Зеркало Google Doctype — Хостинг проектов Google» . 14 октября 2011 года . Проверено 29 июня 2012 г.
