RFC 3629 | UTF-8, формат преобразования ISO 10646

Аннотация

ISO/IEC 10646-1 определяет большой набор символов, называемый универсальным набором символов (UCS), который охватывает большинство систем письменности мира. Однако первоначально предложенные кодировки UCS были несовместимы со многими современными приложениями и протоколами, и это привело к разработке UTF-8, объекта этой заметки. UTF-8 обладает характеристиками сохранения полного диапазона US-ASCII, обеспечивая совместимость с файловыми системами, синтаксическими анализаторами и другим программным обеспечением, которые полагаются на значения US-ASCII, но прозрачны для других значений. Эта памятка устаревает и заменяет RFC 2279.

Скачать оригинальный документ на английском языке RFC 3629 PDF

1. Введение
2. Условные обозначения
3. Определение UTF-8
4. Синтаксис байтовых последовательностей UTF-8
5. Версии стандартов
6. Порядок следования байтов (BOM)
7. Примеры
8. Регистрация MIME
9. Соображения IANA
10. Вопросы безопасности
11. Благодарности
12. Отличия от RFC 2279
13. Нормативные документы
14. Информационные ссылки
15. URI
16. Заявление об интеллектуальной собственности
17. Адрес автора
18. Полная информация об авторских правах

Статус этой заметки

Этот документ определяет протокол отслеживания стандартов Интернета для интернет-сообщества и запрашивает обсуждение и предложения по улучшению. Пожалуйста, обратитесь к текущей редакции «Официальных стандартов протокола Интернета» (STD 1) для ознакомления с состоянием стандартизации и статусом этого протокола. Распространение этой заметки не ограничено.

Уведомление об авторских правах

1. Введение

ISO/IEC 10646 [ISO.10646] определяет большой набор символов, называемый универсальным набором символов (UCS), который охватывает большинство мировых систем письма. Тот же набор символов определяется стандартом Unicode [UNICODE], который дополнительно определяет свойства символов и другие детали приложения, представляющие большой интерес для разработчиков. До настоящего времени изменения в Юникоде, а также изменения и дополнения в ИСО / МЭК 10646 отслеживали друг друга, так что репертуары символов и назначения кодовых точек оставались синхронизированными. Соответствующие комитеты по стандартизации обязались поддерживать этот очень полезный синхронизм.

ИСО / МЭК 10646 и Unicode определяют несколько форм кодирования их общего репертуара: UTF-8, UCS-2, UTF-16, UCS-4 и UTF-32. В форме кодирования каждый символ представлен как одна или несколько единиц кодирования. Все стандартные формы кодирования UCS, кроме UTF-8, имеют единицу кодирования, превышающую один октет, что затрудняет их использование во многих современных приложениях и протоколах, которые принимают 8 или даже 7-битные символы.

UTF-8, объект этой заметки, имеет одно-октетный блок кодирования. Он использует все биты октета, но обладает качеством сохранения полного диапазона US-ASCII [US-ASCII]: символы US-ASCII кодируются в одном октете, имеющем нормальное значение US-ASCII, и любой октет с таким значением может означать только символ США-ASCII и ничего больше.

UTF-8 кодирует символы UCS как переменное количество октетов, где количество октетов и значение каждого из них зависят от целочисленного значения, назначенного символу в ISO / IEC 10646 (номер символа, или кодовая позиция, кодовая точка или скалярное значение Unicode). Эта форма кодирования имеет следующие характеристики (все значения указаны в шестнадцатеричном формате):

Символьные числа от U+0000 до U+007F (репертуар US-ASCII) соответствуют октетам от 00 до 7F (7-битные значения US-ASCII). Прямым следствием является то, что простая строка ASCII также является допустимой строкой UTF-8.
Значения октетов US-ASCII не появляются иначе в потоке символов в кодировке UTF-8. Это обеспечивает совместимость с файловыми системами или другим программным обеспечением (например, функцией printf () в библиотеках C), которые анализируют на основе значений US-ASCII, но прозрачны для других значений.
Обратное преобразование легко между UTF-8 и другими формами кодирования.
Первый октет много-октетной последовательности указывает количество октетов в последовательности.
Значения октетов C0, C1, F5-FF никогда не появляются.
Границы символов легко найти из любого места в потоке октетов.
Лексикографическая сортировка байтового значения строк UTF-8 такая же, как если бы они были упорядочены по символьным номерам. Конечно, это представляет ограниченный интерес, так как порядок сортировки, основанный на числах символов, почти никогда не является культурно действительным.
Алгоритм быстрого поиска Бойера-Мура можно использовать с данными UTF-8.
Строки UTF-8 могут быть достаточно надежно распознаны как таковые с помощью простого алгоритма, то есть вероятность того, что строка символов в любой другой кодировке появится в качестве действительного UTF-8, мала и уменьшается с увеличением длины строки.

UTF-8 был разработан в сентябре 1992 года Кеном Томпсоном (Ken Thompson), руководствуясь критериями проектирования, указанными Робом Пайком (Rob Pike), с целью определения формата преобразования UCS, который можно использовать в операционной системе Plan9 без прерывания работы. Дизайн Томпсона был изменен посредством стандартизации X / Open Joint Internationalization Group XOJIG (см. [FSS_UTF]), носящей имена FSS-UTF (вариант FSS / UTF), UTF-2 и, наконец, UTF-8.

2. Условные обозначения

Ключевые слова «ОБЯЗАН», «НЕ ОБЯЗАН», «ТРЕБУЕТСЯ», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «СЛЕДУЕТ», «НЕ СЛЕДУЕТ», «РЕКОМЕНДУЕТСЯ», «ВОЗМОЖЕН» и «ДОПОЛНИТЕЛЬНО» в этом документе интерпретироваться как описано в [RFC2119].

Символы UCS обозначаются обозначением U+HHHH, где HHHH — строка из 4–6 шестнадцатеричных цифр, представляющих номер символа в ИСО / МЭК 10646.

3. Определение UTF-8

UTF-8 определяется стандартом Unicode [UNICODE]. Описания и формулы также можно найти в Приложении D к ISO / IEC 10646-1 [ISO.10646]

В UTF-8 символы из диапазона U+0000..U+10FFFF (доступный диапазон UTF-16) кодируются с использованием последовательностей от 1 до 4 октетов. Единственный октет «последовательности» из одного имеет бит высшего порядка, установленный в 0, остальные 7 бит используются для кодирования номера символа. В последовательности из n октетов, n> 1, исходный октет имеет n битов старшего порядка, установленных на 1, за которыми следует бит, установленный на 0. Остальные биты этого октета содержат биты из числа символов быть закодированным. Все последующие октеты имеют бит высшего порядка, установленный на 1, и следующий бит, установленный на 0, оставляя по 6 бит в каждом, чтобы содержать биты из символа, подлежащего кодированию.

Таблица ниже суммирует формат этих различных типов октетов. Буква «x» указывает биты, доступные для кодирования битов номера символа.

Кодирование символа в UTF-8 происходит следующим образом:

Определите количество октетов, необходимое из номера символа и первого столбца таблицы выше. Важно отметить, что строки таблицы являются взаимоисключающими, то есть существует только один допустимый способ кодирования данного символа.
Подготовьте старшие биты октетов согласно второму столбцу таблицы.
Заполните биты, помеченные символом x, из битов номера символа, выраженного в двоичном формате. Начните с помещения бита младшего разряда номера символа в позицию младшего разряда последнего октета последовательности, затем поместите следующий бит старшего порядка номера символа в следующую позицию старшего порядка этого октета и т. д.. Когда биты x последнего октета заполнены, переходите к следующему последнему октету, затем к предыдущему и т. Д., Пока не будут заполнены все биты x.

Определение UTF-8 запрещает кодирование номеров символов между U+D800 и U+DFFF, которые зарезервированы для использования с формой кодирования UTF-16 (в качестве суррогатных пар) и не представляют непосредственно символы. При кодировании в UTF-8 из данных UTF-16 необходимо сначала декодировать данные UTF-16 для получения номеров символов, которые затем кодируются в UTF-8, как описано выше. Это отличается от CESU-8 [CESU-8], который представляет собой UTF-8-подобную кодировку, которая не предназначена для использования в Интернете. CESU-8 работает аналогично UTF-8, но кодирует значения кода UTF-16 (16-разрядные величины) вместо номера символа (кодовая точка). Это приводит к разным результатам для чисел выше 0xFFFF; кодировка этих символов CESU-8 НЕ является допустимой UTF-8.

Декодирование символа UTF-8 происходит следующим образом:

Инициализируйте двоичное число со всеми битами, установленными в 0. Может потребоваться до 21 бита.
Определите, какие биты кодируют номер символа, исходя из количества октетов в последовательности и второго столбца таблицы выше (биты отмечены значком x).
Распределите биты из последовательности в двоичное число, сначала младшие биты из последнего октета последовательности и продолжайте влево, пока не останется ни одного x бит. Двоичное число теперь равно номеру символа.

Реализации вышеописанного алгоритма декодирования ДОЛЖНЫ защищать от декодирования недопустимых последовательностей. Например, наивная реализация может декодировать слишком длинную последовательность C0 80 UTF-8 в символ U + 0000 или суррогатную пару ED A1 8C ED BE B4 в U+233B4. Декодирование недопустимых последовательностей может иметь последствия для безопасности или вызывать другие проблемы. См. Вопросы безопасности (раздел 10) ниже.

4. Синтаксис байтовых последовательностей UTF-8

Для удобства разработчиков, использующих ABNF, здесь дано определение UTF-8 в синтаксисе ABNF.

Строка UTF-8 — это последовательность октетов, представляющая последовательность символов UCS. Последовательность октетов действительна для UTF-8, только если она соответствует следующему синтаксису, который получен из правил для кодирования UTF-8 и выражен в ABNF из [RFC2234].

UTF8-octets = *( UTF8-char )
UTF8-char = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4
UTF8-1 = %x00-7F
UTF8-2 = %xC2-DF UTF8-tail

UTF8-3 = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) / %xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail )
UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) / %xF4 %x80-8F 2( UTF8-tail )
UTF8-tail = %x80-BF

ПРИМЕЧАНИЕ. — Официальное определение UTF-8 содержится в [UNICODE]. Считается, что эта грамматика описывает то же самое, что описывает Unicode, но не претендует на авторитетность. Разработчикам настоятельно рекомендуется полагаться на авторитетный источник, а не на эту ABNF.

5. Версии стандартов

ИСО / МЭК 10646 время от времени обновляется публикацией поправок и дополнительных частей; аналогично, новые версии стандарта Unicode публикуются с течением времени. Каждая новая версия устаревает и заменяет предыдущую, но реализации и, что более важно, данные не обновляются мгновенно.

В целом, изменения сводятся к добавлению новых символов, что не создает особых проблем со старыми данными. В 1996 году поправка 5 к изданию 1993 года ISO / IEC 10646 и Unicode 2.0 переместила и расширила корейский блок хангыль, сделав тем самым все предыдущие данные, содержащие символы хангыль, недопустимыми в новой версии. Unicode 2.0 имеет такое же отличие от Unicode 1.1. Оправданием для разрешения такого несовместимого изменения было то, что не было крупных реализаций и не было значительного количества данных, содержащих хангыль. Инцидент был назван «корейским беспорядком», и соответствующие комитеты обязались никогда и никогда не вносить такое несовместимое изменение (см. Политику консорциума Unicode [1]).

Новые версии и, в частности, любые несовместимые изменения, имеют последствия в отношении меток кодировки MIME, которые будут обсуждаться при регистрации в MIME (раздел 8).

6. Порядок следования байтов (BOM)

Символ UCS U + FEFF «ZERO WIDTH NO-BREAK SPACE» также неофициально известен как «BYTE ORDER MARK» (сокращенно «BOM»). Этот символ может использоваться как подлинный «НУЛЕВОЙ ПРОБЕЛ ZERO WIDTH» в тексте, но имя спецификации указывает на второе возможное использование символа: для добавления символа U+FEFF к потоку символов UCS в качестве «подписи» ». Приемник такого сериализованного потока может затем использовать начальный символ в качестве подсказки о том, что поток состоит из символов UCS, а также для распознавания, какое кодирование UCS задействовано, и, с кодировками, имеющими многооктетный блок кодирования, в качестве способа распознавания порядок сериализации октетов. UTF-8, имеющий однооктетный блок кодирования, эта последняя функция бесполезна, и спецификация всегда будет отображаться как последовательность октетов EF BB BF.

Важно понимать, что символ U+FEFF, появляющийся в любой позиции, отличной от начала потока, ДОЛЖЕН интерпретироваться с семантикой для неразрывного пробела нулевой ширины и НЕ ДОЛЖЕН интерпретироваться как сигнатура. Когда интерпретируется как подпись, стандарт Unicode предполагает, что начальный символ U+FEFF может быть удален перед обработкой текста. Такое удаление необходимо в некоторых случаях (например, при объединении двух строк, потому что в противном случае результирующая строка может содержать непреднамеренное «НУЛЕВОЙ ПРОБЕЛ ЗУРА» в точке соединения), но может повлиять на внешний процесс на другом уровне (например, в виде цифровой подписи или числа символов), которая зависит от наличия всех символов в потоке. Поэтому РЕКОМЕНДУЕТСЯ избегать удаления начального U+FEFF, интерпретируемого как подпись без веской причины, игнорировать его вместо удаления, когда это необходимо (например, для отображения), и удалять его только тогда, когда это действительно необходимо.

U+FEFF в первой позиции потока МОЖЕТ интерпретироваться как неразрывный пробел нулевой ширины и не всегда является сигнатурой. В попытке уменьшить эту неопределенность, Unicode 3.2 добавляет новый символ, U+2060 «WORD JOINER», с точно такой же семантикой и использованием, что и U+FEFF, за исключением функции подписи, и настоятельно рекомендует использовать ее исключительно для выражения word- присоединяющаяся семантика. В конце концов, следуя этой рекомендации, можно с уверенностью сказать, что любой начальный U+FEFF является подписью, а не предполагаемым «нулевым пространством без разрывов».

Между тем, к сожалению, неопределенность сохраняется и может повлиять на интернет-протоколы. Спецификации протокола МОГУТ ограничивать использование U + FEFF в качестве сигнатуры, чтобы уменьшить или устранить потенциальные вредные последствия этой неопределенности. В интересах установления баланса между преимуществами (уменьшение неопределенности) и недостатками (потеря функции сигнатуры) таких ограничений полезно выделить несколько случаев:

Протоколу СЛЕДУЕТ запрещать использование U+FEFF в качестве подписи для тех текстовых элементов протокола, которые протокол обязывает всегда быть UTF-8, причем функция подписи в этих случаях полностью бесполезна.
Протоколу СЛЕДУЕТ также запретить использование U+FEFF в качестве сигнатуры для тех элементов текстового протокола, для которых протокол предоставляет механизмы идентификации кодировки символов, когда ожидается, что реализации протокола будут в состоянии всегда использовать механизмы должным образом. Это будет иметь место, когда элементы протокола поддерживаются под строгим контролем реализации от времени их создания до времени их (должным образом маркированных) передачи.
Протоколу НЕ СЛЕДУЕТ запрещать использование U+FEFF в качестве сигнатуры для тех элементов текстового протокола, для которых протокол не обеспечивает механизмы идентификации кодировки символов, когда запрет будет неосуществимым или когда ожидается, что реализации протокола не будут в состоянии всегда использовать механизмы должным образом. Последние два случая могут возникать с более крупными протокольными элементами, такими как объекты MIME, особенно когда реализации протокола будут получать такие объекты из файловых систем, из протоколов, которые не имеют механизмов идентификации кодирования для полезных нагрузок (таких как FTP) или из других протоколы, которые не гарантируют правильную идентификацию кодировки символов (например, HTTP).

Когда протокол запрещает использование U+FEFF в качестве сигнатуры для определенного элемента протокола, то любой начальный U+FEFF в этом элементе протокола ДОЛЖЕН интерпретироваться как «НУЛЕВОЙ ПРОБЕЛ ЗУРА». Когда протокол НЕ запрещает использование U+FEFF в качестве сигнатуры для определенного элемента протокола, тогда реализации ДОЛЖНЫ быть готовы обработать сигнатуру в этом элементе и реагировать соответствующим образом: используя сигнатуру для идентификации кодировки символов по мере необходимости и удаления или игнорирования подпись при необходимости.

7. Примеры

Последовательность символов U+0041 U+2262 U+0391 U+002E «A<NOT IDENTICAL TO><ALPHA> (A <НЕ ИДЕНТИЧНО ДЛЯ> <ALPHA>).» кодируется в UTF-8 следующим образом:

—+———-+——+—
41 E2 89 A2 CE 91 2E
—+———-+——+—

Последовательность символов U+D55C U+AD6D U+C5B4 (корейский «hangugeo», что означает «корейский язык») кодируется в UTF-8 следующим образом:

————+————+———
ED 95 9C EA B5 AD EC 96 B4
————+————+———

Последовательность символов U+65E5 U+672C U+8A9E (японское «nihongo», что означает «японский язык») кодируется в UTF-8 следующим образом:

———-+————+———-
E6 97 A5 E6 9C AC E8 AA 9E
———-+————+———-

Символ U+233B4 (китайский символ, означающий «пень дерева — stump of tree»), которому предшествует спецификация UTF-8, кодируется в UTF-8 следующим образом:

————+—————
EF BB BF F0 A3 8E B4
————+—————

8. Регистрация MIME

Эта памятка служит основой для регистрации параметра кодировки MIME для UTF-8, в соответствии с [RFC2978]. Значение параметра charset — «UTF-8». Эта строка обозначает типы мультимедиа, содержащие текст, состоящий из символов из репертуара ИСО / МЭК 10646, включая все поправки, по крайней мере, до поправки 5 издания 1993 года (корейский блок), закодированные в последовательность октетов с использованием схемы кодирования, описанной выше. UTF-8 подходит для использования в типах контента MIME с типом верхнего уровня text.

Следует отметить, что метка «UTF-8» не содержит идентификацию версии, что в целом относится к ИСО / МЭК 10646. Это сделано намеренно, обоснование таково:

Метка кодировки MIME предназначена для предоставления только той информации, которая необходима для интерпретации последовательности байтов, полученных на проводе, в последовательность символов, не более того (см. [RFC2045], раздел 2.2). Пока стандарт набора символов не изменяется несовместимо, номера версий не имеют смысла, потому что человек ничего не получает, узнав из тега, что могут быть получены новые назначенные символы, о которых он не знает. Сам тег ничего не рассказывает о новых персонажах, которые все равно будут получены.

Следовательно, до тех пор, пока стандарты развиваются совместимым образом, очевидное преимущество наличия ярлыков, идентифицирующих версии, является только очевидным. Но у таких зависимых от версии меток есть недостаток: когда старое приложение получает данные, сопровождаемые новой, неизвестной меткой, оно может не распознать метку и не сможет полностью справиться с данными, тогда как общая известная метка будет вызвали в основном правильную обработку данных, которая вполне может не содержать никаких новых символов.

Теперь «корейский беспорядок» (поправка 5 к ISO / IEC 10646) является несовместимым изменением, в принципе противоречащим уместности независимой от версии метки кодировки MIME, как описано выше. Но проблема совместимости может появиться только с данными, содержащими корейские символы хангыль, закодированные в соответствии с Unicode 1.1 (или эквивалентно ISO / IEC 10646 до исправления 5), и, возможно, таких данных не о чем беспокоиться, это и есть причина, по которой произошло несовместимое изменение. считается приемлемым.

Таким образом, на практике гарантируется независимая от версии метка, при условии, что метка понимается как относящаяся ко всем версиям после Поправки 5, и при условии, что на самом деле не происходит несовместимых изменений. Если в более поздней версии ISO / IEC 10646 произойдут несовместимые изменения, метка кодировки MIME, определенная здесь, будет оставаться в соответствии с предыдущей версией до тех пор, пока IETF не примет иного решения.

9. Соображения IANA

Запись для UTF-8 в реестре кодировок IANA была обновлена, чтобы указывать на эту заметку.

10. Вопросы безопасности

Разработчики UTF-8 должны учитывать аспекты безопасности того, как они обрабатывают недопустимые последовательности UTF-8. Возможно, что в некоторых обстоятельствах злоумышленник сможет использовать неосторожный синтаксический анализатор UTF-8, отправив ему последовательность октетов, которая не разрешена синтаксисом UTF-8.

Особенно тонкая форма этой атаки может быть выполнена против синтаксического анализатора, который выполняет критические для безопасности проверки достоверности по отношению к форме своего ввода в кодировке UTF-8, но интерпретирует некоторые недопустимые последовательности октетов как символы. Например, синтаксический анализатор может запретить символ NUL при кодировании как однооктетную последовательность 00, но ошибочно разрешить недопустимую двухоктетную последовательность C0 80 и интерпретировать его как символ NUL. Другим примером может быть синтаксический анализатор, который запрещает последовательность октетов 2F 2E 2E 2F («/../»), но разрешает недопустимую последовательность октетов 2F C0 AE 2E 2F. Этот последний эксплойт фактически использовался на широко распространенных вирус-атакующих веб-серверах в 2001 году; Таким образом, угроза безопасности очень реальна.

Другая проблема безопасности возникает при кодировании в UTF-8: описание UTF-8 в стандарте ISO / IEC 10646 позволяет кодировать номера символов до U+7FFFFFFF, получая последовательности длиной до 6 байтов. Следовательно, существует риск переполнения буфера, если диапазон числовых значений не ограничен явно U+10FFFF или если размер буфера не учитывает возможность 5- и 6-байтовых последовательностей.

На безопасность также может влиять характеристика нескольких кодировок символов, включая UTF-8: «одно и то же» (насколько может судить пользователь) может быть представлено несколькими различными последовательностями символов. Например, e с острым акцентом может быть представлен предварительно составленным символом U + 00E9 E ACUTE или канонически эквивалентной последовательностью U + 0065 U + 0301 (E + COMBINING ACUTE). Даже несмотря на то, что UTF-8 предоставляет одну последовательность байтов для каждой последовательности символов, наличие нескольких последовательностей символов для «одной и той же вещи» может иметь последствия для безопасности всякий раз, когда участвуют сопоставление строк, индексация, поиск, сортировка, сопоставление и выбор регулярных выражений. Примером может служить сопоставление строк идентификатора, появляющегося в учетных данных и в записях списка управления доступом. Эта проблема поддается решениям, основанным на формах нормализации Unicode, см. [UAX15].

11. Благодарности

Следующие участники участвовали в составлении и обсуждении этого меморандума: Джеймс Э. Агенброуд, Харальд Альвестранд, Андриес Брауэр, Марк Дэвис, Мартин Дж. Дюрст, Патрик Фальтстром, Нед Фрид, Дэвид Голдсмит, Тони Хансен, Эдвин Ф. Харт, Пол Хоффман, Дэвид Хопвуд, Саймон Йозефссон, Кент Карлссон, Дэн Кон, Маркус Кун, Майкл Кунг, Ален ЛаБонте, Ира Макдональд, Алексей Мельников, Мурата Макото, Джон Гардинер Майерс, Крис Ньюман, Дэн Оскарссон, Роузбх Пурнадер, Мюррей Сарджент, Маркус Шерер Келд Симонсен, Арнольд Винклер, Кеннет Уистлер и Миша Вольф.

12. Отличия от RFC 2279

Ограничен диапазон символов до 0000-10FFFF (доступный диапазон UTF-16).
Сделал Unicode источником нормативного определения UTF-8, сохранив ISO / IEC 10646 в качестве ссылки для символов.
Выровнял терминологию. UTF-8 теперь описывается в терминах формы кодирования номера символа. UCS-2 и UCS-4 почти исчезли.
Превратил примечание, предупреждающее против декодирования недопустимых последовательностей в норматив, НЕ ДОЛЖЕН.
Добавлен новый раздел о спецификации UTF-8 с советами по протоколам.
Удалено предложено UNICODE-1-1-UTF-8 MIME регистрация кодировки.
Добавлен синтаксис ABNF для допустимых последовательностей октетов UTF-8
Расширенный раздел «Вопросы безопасности», в частности влияние нормализации Unicode

13. Нормативные документы

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[ISO.10646] International Organization for Standardization, «Information Technology — Universal Multiple-octet coded Character Set (UCS)», ISO/IEC Standard 10646, comprised
of ISO/IEC 10646-1:2000, «Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1: Architecture and Basic Multilingual Plane», ISO/IEC 10646-2:2001, «Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 2: Supplementary Planes» and ISO/IEC 10646-1:2000/Amd 1:2002, «Mathematical symbols and other characters».

[UNICODE] The Unicode Consortium, «The Unicode Standard — Version 4.0», defined by The Unicode Standard, Version 4.0 (Boston, MA, Addison-Wesley, 2003. ISBN 0-321-18578-1),
April 2003,

http://www.unicode.org/unicode/standard/versions/enumeratedversions.html#Unicode_4_0_0.

14. Информационные ссылки

[CESU-8] Phipps, T., «Unicode Technical Report #26: Compatibility Encoding Scheme for UTF-16: 8-Bit (CESU-8)», UTR 26, April 2002,

http://www.unicode.org/unicode/reports/tr26/.

[FSS_UTF] X/Open Company Ltd., «X/Open Preliminary Specification — File System Safe UCS Transformation Format (FSS-UTF)», May 1993,

http://wwwold.dkuug.dk/jtc1/sc22/wg20/docs/N193-FSS-UTF.pdf.

[RFC2045] Freed, N. and N. Borenstein, «Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies», RFC 2045, November 1996.

[RFC2234] Crocker, D. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», RFC 2234, November 1997.

[RFC2978] Freed, N. and J. Postel, «IANA Charset Registration Procedures», BCP 19, RFC 2978, October 2000.

[UAX15] Davis, M. and M. Duerst, «Unicode Standard Annex #15: Unicode Normalization Forms», An integral part of The Unicode Standard, Version 4.0.0, April 2003,

http://www.unicode.org/unicode/reports/tr15.

[US-ASCII] American National Standards Institute, «Coded Character Set — 7-bit American Standard Code for Information Interchange», ANSI X3.4, 1986.

15. URI

[1] http://www.unicode.org/unicode/standard/policies.html

16. Заявление об интеллектуальной собственности

IETF не занимает никакой позиции относительно действительности или объема какой-либо интеллектуальной собственности или других прав, которые могут быть заявлены как относящиеся к внедрению или использованию технологии, описанной в этом документе, или степени, в которой любая лицензия в рамках таких прав может или не может быть имеется в наличии; это также не означает, что оно приложило какие-либо усилия для выявления таких прав. Информацию о процедурах IETF в отношении прав в документации по стандартам и соответствующей документации можно найти в BCP-11. Могут быть получены копии заявлений о правах, предоставленных для публикации, и любых гарантий лицензий, которые должны быть предоставлены, или в результате попытки получения общей лицензии или разрешения на использование таких прав собственности разработчиками или пользователями данной спецификации. из Секретариата IETF.

IETF предлагает любой заинтересованной стороне довести до ее сведения любые авторские права, патенты или патентные заявки или другие права собственности, которые могут охватывать технологии, которые могут потребоваться для применения этого стандарта. Пожалуйста, отправьте информацию исполнительному директору IETF.

17. Адрес автора

Francois Yergeau
Alis Technologies
100, boul. Alexis-Nihon, bureau 600
Montreal, QC H4M 2P2
Canada

Phone: +1 514 747 2547
Fax: +1 514 747 2561
EMail: fyergeau@alis.com

18. Полная информация об авторских правах

Этот документ и его переводы могут быть скопированы и предоставлены другим лицам, а производные работы, которые комментируют или иным образом объясняют его или помогают в его реализации, могут быть подготовлены, скопированы, опубликованы и распространены, полностью или частично, без каких-либо ограничений. при условии, что вышеупомянутое уведомление об авторских правах и этот параграф включены во все такие копии и производные работы. Однако сам этот документ не может быть изменен каким-либо образом, например, путем удаления уведомления об авторских правах или ссылок на Интернет-сообщество или другие интернет-организации, за исключением случаев, когда это необходимо для разработки стандартов Интернета, и в этом случае процедуры для авторских прав, определенные в необходимо придерживаться процесса интернет-стандартов или по мере необходимости переводить его на другие языки, кроме английского.

Предоставленные выше ограниченные разрешения являются бессрочными и не будут аннулированы Обществом Интернета или его правопреемниками или правопреемниками.

Этот документ и информация, содержащаяся в настоящем документе, предоставляются на условиях «КАК ЕСТЬ», и ИНТЕРНЕТ-ОБЩЕСТВО И ИНТЕРНЕТ-ИНЖЕНЕРНАЯ ЗАДАЧА ОТКАЗЫВАЕТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, НО ОГРАНИЧИВАЯСЬ, НИ ОДНОЙ ГАРАНТИИ, ЧТО ИСПОЛЬЗОВАНИЕ ИНФОРМАЦИИ ЗДЕСЬ НЕ БУДЕТ НАРУШИТЬ ЛЮБЫЕ ПРАВА ИЛИ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОГО ОБЕСПЕЧЕНИЯ ИЛИ ПРИГОДНОСТИ ДЛЯ ОСОБЫХ ЦЕЛЕЙ.

Подтверждение

Финансирование функции RFC Editor в настоящее время обеспечивается Обществом Интернета (Internet Society).