Jump to content

UTF-7

(Перенаправлено с кодовой страницы 65000 )

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 есть недостаток: даже символы 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):

  1. Выразите номера символов в Юникоде (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, как указано в разделе описания. Как только это будет сделано, каждый блок Юникода необходимо декодировать с помощью следующей процедуры (используя результат приведенного выше примера кодирования в качестве нашего примера).

  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 ≡ 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]

См. также

[ редактировать ]
  1. ^ Jump up to: а б «Критическое изменение: пути кода UTF-7 устарели» . docs.microsoft.com . Проверено 8 января 2021 г.
  2. ^ «8.2.2.3. Кодировки символов» . Стандарт HTML 5.1 . W3C.
  3. ^ «12.2.3.3 Кодировки символов» . HTML Уровень жизни . ЧТОРГ.
  4. ^ «Использование международных символов в интернет-почте» . Консорциум Интернет-почты . 1 августа 1998 года. Архивировано из оригинала 7 сентября 2015 года.
  5. ^ «Руководство по настройке» . Документация Dovecot . 8 февраля 2023 г. Разд. «Настройки расположения почты» . Проверено 28 февраля 2023 г. Сохраняйте имена почтовых ящиков на диске, используя UTF-8 вместо модифицированной UTF-7 (mUTF-7).
  6. ^ Криспин, Марк (март 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….
  7. ^ Мельников, Алексей; Лейба, Барри (август 2021 г.). Протокол доступа к сообщениям в Интернете (IMAP) — версия 4rev2 . IETF . дои : 10.17487/RFC9051 . ISSN   2070-1721 . РФК 9051 . Предлагаемый стандарт. сек. 5.1. «Именование почтового ящика». Устаревшие RFC 3501 В IMAP4rev2 имена почтовых ящиков кодируются в Net-Unicode (это отличается от IMAP4rev1).
  8. ^ «Часто задаваемые вопросы — UTF-8, UTF-16, UTF-32 и спецификация» .
  9. ^ «Уточнить рекомендации по использованию спецификации в качестве подписи кодировки UTF-8» (PDF) . Проверено 17 января 2024 г.
  10. ^ «ArticleUtf7 — doctype-mirror — UTF-7: случай отсутствия кодировки — Зеркало Google Doctype — Хостинг проектов Google» . 14 октября 2011 года . Проверено 29 июня 2012 г.
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 7983670bf7599465ca17d89ceedfaa32__1719002820
URL1:https://arc.ask3.ru/arc/aa/79/32/7983670bf7599465ca17d89ceedfaa32.html
Заголовок, (Title) документа по адресу, URL1:
UTF-7 - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)