RFC 6365 | Терминология, используемая в интернационализации в IETF

Аннотация

Этот документ содержит список терминов, используемых в IETF при обсуждении интернационализации. Цель состоит в том, чтобы помочь организовать обсуждения интернационализации в различных областях IETF и помочь представить основные концепции участникам IETF.

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

 

Оглавление

1. Введение
1.1. Цель этого документа
1.2. Формат определений в этом документе
1.3. Нормативная терминология
2. Основные термины
language — язык
script — скрипт
writing system — система письма
character — символ
coded character — закодированный символ
coded character set — набор закодированных символов
character encoding form — форма кодировки символов
repertoire — репертуар
glyph — глиф
glyph code — глиф код
transcoding — транскодирование
character encoding scheme — схема кодирования символов
charset — кодировка
internationalization — интернационализация
localization — локализация
i18n, l10n
multilingual — многоязычный
displaying and rendering text — отображение и рендеринг текста
3. Стандарты «Органы и стандарты»
3.1. Стандарты Органов
ISO и ISO / IEC JTC 1
Unicode Consortium — Консорциум Юникод
World Wide Web Consortium (W3C) — Консорциум World Wide Web (W3C)
local and regional standards organizations — местные и региональные организации по стандартизации
3.2. Кодировки и форматы преобразования ISO / IEC 10646
Basic Multilingual Plane (BMP) — Базовая многоязычная плоскость (BMP)
UCS-2 и UCS-4
UTF-8
UTF-16, UTF-16BE и UTF-16LE
UTF-32
SCSU and BOCU-1
3.3. Родные CCS и Charsets
4. Проблемы с символами
code point — кодовая точка
combining character — комбинирующий символ
composite sequence or combining character sequence — составная последовательность или комбинация последовательности символов
normalization — нормализация
case — дело
sorting and collation — сортировка и сопоставление
code table — таблица кодов
4.1. Типы символов
alphabetic — буквенный
ideographic — идеографический
digit or number — цифра или номер
punctuation — пунктуация
symbol — условное обозначение
nonspacing character — непроходной символ
diacritic — диакритика
control character — управляющий символ
formatting character — форматирование символа
compatibility character or compatibility variant — символ совместимости или вариант совместимости
4.2. Дифференциация подмножеств
non-ASCII — не-ASCII
letters — буквы
5. Пользовательский интерфейс для текста
input methods — методы ввода
rendering rules — правила рендеринга
graphic symbol — графический символ
font — шрифт
bidirectional display — двунаправленный дисплей
undisplayable character — недисплейный символ
writing style — стиль письма
6. Текст в текущих протоколах IETF
protocol elements — элементы протокола
name spaces — пространства имен
on-the-wire encoding — кодирование по проводам
parsed text — проанализированный текст
charset identification — идентификация кодировки
language identification — идентификация языка
MIME
transfer encoding syntax — синтаксис передачи кодирования
Base64
quoted printable — цитируемый для печати
XML
ASN.1 text formats — Текстовые форматы ASN.1
ASCII-compatible encoding (ACE) — ASCII-совместимое кодирование (ACE)
LDH label — Лейбл LDH
7. Термины, связанные с интернационализированными доменными именами
7.1. Терминология IDNA
Stringprep
Punycode
7.2. Отношения персонажей и варианты
8. Другие общие термины в интернационализации
locale — место действия
Latin characters — Латинские символы
Romanization — Романизация
CJK characters and Han characters — Символы CJK и символы Хань
translation — перевод
transliteration — транслитерация
transcription — транскрипция
regular expressions — регулярные выражения
private use character — личное использование символов
9. Вопросы безопасности
10. Ссылки
10.1. Нормативные ссылки
10.2. Информационные ссылки
Приложение А. Дополнительное интересное чтение
Приложение Б. Благодарности
Приложение C. Значительные изменения по сравнению с RFC 3536
Индекс
Адрес автора

 

 

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

Эта памятка документирует лучшую текущую практику Интернета.

Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественное обозрение и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Дополнительная информация о ПП доступна в Разделе 2 RFC 5741.

Информацию о текущем состоянии этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу http://www.rfc-editor.org/info/rfc6365.

 

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

Copyright (c) 2011 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.

На данный документ распространяется действие ПП 78 и Правовые положения IETF Trust, относящиеся к документам IETF (http://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны включать в себя текст упрощенной лицензии BSD, как описано в разделе 4.e Правил доверия, и предоставляются без гарантии, как описано в упрощенной лицензии BSD.

 

1. Введение

В спецификации политики набора символов IETF [RFC2277] резюмируется: «Интернационализация предназначена для людей. Это означает, что протоколы не подлежат интернационализации; текстовые строки». Во многих протоколах IETF используются текстовые строки, которые вводятся людьми или являются видимыми для людей. С учетом только ограничений своих собственных знаний и возможностей любой человек может иметь возможность вводить или читать эти текстовые строки, что означает, что пользователи Интернета должны иметь возможность вводить текст с использованием типичных методов ввода и отображать его на любом человеческом языке. , Кроме того, текст, содержащий любой символ, должен легко передаваться между Интернет-приложениями. Это проблема интернационализации.

 

1.1. Цель этого документа

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

Интернационализация обсуждается во многих рабочих группах IETF. Однако немногие рабочие группы имеют экспертов по интернационализации. При разработке или обновлении протоколов часто возникает вопрос: «Должны ли мы это интернационализировать?» (или, более вероятно, «Мы должны интернационализировать это?»).

В этом документе дается обзор терминологии интернационализации применительно к работе над стандартами IETF, слегка освещая многие аспекты интернационализации и словарь, связанный с этими темами. Часть обзора носит обучающий характер. Оно не предназначено для полного описания интернационализации. Определения здесь ДОЛЖНЫ использоваться стандартами IETF. Стандарты IETF, которые явно хотят создавать разные определения для терминов, определенных здесь, могут это делать, но если не предоставлено альтернативное определение, применяются определения терминов в этом документе. Для ясности стандарты IETF, требующие разных определений, поощряются к тому, чтобы находить термины, отличающиеся от определенных здесь. Некоторые определения в этом документе взяты из более ранних документов и книг IETF.

Как и во многих областях, в сообществе интернационализации существуют разногласия по поводу определения многих слов. Тема языка поднимает особенно страстные мнения как экспертов, так и неопытных. В этом документе делается попытка определить термины таким образом, чтобы они были наиболее полезны для аудитории IETF.

В этом документе используются определения из многих документов, которые были разработаны внутри и вне IETF. Основные используемые документы:

• ISO / IEC 10646 [ISOIEC10646]
• Стандарт Юникода [UNICODE]
• Модель персонажа W3C [CHARMOD]
• RFC IETF, включая спецификацию политики набора символов [RFC2277] и стандарт интернационализации доменного имени [RFC5890]

 

1.2. Формат определений в этом документе

В основной части этого документа источник определения указан в угловых скобках, например «<ISOIEC10646>». Многие определения отображаются как «<RFC6365>», что означает, что определения были изначально созданы для этого документа. Нотация в угловых скобках для источника определений отличается от нотации в квадратных скобках, используемой для ссылок на документы, как, например, в абзаце выше; эти ссылки приведены в справочных разделах этого документа.

Для некоторых терминов есть комментарии и примеры после определений. В этих случаях часть перед угловыми скобками — это определение, исходящее из исходного источника, а часть после угловых скобок — это комментарий, который не является определением (например, пример или дальнейшее изложение).

Примеры в этом документе используют обозначения для кодовых точек и имен из стандарта Unicode [UNICODE] и ISO / IEC 10646 [ISOIEC10646]. Например, буква «a» может быть представлена ​​как «U + 0061» или «LATIN SMALL LETTER A». См. RFC 5137 [RFC5137] для описания этой записи.

 

1.3. Нормативная терминология

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

 

2. Основные условия

В этом разделе рассматриваются основные темы, которые нужны почти всем, кто занимается созданием протоколов IETF, более дружественных к тексту, не относящемуся к ASCII (см. Раздел 4.2), а также к другим аспектам интернационализации.

language — язык

Язык — это способ общения людей. Использование языка встречается во многих формах, наиболее распространенными из которых являются речь, письмо и подписание. <RFC6365> Некоторые языки имеют тесную связь между письменной и устной формами, в то время как другие имеют более слабые отношения. Так называемые стандарты LTRU (Обновление реестра языковых тегов) [RFC5646] [RFC4647] более подробно обсуждают языки и предоставляют идентификаторы языков для использования в интернет-протоколах. Обратите внимание, что компьютерные языки явно исключены из этого определения.

script — скрипт

Набор графических символов, используемых для письменной формы одного или нескольких языков. <ISOIEC10646>

Примерами сценариев являются латиница, кириллица, греческий, арабский и ханьский (символы, часто называемые идеографами после их подмножества, используемые при написании китайского, японского и корейского языков). В RFC 2277 подробно рассматриваются сценарии.

Для новичков интернационализации характерно смешивать термины «язык» и «сценарий». Это может быть проблемой в протоколах, которые различают два. Почти все протоколы, которые разработаны (или были перепроектированы) для обработки текста, не относящегося к ASCII, имеют дело со сценариями (письменными системами) или символами, в то время как меньшее количество фактически имеет дело с языками.

Одно имя может означать либо язык, либо сценарий; например, «арабский» — это и название языка, и название сценария. На самом деле, многие сценарии заимствуют свои имена из названий языков. Кроме того, многие сценарии используются для написания более чем одного языка; например, русский и болгарский языки написаны кириллицей. Некоторые языки могут быть выражены с использованием разных сценариев или использовались с разными сценариями в разное время; монгольский язык может быть написан либо на монгольском, либо на кириллице; Сегодня малайский язык в основном написан латинскими буквами, но более ранняя форма на языке арабского алфавита до сих пор используется; и ряд языков был преобразован из других шрифтов в кириллицу в первой половине прошлого века, некоторые из которых снова переключились совсем недавно. Кроме того, некоторые языки обычно выражаются несколькими сценариями одновременно; например, японский язык обычно выражается в сценариях кандзи (хань), катакана и хирагана в виде одной строки текста.

writing system — система письма

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

character — символ

Член набора элементов, используемых для организации, контроля или представления данных. <ISOIEC10646>

Существует как минимум три общих определения слова «символ»:

• общее описание текстовой сущности
• блок системы письма, часто синонимичный с «буквой» или подобными терминами, но обобщенный, чтобы включать цифры и символы различных видов
• сам кодированный объект

Когда люди говорят о символах, они обычно имеют в виду одно из первых двух определений. Термин «character» часто сокращается как «char».

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

coded character — закодированный символ

Символ вместе с его кодированным представлением. <ISO IEC 10646>

coded character set — набор закодированных символов

Набор кодированных символов (CCS) — это набор однозначных правил, которые устанавливают набор символов и взаимосвязь между символами набора и их кодированным представлением. <ISOIEC10646>

character encoding form — форма кодировки символов

Форма кодирования символов представляет собой сопоставление набора кодированных символов (CCS) с фактическими единицами кода, используемыми для представления данных. <UNICODE>

repertoire — репертуар

Коллекция символов, включенных в набор символов. Также называется репертуар символа. <UNICODE>

glyph — глиф

Глиф — это изображение символа, которое может отображаться после отображения на поверхности дисплея. <RFC6365>

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

glyph code — глиф код

Код глифа — это числовой код, который относится к глифу. Обычно на глифы, содержащиеся в шрифте, ссылается их код глифа. Коды глифа являются локальными для определенного шрифта; то есть другой шрифт, содержащий одинаковые глифы, может использовать разные коды. <UNICODE>

transcoding — транскодирование

Транскодирование — это процесс преобразования текстовых данных из одной формы кодировки символов в другую. Транскодеры работают только на уровне кодировки символов и не анализируют текст. Примечание. Транскодирование может включать в себя отображения «один к одному», «многие к одному», «один ко многим» или «многие ко многим». Поскольку некоторые устаревшие отображения являются глифическими, они могут быть не только множественными, но и неупорядоченными: таким образом, XYZ может отображаться в yxz. <CHARMOD>

В этом определении «многие-к-одному» означает последовательность символов, сопоставленных с одним символом. «Много» не означает альтернативные символы, которые отображаются на один символ.

character encoding scheme — схема кодирования символов

Схема кодирования символов (CES) — это форма кодирования символов плюс байтовая сериализация. В Unicode есть много схем кодирования символов, таких как UTF-8 и UTF-16BE. <UNICODE>

Некоторые CES связаны с одной CCS; например, UTF-8 [RFC3629] применяется только к идентичным CCS ISO / IEC 10646 и Unicode. Другие CES, такие как ISO 2022, связаны со многими CCS.

charset — кодировка

Кодировка — это метод отображения последовательности октетов на последовательность абстрактных символов. По сути, кодировка представляет собой комбинацию одного или нескольких CCS с CES. Имена кодировок регистрируются IANA в соответствии с процедурами, описанными в [RFC2978]. <RFC6365>

Многие определения протоколов используют термин «набор символов» в своих описаниях. Термины «кодировка» или «схема кодирования символов» и «набор кодированных символов» настоятельно предпочтительнее термина «набор символов», поскольку «набор символов» имеет другие определения в других контекстах, в частности вне IETF. При чтении стандартов IETF, в которых используется «набор символов» без определения термина, они обычно означают «конкретную комбинацию одной CCS с CES», особенно когда речь идет о «наборе символов US-ASCII».

internationalization — интернационализация

В IETF «интернационализация» означает добавление или улучшение обработки текста не-ASCII в протоколе. <RFC6365> Другая точка зрения, более подходящая для протоколов, которые с самого начала предназначены для глобального использования, — это определение, используемое W3C:

• «Интернационализация — это дизайн и разработка продукта, приложения или содержимого документа, которое позволяет легко локализовать целевую аудиторию, различную по культуре, региону или языку». [W3C-i18n-Def]

Многие протоколы, которые обрабатывают текст, обрабатывают только одну кодировку (US-ASCII) или оставляют вопрос о том, какие CCS и кодирование используются до локальных догадок (что, конечно, приводит к проблемам взаимодействия). Если разрешено несколько кодировок, они должны быть явно идентифицированы [RFC2277]. Добавление не-ASCII-текста в протокол позволяет протоколу обрабатывать больше сценариев, возможно, всех полезных в мире. В современном мире это обычно лучше всего достигается, если использовать кодировку Unicode только в UTF-8, что устраняет проблемы с преобразованием в сторону от индивидуального выбора.

localization — локализация

Процесс адаптации интернационализированной прикладной платформы или приложения к конкретной культурной среде. При локализации сохраняется та же семантика, а синтаксис может быть изменен. [ФРЕЙМВОРК]

Локализация — это процесс адаптации приложения к другому языку, сценарию или культуре. Некоторые интернационализированные приложения могут работать с различными языками. Обычные пользователи понимают только небольшое количество языков, поэтому программа должна быть адаптирована для взаимодействия с пользователями только на тех языках, которые они знают.

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

Локализация редко является вопросом IETF, и протоколы, которые просто локализованы, даже если они последовательно локализованы для нескольких местоположений, обычно считаются неудовлетворительными для глобальной сети Интернет.
Не путайте «локализацию» с «локалью», которая описана в разделе 8 этого документа.

i18n, l10n

Это аббревиатуры для «интернационализация» и «локализация». <RFC6365>

«18» — это количество символов между «i» и «n» в «интернационализации», а «10» — количество символов между «l» и «n» в «локализации».

multilingual — многоязычный

Термин «многоязычный» имеет много различных определений и поэтому не рекомендуется для использования в стандартах. Некоторые из определений относятся к способности обрабатывать международные символы; другие определения относятся к способности обрабатывать несколько кодировок; а третьи касаются способности работать с несколькими языками. <RFC6365>

displaying and rendering text — отображение и рендеринг текста

Для отображения текста система размещает символы на устройстве визуального отображения, таком как экран или принтер. Для визуализации текста система анализирует ввод символов, чтобы определить, как отображать текст. Термины «отображение» и «визуализация» иногда используются взаимозаменяемо. Обратите внимание, однако, что текст может отображаться как аудио и / или тактильный вывод, например, в системах, которые были разработаны для людей с нарушениями зрения. <RFC6365>

Комбинированные символы изменяют отображение символа (или, в некоторых случаях, символов), предшествующего им. При рендеринге такого текста механизм отображения должен либо найти глиф в шрифте, который представляет базовый символ и все комбинирующие символы, либо он должен отобразить саму комбинацию. Такой рендеринг может быть простым, но иногда это сложно, когда комбинирующие метки взаимодействуют друг с другом, например, когда есть две комбинирующие метки, которые появляются над одним и тем же символом. Форматирование символов также может изменить способ отображения текста средством визуализации. Рендеринг также может быть затруднен для некоторых скриптов, которые имеют сложные правила отображения для базовых символов, таких как скрипты на арабском и индийском языках.

 

3. Стандарты Органы и стандарты

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

3.1. Стандарты Органов

ISO и ISO / IEC JTC 1

Международная организация по стандартизации была связана со стандартами для персонажей еще до начала IETF. ИСО является неправительственной группой, состоящей из национальных органов. Большая часть работы ИСО в области информационных технологий выполняется совместно с аналогичным органом, Международной электротехнической комиссией (МЭК), через объединенный комитет, известный как «JTC 1». ISO и ISO / IEC JTC 1 имеют много различных стандартов в области международных символов; тот, который наиболее часто используется в IETF, обычно называется «ИСО / МЭК 10646», иногда с определенной датой. ISO / IEC 10646 описывает CCS, которая охватывает почти все известные письменные символы, используемые сегодня.

ИСО / МЭК 10646 контролируется группой, известной как «ISO / IEC JTC 1 / SC 2 WG2», для краткости часто называемой «SC2 / WG2» или «WG2». Стандарты ИСО проходят много этапов, прежде чем заканчиваются, и между изменениями базового стандарта ИСО / МЭК 10646 часто проходят годы, хотя в настоящее время выпускаются поправки для отслеживания изменений в Юникоде.

Информацию о WG2 и ее рабочих продуктах можно найти по адресу <http://www.dkuug.dk/JTC1/SC2/WG2/>.

Информацию о SC2 и продуктах его работы можно найти по адресу <http://www.iso.org/iso/standards_development/technical_committees/list_of_iso_technical_committees/iso_technical_committee.htm?commid=45050>

Стандарт поставляется в виде базовой части и серии приложений или поправок. Он доступен для скачивания в формате PDF или на компакт-диске. Один пример того, как цитировать стандарт, приведен в [RFC3629]. Любой стандарт, который цитирует ИСО / МЭК 10646, должен оценивать, как решить проблему управления версиями, которая соответствует потребностям протокола.

ISO отвечает за другие стандарты, которые могут представлять интерес для разработчиков протоколов, заинтересованных в интернационализации. ISO 639 [ISO639] определяет названия языков и является частью основы для работы языкового тега IETF [RFC5646]. ISO 3166 [ISO3166] определяет названия и сокращения кодов для стран и территорий и используется в нескольких протоколах и базах данных, включая имена для доменных имен верхнего уровня с кодом страны. Обязанности ИСО ТК 46 по информации и документации <http://www.iso.org/iso/standards_development/technical_committees/list_of_iso_technical_committees/iso_technical_committee.htm?commid=48750> включают серию стандартов для транслитерации различных языков на латинские символы.

Другой соответствующей группой ISO была JTC 1 / SC22 / WG20, которая отвечала за интернационализацию в JTC 1, например, за международный порядок строк. Информацию о WG20 и ее рабочих продуктах можно найти по адресу <http://www.dkuug.dk/jtc1/sc22/wg20/>. Конкретные задачи SC22 / WG20 были перенесены из SC22 в SC2, и с тех пор там не было значительных действий.

Unicode Consortium — Консорциум Юникод

Вторая важная группа для международных стандартов характера — Консорциум Unicode. Консорциум Unicode — это торговая ассоциация компаний, правительств и других групп, заинтересованных в продвижении стандарта Unicode [UNICODE]. Стандарт Unicode — это CCS, репертуар и кодовые точки которого идентичны ISO / IEC 10646. Консорциум Unicode добавил в базовую CCS функции, которые делают его более полезным в протоколах, например, определение атрибутов для каждого символа. Примеры этих атрибутов включают преобразование регистра и числовые свойства.

Фактическая техническая и определяющая работа Консорциума Unicode выполняется в Техническом комитете Unicode (UTC). Термины «UTC» и «Unicode Consortium» часто трактуются неточно, как синонимы в IETF.

Консорциум Unicode публикует дополнения к стандарту Unicode в виде технических отчетов Unicode. Существует много видов технических отчетов на разных стадиях зрелости. Стандарт Unicode и связанные с ним технические отчеты можно найти по адресу <http://www.unicode.org/>.

Взаимное соглашение между Консорциумом Юникод и JTC 1 / SC 2 ИСО / МЭК предусматривает, что ИСО / МЭК 10646 и Стандарт Юникод отслеживают друг друга для определения символов и назначений кодовых точек. Обновления, часто в форме поправок, к первым иногда отстают от обновлений последних на короткий период, но в последние годы разрыв редко был значительным.

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

World Wide Web Consortium (W3C) — Консорциум World Wide Web (W3C)

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

local and regional standards organizations — местные и региональные организации по стандартизации

Так же, как существует много собственных CCS и кодировок, существует множество местных и региональных организаций по стандартизации, которые создают и поддерживают их. Типичными примерами этого являются ANSI (США), CEN / ISSS (Европа), JIS (Япония) и SAC (Китай).

3.2. Кодировки и форматы преобразования ISO / IEC 10646

Символы в CCS ИСО / МЭК 10646 могут быть выражены многими способами. Исторически «формы кодирования» — это оба метода прямой адресации, в то время как «форматы преобразования» — это методы для выражения форм кодирования в виде битов в проводе. Это различие в основном исчезло в последние годы.

Документы, которые обсуждают символы в CCS ИСО / МЭК 10646, часто должны перечислять определенные символы. RFC 5137 описывает общие методы для этого в документах IETF, и эта практика также была принята многими другими сообществами.

Basic Multilingual Plane (BMP) — Базовая многоязычная плоскость (BMP)

BMP состоит из первых 2 ^ 16 кодовых точек в ISO / IEC 10646 и содержит почти все символы современного использования. BMP также называется «плоскостью 0».

UCS-2 и UCS-4

UCS-2 и UCS-4 являются двумя формами кодирования, исторически определенными для ISO / IEC 10646. UCS-2 обращается только к BMP. Поскольку многие полезные символы (например, многие символы Хан) были определены вне BMP, многие люди считают UCS-2 устаревшим.

UCS-4 обращается ко всему диапазону кодовых точек из ИСО / МЭК 10646 (по соглашению между ИСО / МЭК JTC 1 SC2 и Консорциумом Unicode, диапазон от 0..0x10FFFF) в виде 32-битных значений с нулевым заполнением слева. UCS-4 идентичен UTF-32BE (без использования спецификации (см. Ниже)); UTF-32BE сейчас является предпочтительным термином.

UTF-8

UTF-8 [RFC3629] является предпочтительной кодировкой для протоколов IETF. Символы в BMP кодируются как один, два или три октета. Символы вне BMP кодируются в виде четырех октетов. Символы из репертуара US-ASCII имеют такое же представление в проводном режиме в UTF-8, как и в US-ASCII. Специфичное для IETF определение UTF-8 в RFC 3629 идентично определению в последних версиях стандарта Unicode (например, в разделе 3.9 версии 6.0 [UNICODE]).

UTF-16, UTF-16BE и UTF-16LE

UTF-16, UTF-16BE и UTF-16LE, три формата преобразования, описанные в [RFC2781] и определенные в Стандарте Unicode (разделы 3.9 и 16.8 в Версии 6.0), не требуются никакими стандартами IETF и, таким образом, широко используются реже в протоколах, чем UTF-8. Символы в BMP всегда кодируются в виде двух октетов, а символы вне BMP кодируются в виде четырех октетов с использованием схемы «суррогатная пара». Последний не является частью UCS-2, отмечая разницу между UTF-16 и UCS-2. Три формата UTF-16 различаются в зависимости от порядка октетов и наличия или отсутствия специального начального идентификатора порядка, называемого «меткой порядка байтов» или «BOM».

UTF-32

Консорциум Unicode и ISO / IEC JTC 1 определили UTF-32 как формат преобразования, который включает в себя целочисленное значение кодовой точки, выровненное по правому краю в 32-битном поле. Как и в UTF-16, можно использовать метку порядка байтов (BOM) и определить UTF-32BE и UTF-32LE. UTF-32 и UCS-4 по существу эквивалентны, и эти термины часто используются взаимозаменяемо.

SCSU and BOCU-1

Консорциум Unicode определил кодировку SCSU [UTR6], которая предназначена для обеспечения хорошего сжатия типичного текста. Другое кодирование, которое должно быть MIME-дружественным, BOCU-1, описано в [UTN6]. Хотя сжатие является привлекательным, в отличие от UTF-8, ни один из них (на момент написания этой статьи) не вызвал большого интереса.

Сжатие, предоставляемое в качестве побочного эффекта алгоритма Punycode [RFC3492], интенсивно используется в некоторых контекстах, особенно IDNA [RFC5890], но накладывает некоторые ограничения. (См. Также Раздел 7.)

3.3. Родные CCS и Charsets

До разработки ИСО / МЭК 10646 многие страны разработали свои собственные CCS и кодировки. Некоторые из них были приняты в международные стандарты для соответствующих сценариев или систем письма. Многие десятки из них сегодня широко используются в Интернете. Примеры включают ISO 8859-5 для кириллицы и Shift-JIS для японских шрифтов.

Официальный список зарегистрированных имен кодировок для использования с протоколами IETF поддерживается IANA и находится по адресу <http://www.iana.org/assignments/character-sets>. Список содержит предпочтительные имена и псевдонимы. Обратите внимание, что этот список исторически содержал много ошибок, таких как имена, которые на самом деле не являются наборами символов, или ссылки, которые не дают достаточно подробностей для надежного сопоставления имен с наборами символов.

Вероятно, наиболее известным нативным CCS является ASCII [US-ASCII]. Эта CCS используется в качестве основы для ключевых слов и имен параметров во многих протоколах IETF и в качестве единственной CCS в многочисленных протоколах IETF, которые еще не были интернационализированы. ASCII стал основой для ISO / IEC 646, который, в свою очередь, сформировал основу для многих национальных и международных стандартов, таких как серия ISO 8859, которые смешивают символы базовой латиницы с символами из другого сценария.

Важно отметить, что, строго говоря, «ASCII» — это CCS и репертуар, а не кодировка. Кодирование, используемое для ASCII в протоколах IETF, включает в себя 7-разрядное целое число ASCII-кодовой точки, выровненное по правому краю в 8-разрядном поле, и иногда описывается как кодирование «виртуального сетевого терминала» или «NVT» [RFC5198]. Менее формально «ASCII» и «NVT» часто используются взаимозаменяемо. Однако «не-ASCII» относится только к символам вне репертуара ASCII и не связан с конкретной кодировкой. Смотрите раздел 4.2.

Публикация Unicode описывает проблемы, связанные с отображением символьных данных между кодировками, и формат XML для отображения данных таблицы [UTR22].

 

4. Проблемы с персонажами

Этот раздел содержит термины и темы, которые обычно используются при обработке символов и, следовательно, представляют интерес для людей, добавляющих обработку текстов не-ASCII в протоколы. Эти темы стандартизированы за пределами IETF.

code point — кодовая точка

Значение в кодовом пространстве репертуара. Для всех распространенных репертуаров, разработанных в последние годы, значения кодовых точек являются целыми числами (кодовые точки для ASCII и его непосредственных потомков были определены в терминах позиций столбцов и строк таблицы).

combining character — комбинирующий символ

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

composite sequence or combining character sequence — составная последовательность или комбинация последовательности символов

Последовательность графических символов, состоящая из не комбинирующего символа, за которым следует один или несколько комбинирующих символов. Графический символ для составной последовательности обычно состоит из комбинации графических символов каждого символа в последовательности. Стандарт Unicode часто использует термин «объединение последовательности символов» для обозначения составных последовательностей. Составная последовательность не является символом и, следовательно, не входит в репертуар ИСО / МЭК 10646. <ISOIEC10646> Однако теперь Юникод присваивает имена некоторым таким последовательностям, особенно когда имена должны соответствовать терминологии в других стандартах [UAX34].

В некоторых CCS некоторые символы состоят из комбинаций других символов. Например, буква «а с острым» может быть комбинацией двух символов «а» и «сочетания острого», или это может быть комбинация трех символов «а», неразрушающего возврата и острого. В тех же или других CCS он может быть доступен как одна кодовая точка. Правила объединения двух или более символов называются «правилами композиции», а правила разделения символа на другие символы называются «правилами декомпозиции». Результат разложения называется «разложенным персонажем»; Результатом композиции обычно является «заранее составленный персонаж».

normalization — нормализация

Нормализация — это преобразование данных в нормальную форму, например, для унификации орфографии. <UNICODE>

Обратите внимание, что фраза «унифицировать орфографию» в приведенном выше определении не означает объединение разных строк с тем же значением, что и слова (например, «цвет» и «цвет»). Вместо этого это означает объединение различных последовательностей символов, которые предназначены для формирования одних и тех же составных символов, таких как «<n> <combining tilde>» и «<n with tilde>» (где «<n>» — это U + 006E » <объединяющая тильда> «- это U + 0303, а» <n с тильдой> «- это U + 00F1).

Цель нормализации — позволить двум строкам сравниваться на эквивалентность. Строки «<a> <n> <объединение тильды> <o>» и «<a> <n с тильдой> <o>» будут одинаково отображаться на устройстве отображения текста. Если разработчик протокола хочет, чтобы эти две строки считались эквивалентными во время сравнения, протокол должен определить, где происходит нормализация.

Термины «нормализация» и «канонизация» часто используются взаимозаменяемо. Как правило, они оба означают преобразование строки из одного или нескольких символов в другую строку на основе стандартизированных правил. Однако в Unicode «канонизация» или подобные термины используются для обозначения определенного типа эквивалентности нормализации («каноническая эквивалентность» в отличие от «эквивалентности совместимости»), поэтому этот термин следует использовать с некоторой осторожностью. Некоторые CCS допускают несколько эквивалентных представлений для записанной строки; нормализация выбирает одно из нескольких эквивалентных представлений в качестве основы для справочных целей при сравнении строк. В строках текста эти правила обычно основаны на разложении комбинированных символов или составлении символов с объединением символов. Стандартное приложение Unicode № 15 [UTR15] описывает процесс и многие формы нормализации в деталях. Нормализация важна при сравнении строк, чтобы увидеть, совпадают ли они.

Нормализация Unicode NFC и NFD поддерживает каноническую эквивалентность; NFKC и NFKD поддерживают каноническую эквивалентность и эквивалентность.

case — дело

Регистр — это особенность некоторых алфавитов, в которых буквы имеют две (или иногда больше) разные формы. Эти формы, которые могут заметно различаться по форме и размеру, называются заглавной буквой (также известной как заглавная или прописная) и строчной буквой (также известной как строчная или маленькая). Отображение регистра — это сочетание прописных и строчных букв. <UNICODE>

В обоих случаях обычно (но не всегда) однозначное сопоставление одной и той же буквы. Тем не менее, существует много примеров символов, которые существуют в одном случае, но для которых в другом случае нет соответствующих символов или для которых существует специальное правило отображения, такое как турецкий без точек «i», некоторые греческие символы с модификаторами, и такие персонажи, как немецкий Sharp S (Eszett) и греческая Final Sigma, которые традиционно не имеют заглавных букв. Отображение случая может даже зависеть от локали или языка. Преобразование текста в один регистр, главным образом для сравнения, называется «сворачиванием регистра». Из-за различных необычных случаев отображение дел может быть довольно спорным, а некоторые алгоритмы сворачивания дел — еще более. Например, некоторые языки программирования, такие как Java, имеют алгоритмы свертывания регистра, которые чувствительны к локали; это делает эти алгоритмы невероятно ресурсоемкими и заставляет их действовать по-разному в зависимости от местоположения системы во время использования алгоритма.

sorting and collation — сортировка и сопоставление

Обработка — это процесс заказа единиц текстовой информации. Сопоставление обычно зависит от конкретного языка или даже от конкретного приложения или локали. Иногда его называют алфавитизацией, хотя алфавитизация — это особый случай сортировки и сортировки. <UNICODE>

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

Относительные порядки букв в последовательностях сопоставления могут широко различаться в зависимости от потребностей системы или протокола, определяющего порядок сопоставления. Например, даже в символах ASCII существует два общих и очень разных порядка сопоставления: «A, a, B, b, …» и «A, B, C, …, Z, a, b ,. .. «, с дополнительными вариациями для строчных букв вначале и цифр до и после букв.

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

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

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

Многие процессы должны упорядочивать строки в последовательной (отсортированной) последовательности. Только для нескольких комбинаций CCS / CES существует очевидный порядок сортировки, который можно применять без ссылки на лингвистическое значение символов: для сортировки достаточно порядка кодовых точек. То есть порядок кодовых точек также является порядком, который человек будет использовать при сортировке символов. Для многих комбинаций CCS / CES порядок кодовых точек не имеет смысла для человека и, следовательно, бесполезен для сортировки, если результаты будут отображаться для человека.

Порядок кодовых точек обычно не такой, как любой человек, получивший образование в местной школьной системе, ожидает увидеть упорядоченные строки; если кто-то подчиняется ожиданиям человека, у него есть «языковой» или «человеческий язык». Сортировка по порядку кодовой точки может показаться непоследовательной, если строки не нормализованы перед сортировкой, потому что разные представления одного и того же символа будут сортироваться по-разному. Эта проблема может быть меньше в зависимости от языка.

code table — таблица кодов

Кодовая таблица — это таблица, показывающая символы, выделенные октетам в коде. <ISOIEC10646>

Кодовые таблицы также обычно называют «кодовыми символами».

 

4.1. Типы символов

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

alphabetic — буквенный

Информативное свойство Unicode. Символы, которые являются основными единицами алфавитов и / или слогов, как комбинирующих, так и не комбинируемых. Сюда входят составные символы, которые являются каноническими эквивалентами последовательности символов объединения буквенного базового символа плюс один или несколько символов объединения: буквенные орграфы; контекстные варианты буквенных знаков; лигатуры буквенных знаков; контекстные варианты лигатур; буквы-модификаторы; буквенные символы, которые являются эквивалентами совместимости отдельных букв алфавита; и разные элементы письма. <UNICODE>

ideographic — идеографический

Любой символ, который в первую очередь обозначает идею (или значение) в отличие от звука (или произношения), например, символ, показывающий телефон или символы Хань, используемые в китайском, японском и корейском языках. <UNICODE>

В то время как Unicode и многие другие системы используют этот термин для обозначения всех символов Han, строго говоря, не все эти символы на самом деле являются идеографическими. Некоторые из них являются пиктографическими (например, телефонный пример выше), некоторые используются фонетически, и так далее. Тем не менее, соглашение состоит в том, чтобы описать сценарий как идеографический, а не алфавитный.

digit or number — цифра или номер

Все современные системы письма используют десятичные цифры в той или иной форме; некоторые старые используют непозиционные или другие системы. Разные скрипты могут иметь свои собственные цифры. Юникод различает числа и другие виды символов, присваивая им специальное значение общей категории и подразделяя это значение, чтобы различать десятичные, буквенные и другие цифры. <UNICODE>

punctuation — пунктуация

Символы, которые разделяют единицы текста, такие как предложения и фразы, таким образом проясняя смысл текста. Использование знаков препинания не ограничивается прозой; например, они также используются в математических и научных формулах. <UNICODE>

symbol — условное обозначение

Один из набора символов, отличных от тех, которые используются для букв, цифр или знаков препинания, и представляющих различные понятия, обычно не связанные с использованием письменного языка как такового. <RFC6365>

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

nonspacing character — непроходной символ

Комбинирующий символ, расположение которого в презентации зависит от его базового символа. Как правило, он не занимает пространство вдоль визуальной базовой линии само по себе. <UNICODE>

Комбинированный острый акцент (U + 0301) является примером непространственного символа.

diacritic — диакритика

Метка, примененная или прикрепленная к символу, для создания нового символа, представляющего измененное или новое значение. Они также могут быть метками, примененными к символу, независимо от того, изменяют ли они значение этого символа. В последнем случае диакритический знак обычно представляет собой независимое значение (например, ударение, тон или некоторую другую лингвистическую информацию). Также называется диакритическим знаком или диакритическим знаком. <UNICODE>

control character — управляющий символ

65 символов в диапазонах U + 0000..U + 001F и U + 007F..U + 009F. Базовый пробел, U + 0020, также часто рассматривается как управляющий символ, что дает общее число 66. Они также известны как управляющие коды. В терминологии, принятой Unicode из стандартов ASCII и ISO 8859, эти коды рассматриваются как принадлежащие к трем диапазонам: «C0» (для U + 0000..U + 001F), «C1» (для U + 0080 … U + 009F) и один управляющий символ «DEL» (U + 007F). <UNICODE>

Иногда в других словарях термин «контрольный символ» используется для описания любого символа, который обычно не имеет ассоциированного символа; он также иногда используется для последовательностей управления устройством [ISO6429]. Ни один из этих способов не подходит для терминологии интернационализации в IETF.

formatting character — форматирование символа

Символы, которые по своей природе невидимы, но влияют на окружающие символы. <UNICODE>

Примеры символов форматирования включают символы для указания направления текста и символы, которые определяют способ объединения нескольких символов.

compatibility character or compatibility variant — символ совместимости или вариант совместимости

Графический символ, включенный в качестве кодированного символа ISO / IEC 10646, главным образом для совместимости с существующими наборами кодированных символов. <ISOIEC10646)>

Определение совместимости Unicode также включает символы, которые были включены по другим причинам. Их список включает несколько отдельных групп символов, включенных в целях совместимости: символы половинной и полной ширины, используемые в восточноазиатских сценариях, арабские контекстные формы (например, начальные или конечные формы), некоторые лигатуры, устаревшие символы форматирования, варианты форм символов (или даже копии) из них) для конкретных целей (например, фонетических или математических приложений), вариантов шрифтов, идеограмм совместимости CJK и т. д. Для получения дополнительной информации и отдельного термина «разложимый символ совместимости» см. Стандарт Unicode.

Например, U + FF01 (FULLWIDTH EXCLAMATION MARK) был включен для совместимости с азиатскими кодировками, которые включают символы ASCII полной ширины и полуширины.

Некоторые усилия в IETF пришли к выводу, что было бы полезно поддерживать отображение некоторых групп эквивалентов совместимости, а не других (например, поддержку или отображение изменений ширины при сохранении или отклонении математических изменений). См. Документ сопоставления IDNA [RFC5895] для одного примера.

4.2. Дифференциация подмножеств

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

Несмотря на то, что определенные коллекции определены, важно помнить, что, хотя более старые CCS, такие как ASCII и семейство ISO 8859, являются закрытыми и фиксированными, Unicode является открытым, с новыми определениями символов и часто новыми сценариями, добавляемыми каждый раз. год или около того. Таким образом, хотя, например, подмножество ASCII, такое как «заглавные буквы», может быть задано как диапазон кодовых точек (от 4/1 до 5/10 для этого примера), аналогичные определения для Unicode либо должны быть указаны в терминах свойств Unicode или очень зависят от версий Unicode (и соответствующая версия должна быть указана в любой спецификации). См. Спецификацию кодовой точки IDNA [RFC5892] для примера спецификации комбинациями свойств.

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

non-ASCII — не-ASCII

Термин «не ASCII» строго относится к символам, отличным от тех, которые появляются в репертуаре ASCII, независимо от CCS или используемой для них кодировки. На практике, если репертуар, такой как Unicode, установлен как контекст, «не-ASCII» относится к символам в этом репертуаре, которые не появляются в репертуаре ASCII. «За пределами репертуара ASCII» и «вне диапазона ASCII» являются практическими и более точными синонимами для «не-ASCII».

letters — буквы

Термин «буквы» не имеет точного эквивалента в стандарте Unicode. Буквы, как правило, символы, которые используются для написания слов, но это означает, что в разных языках и культурах это очень разные вещи.

 

5. Пользовательский интерфейс для текста

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

input methods — методы ввода

Метод ввода — это механизм, позволяющий человеку вводить текст в приложение. <RFC6365>

Текст можно вводить в компьютер разными способами. Клавиатуры, безусловно, являются наиболее распространенным используемым устройством, но многие символы не могут быть введены на типичных компьютерных клавиатурах за один ход. Многие операционные системы поставляются с системным программным обеспечением, которое позволяет пользователям вводить символы вне диапазона, разрешенного клавиатурой.

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

Термин «редактор метода ввода» (IME) часто используется для описания инструментов и программного обеспечения, используемых для ввода символов в конкретной системе.

rendering rules — правила рендеринга

Правило рендеринга — это алгоритм, который система использует для определения способа отображения строки текста. <RFC6365>

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

Некоторые примеры этих правил рендеринга включают в себя:

• Скрипты, такие как арабский (и многие другие), где форма буквы изменяется в зависимости от соседних букв, независимо от того, стоит ли буква отдельно, в начале слова, в середине слова или в конце слово. Правила рендеринга должны выбирать между двумя или более глифами.
• Скрипты, такие как индийские, где согласные могут менять свою форму, если они соседствуют с некоторыми другими согласными, или могут отображаться в порядке, отличном от того, как они хранятся и произносятся. Правила рендеринга должны выбирать между двумя или более глифами.
• Арабские и ивритские скрипты, где порядок отображаемых символов изменяется двунаправленными свойствами букв и других символов, а также с метками справа налево и слева направо. Правила рендеринга должны выбирать порядок отображения символов.
• Некоторые системы записи не могут определять свои правила рендеринга надлежащим образом, используя механизмы, которые теперь определены в Стандарте Юникод. Ни один из этих языков не используется в настоящее время без научного подхода.
• Многие системы используют специальное правило рендеринга, когда у них нет шрифта или другого механизма для правильного рендеринга конкретного символа. Это правило обычно включает замену небольшого открытого поля или вопросительного знака на отсутствующий символ. Смотрите «неотображаемый символ» ниже.

graphic symbol — графический символ

Графический символ — это визуальное представление графического символа или составной последовательности. <ISOIEC10646>

font — шрифт

Шрифт — это коллекция глифов, используемых для визуального отображения символьных данных. Шрифт часто ассоциируется с набором параметров (например, размер, положение, вес и степень засечек), который при задании определенных значений генерирует коллекцию изобразимых глифов. <UNICODE>

Термин «шрифт» часто используется взаимозаменяемо с «гарнитурой». Как исторически использовалось в типографии, гарнитура — это семейство одного или нескольких шрифтов, которые имеют общий общий дизайн. Например, «Times Roman» на самом деле является шрифтом с набором шрифтов, таких как «Times Roman Bold», «Times Roman Medium», «Times Roman Italic» и так далее. В некоторых источниках даже разные размеры шрифта внутри гарнитуры являются разными шрифтами. Хотя эти различия редко важны для целей интернационализации, существуют исключения. Те, кто пишет спецификации, должны быть очень осторожны с определениями в тех случаях, когда исключения могут привести к неоднозначности.

bidirectional display — двунаправленный дисплей

Процесс или результат смешивания текста, ориентированного слева направо и текста, ориентированного справа налево, в одну строку называется двунаправленным отображением, часто сокращенно обозначается как «двунаправленный». <UNICODE>

Большинство письменных языков мира отображаются слева направо. Однако многие широко используемые письменные языки, например, основанные на иврите или арабском языке, отображаются в основном справа налево (цифры являются распространенным исключением в современных сценариях). Текст справа налево часто вводит в заблуждение создателей протоколов, потому что они должны продолжать думать в терминах порядка символов в строке в памяти, порядок, который может отличаться от того, что они видят на экране. (Обратите внимание, что некоторые языки написаны как по горизонтали, так и по вертикали, а некоторые исторические используют другие порядки отображения.)

Кроме того, двунаправленный текст может вызвать путаницу, потому что в ISO / IEC 10646 есть символы форматирования, которые вызывают изменение порядка отображения текста. Эти явные символы форматирования изменяют отображение независимо от неявных свойств символов слева направо или справа налево. Текст, который может содержать эти символы, обычно требует тщательной обработки перед сортировкой или сравнением на равенство.

Обычно встречаются строки с текстом в обоих направлениях, например строки, содержащие как текст, так и числа, или строки, содержащие смесь сценариев.
Unicode имеет длинный и невероятно подробный алгоритм отображения двунаправленного текста [UAX9].

undisplayable character — недисплейный символ

Символ, который не имеет отображаемой формы. <RFC6365>

Например, пространство нулевой ширины (U + 200B) не может быть отображено, потому что оно не занимает горизонтальное пространство. Символы форматирования, например, для задания направления текста, также не отображаются. Однако обратите внимание, что каждый символ в [UNICODE] имеет связанный с ним глиф, и что глифы для неиграемых символов заключены в пунктирный квадрат в качестве указания на то, что фактический символ не отображается.

Свойство персонажа, которое делает его недоступным для воспроизведения, является неотъемлемой частью его определения. Нераспознаваемые символы никогда не могут отображаться в обычном тексте (пунктирная квадратная запись используется только в особых случаях). Печатные символы, чьи определения Unicode связаны с глифами, которые нельзя отобразить в конкретной системе, в этом смысле не отображаются.

writing style — стиль письма

Условные обозначения написания одного и того же сценария в разных стилях. <RFC6365>

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

 

6. Текст в текущих протоколах IETF

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

protocol elements — элементы протокола

Элементы протокола — это части протокола с уникальными именами. <RFC6365>

Почти каждый протокол имеет именованные элементы, такие как «порт источника» в TCP. В некоторых протоколах имена элементов (или текстовые токены для имен) передаются внутри протокола. Например, в SMTP и многих других протоколах IETF имена глаголов являются частью потока команд. Таким образом, имена являются частью стандарта протокола. Имена элементов протокола обычно не видны конечным пользователям, и редко бывает целесообразно интернационализировать имена элементов протокола (даже если сами элементы могут быть интернационализированы).

name spaces — пространства имен

Пространство имен — это набор допустимых имен для определенного элемента или синтаксические правила для генерации этих допустимых имен. <RFC6365>

Многие элементы в интернет-протоколах используют имена для идентификации конкретных экземпляров или значений. Имена могут быть сгенерированы (по некоторым предписанным правилам), зарегистрированы централизованно (например, например, в IANA) или иметь распределенный механизм регистрации и управления, такой как имена в DNS.

on-the-wire encoding — кодирование по проводам

Кодирование и декодирование, используемые до и после передачи по сети, часто называют «проводным» (или иногда просто «проводным») форматом. <RFC6365>

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

parsed text — проанализированный текст

Текстовые строки, которые были проанализированы на части. <RFC6365>

В некоторых протоколах свободный текст в текстовых полях может быть проанализирован. Например, многие почтовые пользовательские агенты (MUA) будут анализировать слова в тексте поля Subject:, чтобы попытаться создать поток, основываясь на том, что появляется после префикса «Re:».

Такие соглашения очень чувствительны к локализации. Если, например, MUA изменяет форму, такую как «Re:», чтобы отразить язык отправителя или получателя, система, которая впоследствии выполняет многопоточность, может не распознать заменяющий термин как строку-разделитель.

charset identification — идентификация кодировки

Спецификация кодировки, используемой для строки текста. <RFC6365>

Протоколы, которые позволяют использовать более одной кодировки в одном и том же месте, должны требовать идентификации текста с соответствующей кодировкой. Без этой идентификации программа, смотрящая на текст, не сможет окончательно распознать кодировку текста. Идентификация кодировки также называется «маркировка кодировки».

language identification — идентификация языка

Спецификация человеческого языка, используемого для текстовой строки. <RFC6365>

Некоторые протоколы (такие как MIME и HTTP) позволяют идентифицировать текст, предназначенный для машинной обработки, с помощью языка, используемого в тексте. Такая идентификация важна для машинной обработки текста, например, в системах, которые воспроизводят текст, произнося его. Идентификация языка также называется «маркировка языка». Стандарты IETF «LTRU» [RFC5646] и [RFC4647] предоставляют всеобъемлющую модель для идентификации языка.

MIME

MIME (Multipurpose Internet Mail Extensions) — это формат сообщений, который допускает текстовые сообщения и заголовки в наборах символов, отличных от US-ASCII, в форматах, требующих ASCII (в частности, RFC 5322, стандарт для заголовков почты в Интернете [RFC5322]). MIME описывается в RFC с 2045 по 2049, а также в более поздних RFC. <RFC6365>

transfer encoding syntax — синтаксис передачи кодирования

Синтаксис кодирования передачи (TES) (иногда называемый схемой кодирования передачи) представляет собой обратимое преобразование уже закодированных данных, которое представлено в одной или нескольких схемах кодирования символов. <RFC6365>

TES полезны для кодирования типов символьных данных в другом формате, обычно для передачи новых типов данных по устаревшим протоколам. Основные примеры TES, используемых в IETF, включают Base64 и quoted-printable. MIME идентифицирует синтаксис кодирования передачи для частей тела как кодирование передачи содержимого, иногда сокращенно обозначаемое как C-T-E.

Base64

Base64 — это синтаксис кодирования передачи, который позволяет представлять двоичные данные символами ASCII от A до Z, от a до z, от 0 до 9, +, / и =. Это определено в [RFC2045]. <RFC6365>

quoted printable — цитируемый для печати

Печать в кавычках — это синтаксис кодировки передачи, который позволяет читателям читать строки, содержащие не-ASCII-символы, в основном с печатными символами ASCII. Это описано в [RFC2047]. <RFC6365>

Цитируемый печатный синтаксис обычно считается ошибкой при чтении. Это в шутку называют «цитируемым нечитаемым».

XML

XML (который является приблизительным сокращением для Extensible Markup Language) является популярным методом структурирования текста. Текст XML, который не закодирован как UTF-8, явно помечен кодировками, а весь текст в XML состоит только из символов Unicode. Спецификацию для XML можно найти по адресу <http://www.w3.org/XML/>. <RFC6365>

ASN.1 text formats — Текстовые форматы ASN.1

Язык описания данных ASN.1 имеет много форматов для текстовых данных. Форматы допускают разные репертуары и разные кодировки. Некоторые из форматов, которые появляются в стандартах IETF на основе ASN.1, включают IA5String (все символы ASCII), PrintableString (большинство символов ASCII, но пропускают много знаков препинания), BMPString (символы из плоскости 0 ИСО / МЭК 10646 в формате UTF-16BE ), UTF8String (как и следует из названия) и TeletexString (также называемый T61String).

ASCII-compatible encoding (ACE) — ASCII-совместимое кодирование (ACE)

Начиная с 1996 года, многие ASCII-совместимые схемы кодирования (которые фактически являются синтаксисами кодирования передачи) были предложены в качестве возможных решений для интернационализации имен хостов и некоторых других целей. Их цель состоит в том, чтобы иметь возможность кодировать любую строку символов ISO / IEC 10646, используя предпочтительный синтаксис для доменных имен (как описано в STD 13). На момент написания этой статьи только ACE, произведенный Punycode [RFC3492], стал стандартом IETF.

Выбор форм ACE для интернационализации устаревших протоколов должен быть сделан с осторожностью, поскольку это может вызвать некоторые сложные побочные эффекты [RFC6055].

LDH label — Лейбл LDH

Классическая форма метки, используемая в DNS и большинстве приложений, которые ее вызывают, хотя и с некоторыми дополнительными ограничениями, отражает ранний синтаксис «имен хостов» [RFC0952] и ограничивает эти имена буквами ASCII, цифрами и встроенными дефисами. Синтаксис имени хоста идентичен синтаксису, описанному как «предпочтительный синтаксис имени» в Разделе 3.5 RFC 1034 [RFC1034] с изменениями в RFC 1123 [RFC1123]. Метки LDH определены более ограниченным и точным способом для контекстов интернационализации как часть спецификации IDNA2008 [RFC5890].

 

7. Термины, связанные с интернационализированными доменными именами

7.1. Терминология IDNA

Текущая спецификация для интернационализированных доменных имен (IDN), формально известная как интернационализированные доменные имена для приложений или IDNA, упоминается в IETF и частях более широкого сообщества как «IDNA2008» и состоит из нескольких документов. Раздел 2.3 первого из этих документов, обычно известный как «Определения IDNA2008» [RFC5890], содержит определения и вводит некоторые специальные термины для различения типов меток DNS в контексте IDN. Эти термины перечислены в таблице ниже; см. RFC 5890 для конкретных определений, если это необходимо.

• ACE Prefix
• A-label
• Domain Name Slot
• IDNA-valid string
• Internationalized Domain Name (IDN)
• Internationalized Label
• LDH Label
• Non-Reserved LDH label (NR-LDH label)
• U-label

Два дополнительных термина вошли в словарь IETF как часть более ранней работы по IDN [RFC3490] (IDNA2003):

Stringprep

Stringprep [RFC3454] предоставляет модель и таблицы символов для подготовки и обработки интернационализированных строк. Он использовался в оригинальной спецификации IDN (IDNA2003) через профиль под названием «Nameprep» [RFC3491]. Он больше не используется в IDNA, но продолжает использоваться в профилях рядом с другими протоколами. <RFC6365>

Punycode

Это имя алгоритма [RFC3492], используемого для преобразования допустимых в противном случае меток IDN из строк собственных символов, выраженных в Unicode, в ASCII-совместимую кодировку (ACE). Строго говоря, термин относится только к алгоритму. На практике он широко, если ошибочно, используется для ссылки на строки, которые кодирует алгоритм.

7.2. Отношения персонажей и варианты

Термин «вариант» был введен в словарь IETF i18n с рекомендациями JET [RFC3743]. В том смысле, в котором он здесь используется, речь идет строго о связи между символами традиционного китайского языка и их упрощенными эквивалентами. Рекомендации JET предоставили модель для идентификации этих пар символов и меток, которые их использовали. Конкретные рекомендации по обработке вариантов для китайского языка были представлены в последующем документе [RFC4713].

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

• «визуально похожие» или «визуально смешные» символы. Они могут быть ограничены символами в разных сценариях, символами в одном сценарии или обоими, и они могут быть одинаковыми, даже если используются эталонные шрифты с высокой степенью различимости или при различных обстоятельствах, которые могут включать злонамеренный выбор шрифтов или другие способы обмануть восприятие пользователя. Тривиальные примеры включают ASCII «l» и «1» и латинскую и кириллическую «a».
• Символам присваивается более одной кодовой точки Unicode из-за какого-то специального свойства. Эти символы могут считаться «одинаковыми» для одних целей и отличаться для других (или других пользователей). Одним из наиболее часто цитируемых примеров является арабская YEH, которая кодируется более одного раза, потому что некоторые ее формы различаются в разных языках. Другим примером являются греческая строчная сигма и последняя сигма: если последние рассматривались исключительно как вариант позиционного представления первого, ей не следовало назначать отдельную кодовую точку.
• Цифры и этикетки, включая их. В отличие от букв, «значение» десятичных цифр ясно и недвусмысленно независимо от того, с каким алфавитом они связаны. Некоторые сценарии обычно используются почти взаимозаменяемо с европейскими цифрами и цифрами, родными для этого сценария. Арабский алфавит состоит из двух наборов цифр (U + 0660..U + 0669 и U + 06F0..U = 06F9), написанных одинаково для нуля через три и с семи по девять, но по-разному для четырех-шести; Европейские цифры преобладают в других областях. Замена цифр одинаковыми числовыми значениями в метках может привести к другому типу варианта.
• Орфографические различия в языке. Многие языки имеют альтернативные варианты написания или написания, которые различаются в зависимости от региона. Пользователи этих языков обычно распознают орфографию как эквивалентную, по крайней мере, в той же степени, что и варианты, описанные выше. Примеры включают «color» и «color» в английском языке, немецкие слова, написанные с помощью o-umlaut или «oe», и так далее. Некоторые из этих отношений могут также создавать другие типы воспринимаемых отличий от языка, которые не существуют для других языков, использующих тот же сценарий. Например, в арабском языке в конце слова ARABIC LETTER TEH MARBUTA (U + 0629) и ARABIC LETTER HEH (U + 0647) имеют разную форму (одна имеет 2 точки сверху), но они используются взаимозаменяемо в письменном виде: они «звучат» одинаково, когда произносятся в конце фразы, и, следовательно, ПИСЬМО МАРБУТА иногда пишется как ПИСЬМО ХЕ, и в этом контексте они считаются «смешанными».

Термин «вариант», используемый в этом разделе, также не следует путать с другими использованиями термина в этом документе или в терминологии Unicode (например, в разделе 4.1 выше). Если термин должен использоваться вообще, контекст должен четко различать эти разные варианты использования и, в частности, между вариантами символов и вариантами меток. Локальный текст должен указывать, какое значение или комбинация значений предназначены.

 

8. Другие общие термины в интернационализации

Это мешанина других терминов, которые появились в дискуссиях по интернационализации в IETF.

locale — место действия

Локаль — это пользовательское местоположение и культурная информация, управляемая компьютером. <RFC6365>

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

Проблемы локали выходят за рамки использования символов и могут включать такие вещи, как формат отображения валюты, даты и времени. Некоторые локали (особенно популярные локали «C» и «POSIX») не включают информацию о языке.

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

Latin characters — Латинские символы

«Латинские символы» — неточный термин для символов, исторически связанных с древнегреческим шрифтом, которые были изменены в Римской Республике и Империи и в настоящее время используются во всем мире. <RFC6365>

Базовые латинские символы являются подмножеством репертуара ASCII и были дополнены множеством диакритических знаков и множественных символов, а также множеством других символов. ISO / IEC 10646 кодирует латинские символы, включая диапазоны U + 0020..U + 024F и U + 1E00..U + 1EFF.

Поскольку «латинские символы» используются в разных контекстах для обозначения букв из репертуара ASCII, подмножества этих символов, использовавшихся в конце периода Римской Республики, или другого подмножества, использованного для написания латинского в средневековые времена, весь репертуар ASCII, Во всех кодовых точках в расширенном латинском скрипте, как определено Unicode, и в других коллекциях, следует избегать использования этого термина в спецификациях IETF, если это возможно. Точно так же «Базовая латиница» не должна использоваться как синоним «ASCII».

Romanization — Романизация

Транслитерация нелатинского алфавита в латинские буквы. <RFC6365>

Из-за их широкого использования латинские символы (или построенные из них графемы) часто используются, чтобы пытаться писать текст на языках, в которых ранее не было систем письменности или чьи системы письма изначально были основаны на различных сценариях. Например, есть две популярные латинизации китайцев: Wade-Giles и Pinyin, последняя из которых гораздо более распространена сегодня. Многие системы латинизации неточны и не дают идеальных сопоставлений между нативным шрифтом и латинскими буквами.

CJK characters and Han characters — Символы CJK и символы Хань

Идеографические символы, используемые в китайских, японских, корейских и традиционных вьетнамских системах письма, часто называют «символами CJK» после начальных букв названий языков на английском языке. Они также называются «иероглифы хань», после термина на китайском языке, который часто используется для этих символов. <RFC6365>

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

В ИСО / МЭК 10646 символы Хань были «унифицированными», что означает, что каждому набору символов Хань из японского, китайского и / или корейского языков, имеющих одинаковое происхождение, была назначена одна кодовая точка. Положительным результатом этого было то, что для представления Хана требовалось гораздо меньше кодовых точек; отрицательный результат этого состоял в том, что символы, которые люди, пишущие на трех языках, считают разными, имеют одинаковую кодовую точку. Существует много разногласий по поводу природы, происхождения и серьезности проблем, вызванных объединением Хань.

translation — перевод

Процесс передачи значения некоторого отрывка текста на одном языке, чтобы его можно было эквивалентно выразить на другом языке. <RFC6365>

Многие системы языкового перевода являются неточными и не могут применяться повторно для перехода с одного языка на другой.

transliteration — транслитерация

Процесс представления символов алфавитной или слоговой системы письма символами алфавита преобразования. <RFC6365>

Многие транскрипции сценариев являются точными, и многие имеют совершенные сопоставления в обоих направлениях. Заметным исключением является романизация, описанная выше. Транслитерация включает в себя преобразование текста, выраженного одним сценарием, в другой сценарий, как правило, по буквам. Существует много официальных и неофициальных стандартов транслитерации, в частности, стандартов ИСО ТК 46 и Библиотеки Конгресса США.

transcription — транскрипция

Процесс систематического написания звуков некоторого отрывка разговорного языка, как правило, с использованием технического фонетического алфавита (обычно на основе латинского алфавита) или другой систематической транскрипционной орфографии. Транскрипция также иногда относится к преобразованию письменного текста в транскрибированную форму, основанную на звучании текста, как если бы оно было произнесено. <RFC6365>

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

regular expressions — регулярные выражения

Регулярные выражения предоставляют механизм для выбора определенных строк из набора символьных строк. Регулярные выражения — это язык, используемый для поиска текста в строках и, возможно, для изменения текста, найденного с помощью другого текста. <RFC6365>

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

Консорциум Unicode хорошо обсудил, как адаптировать механизмы регулярных выражений для использования Unicode. [UTR18]

private use character — личное использование символов

Кодовые точки ISO / IEC 10646 от U + E000 до U + F8FF, U + F0000 до U + FFFFD и U + 100000 до U + 10FFFD доступны для частного использования. Это относится к кодовым пунктам стандарта, интерпретация которых не определена стандартом и использование которых может определяться частным соглашением между сотрудничающими пользователями. <UNICODE>

Использование этих символов «личного пользования» определяется сторонами, которые их передают и получают, и поэтому не подходит для стандартизации. (IETF имеет долгую историю имен частных пользователей для таких вещей, как имена «x-» в MIME-типах, наборах символов и языках. Большая часть опыта работы с ними была довольно негативной, поскольку многие разработчики предполагают, что имена частных пользователей находятся в Факт публичный и долгоживущий.)

 

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

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

При этом другие RFC, имеющие дело с интернационализацией, имеют описания соображений безопасности, которые могут быть полезны для читателя этого документа. В частности, соображения безопасности в RFC 3454, RFC 3629, RFC 4013 [RFC4013] и RFC 5890 подробно изложены.

10. Ссылки

10.1. Нормативные ссылки

[ISOIEC10646] ISO/IEC, «ISO/IEC 10646:2011. International Standard — Information technology — Universal Multiple-Octet Coded Character Set (UCS)», 2011.

[RFC2047] Moore, K., «MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text», RFC 2047, November 1996.

[UNICODE] The Unicode Consortium, «The Unicode Standard, Version 6.0», (Mountain View, CA: The Unicode Consortium, 2011. ISBN 978-1-936213-01-6).
<http://www.unicode.org/versions/Unicode6.0.0/>.

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

[CHARMOD] W3C, «Character Model for the World Wide Web 1.0», 2005, <http://www.w3.org/TR/charmod/>.

[FRAMEWORK] ISO/IEC, «ISO/IEC TR 11017:1997(E). Information technology — Framework for internationalization, prepared by ISO/IEC JTC 1/SC 22/WG 20», 1997.

[ISO3166] ISO, «ISO 3166-1:2006 — Codes for the representation of names of countries and their subdivisions — Part 1: Country codes», 2006.

[ISO639] ISO, «ISO 639-1:2002 — Code for the representation of names of languages — Part 1: Alpha-2 code», 2002.

[ISO6429] ISO/IEC, «ISO/IEC, «ISO/IEC 6429:1992. Information technology — Control functions for coded character sets»», ISO/IEC 6429:1992, 1992.

[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, «DoD Internet host table specification», RFC 952, October 1985.

[RFC1034] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, November 1987.

[RFC1123] Braden, R., «Requirements for Internet Hosts — Application and Support», STD 3, RFC 1123, October 1989.

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

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

[RFC2277] Alvestrand, H., «IETF Policy on Character Sets and Languages», BCP 18, RFC 2277, January 1998.

[RFC2781] Hoffman, P. and F. Yergeau, «UTF-16, an encoding of ISO 10646», RFC 2781, February 2000.

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

[RFC3454] Hoffman, P. and M. Blanchet, «Preparation of Internationalized Strings («stringprep»)», RFC 3454, December 2002.

[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, «Internationalizing Domain Names in Applications (IDNA)», RFC 3490, March 2003.

[RFC3491] Hoffman, P. and M. Blanchet, «Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)», RFC 3491, March 2003.

[RFC3492] Costello, A., «Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)», RFC 3492, March 2003.

[RFC3629] Yergeau, F., «UTF-8, a transformation format of ISO 10646», STD 63, RFC 3629, November 2003.

[RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, «Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean», RFC 3743, April 2004.

[RFC4013] Zeilenga, K., «SASLprep: Stringprep Profile for User Names and Passwords», RFC 4013, February 2005.

[RFC4647] Phillips, A. and M. Davis, «Matching of Language Tags», BCP 47, RFC 4647, September 2006.

[RFC4713] Lee, X., Mao, W., Chen, E., Hsu, N., and J. Klensin, «Registration and Administration Recommendations for Chinese Domain Names», RFC 4713, October 2006.

[RFC5137] Klensin, J., «ASCII Escaping of Unicode Characters», BCP 137, RFC 5137, February 2008.

[RFC5198] Klensin, J. and M. Padlipsky, «Unicode Format for Network Interchange», RFC 5198, March 2008.

[RFC5322] Resnick, P., Ed., «Internet Message Format», RFC 5322, October 2008.

[RFC5646] Phillips, A. and M. Davis, «Tags for Identifying Languages», BCP 47, RFC 5646, September 2009.

[RFC5890] Klensin, J., «Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework», RFC 5890, August 2010.

[RFC5892] Faltstrom, P., «The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)», RFC 5892, August 2010.

[RFC5895] Resnick, P. and P. Hoffman, «Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008», RFC 5895, September 2010.

[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, «IAB Thoughts on Encodings for Internationalized Domain Names», RFC 6055, February 2011.

[UAX34] The Unicode Consortium, «Unicode Standard Annex #34: Unicode Named Character Sequences», 2010, <http://www.unicode.org/reports/tr34>.

[UAX9] The Unicode Consortium, «Unicode Standard Annex #9: Unicode Bidirectional Algorithm», 2010, <http://www.unicode.org/reports/tr9>.

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

[UTN6] The Unicode Consortium, «Unicode Technical Note #5: BOCU-1: MIME-Compatible Unicode Compression», 2006, <http://www.unicode.org/notes/tn6/>.

[UTR15] The Unicode Consortium, «Unicode Standard Annex #15: Unicode Normalization Forms», 2010, <http://www.unicode.org/reports/tr15>.

[UTR18] The Unicode Consortium, «Unicode Standard Annex #18: Unicode Regular Expressions», 2008, <http://www.unicode.org/reports/tr18>.

[UTR22] The Unicode Consortium, «Unicode Technical Standard #22: Unicode Character Mapping Markup Language», 2009, <http://www.unicode.org/reports/tr22>.

[UTR6] The Unicode Consortium, «Unicode Technical Standard #6: A Standard Compression Scheme for Unicode», 2005, <http://www.unicode.org/reports/tr6>.

[W3C-i18n-Def] W3C, «Localization vs. Internationalization», September 2010, <http://www.w3.org/International/questions/qa-i18n.en>.

Приложение А. Дополнительное интересное чтение

Barry, Randall, ed. ALA-LC Romanization Tables. Washington: U.S. Library of Congress, 1997. ISBN 0844409405

Coulmas, Florian. Blackwell Encyclopedia of Writing Systems. Oxford: Blackwell Publishers, 1999. ISBN 063121481X

Dalby, Andrew. Dictionary of Languages: The Definitive Reference to More than 400 Languages. New York: Columbia University Press, 2004. ISBN 978-0231115698

Daniels, Peter, and William Bright. The World’s Writing Systems. New York: Oxford University Press, 1996. ISBN 0195079930

DeFrancis, John. The Chinese Language: Fact and Fantasy. Honolulu: University of Hawaii Press, 1984. ISBN 0-8284-085505 and 0-8248-1058-6

Drucker, Joanna. The Alphabetic Labyrinth: The Letters in History and Imagination. London: Thames & Hudson, 1995. ISBN 0-500-28068-1

Fazzioli, Edoardo. Chinese Calligraphy. New York: Abbeville Press, 1986, 1987 (English translation). ISBN 0-89659-774-1

Hooker, J.T., et al. Reading the Past: Ancient Writing from Cuneiform to the Alphabet. London: British Museum Press, 1990. ISBN 0-7141-8077-7

Lunde, Ken. CJKV Information Processing. Sebastopol, CA: O’Reilly & Assoc., 1999. ISBN 1-56592-224-7

Nakanishi, Akira. Writing Systems of the World. Rutland, VT: Charles E. Tuttle Company, 1980. ISBN 0804816549

Robinson, Andrew. The Story of Writing: Alphabets, Hieroglyphs, & Pictograms. London: Thames & Hudson, 1995, 2000. ISBN 0-500-28156-4

Sacks, David. Language Visible. New York: Broadway Books (a division of Random House, Inc.), 2003. ISBN 0-7679-1172-5

Приложение Б. Благодарности

Определения в этом документе взяты из многих источников, включая широкий спектр документов IETF.

Джеймс Сенг внес свой вклад в первоначальный набросок RFC 3536. Харальд Альвестранд и Мартин Дуерст сделали обширные полезные комментарии к ранним версиям. Среди других, кто внес вклад в разработку RFC 3536, — Дэн Кон, Якоб Пальме, Йохан ван Винген, Питер Констебл, Юрий Демченко, Сьюзан Харрис, Зита Венцель, Джон Кленсин, Хеннинг Шульцринн, Лесли Дейгл, Маркус Шерер и Кен Уистлер.

Абдулазиз Аль-Зоман, Тим Брей, Фрэнк Эллерманн, Антонио Марко, JFC Morphin, Сармад Хуссейн, Никита Евстифеев, Кен Уистлер и другие определили важные проблемы или внесли конкретные предложения в отношении этой новой версии.

Приложение C. Значительные изменения по сравнению с RFC 3536

Этот документ в основном состоит из дополнений к RFC 3536. Ниже приведен список наиболее значительных изменений.

• Изменен статус документа на BCP.
• Обычно используемые синонимы добавлены в несколько описаний и проиндексированы.
• Был добавлен список терминов, определенных и используемых в IDNA2008, с указателем на RFC 5890. Эти определения не повторялись в этом документе.
• Термин «вариант», который подвергается сильному злоупотреблению, теперь обсуждается довольно подробно.
• Обсуждение различных подмножеств репертуара Unicode было добавлено в Разделе 4.2 и включены соответствующие определения.
• Добавлен новый термин «стиль письма».
• Обсуждение сворачивания дела и составления карт было расширено.
• Незначительные правки были внесены в некоторые заголовки разделов, а также был внесен ряд других редакционных улучшений.
• Обсуждение контрольных кодов было обновлено, чтобы включить дополнительную информацию и уточнить, что «контрольный код» и «контрольный символ» являются синонимами.
• Многие термины были уточнены, чтобы отразить современное использование.
• Указатель терминов по разделам в RFC 3536 был заменен указателем на страницы, содержащие значительно больше терминов.
• Подтверждения были обновлены.
• Некоторые ссылки были обновлены.
• Дополнительный список чтения был несколько расширен.

Индекс

A

A-label 31
ACE 30, 31
ACE Prefix 31
alphabetic 20
ANSI 13
ASCII 15
ASCII-compatible encoding 30, 31
ASN.1 text formats 30

B

Base64 29
Basic Multilingual Plane 13
bidi 26
bidirectional display 26
BMP 13
BMPString 30
BOCU-1 14
BOM 14
byte order mark 14

C

C-T-E 29
case 18
CCS 7
CEN/ISSS 13
character 6
character encoding form 7
character encoding scheme 8
character repertoire 7
charset 8
charset identification 28
CJK characters 34
code chart 19
code point 16
code table 19
coded character 6

coded character set 7
collation 18
combining character 16
combining character sequence 16
compatibility character 22
compatibility variant 22
composite sequence 16
content-transfer-encoding 29
control character 21
control code 21
control sequence 22

D

decomposed character 16
diacritic 21
displaying and rendering text 10
Domain Name Slot 31

E

encoding forms 13

F

font 25
formatting character 22

G

glyph 7
glyph code 7
graphic symbol 25

H

Han characters 34

I

i18n 9
IA5String 30
ideographic 20
IDN 31
IDNA 31
IDNA-valid string 31
IDNA2003 31
IDNA2008 31
IME 24
input method editor 24
input methods 24
internationalization 8
Internationalized Domain Name 31
Internationalized Label 31

ISO 11
ISO 639 11
ISO 3166 11
ISO 8859 15
ISO TC 46 11

J

JIS 13
JTC 1 11

L

l10n 9
language 5
language identification 29
Latin characters 34
LDH Label 30
letters 23
Local and regional standards organizations 13
locale 33
localization 9

M

MIME 29
multilingual 10

N

name spaces 28
Nameprep 31
NFC 17
NFD 17
NFKC 17
NFKD 17
non-ASCII 23
nonspacing character 21
normalization 17
NR-LDH label 31
NVT 15

O

on-the-wire encoding 28

P

parsed text 28
precomposed character 16
PrintableString 30
private use charater 36
protocol elements 27
punctuation 21
Punycode 30, 31

Q

quoted-printable 29

R

regular expressions 36
rendering rules 24
repertoire 7
romanization 34

S

SAC 13
script 5
SCSU 14
sorting 18
Stringprep 31
surrogate pair 14
symbol 21

T

T61String 30
TeletexString 30
TES 29
transcoding 7
transcription 35
transfer encoding syntax 29
transformation formats 13
translation 35
transliteration 34, 35
typeface 25

U

U-label 31
UCS-2 13
UCS-4 13
undisplayable character 26
Unicode Consortium 12
US-ASCII 15
UTC 12
UTF-8 14

UTF-16 14
UTF-16BE 14
UTF-16LE 14
UTF-32 14
UTF8String 30

V

variant 32

W

W3C 13
World Wide Web Consortium 13
writing style 27
writing system 6

X

XML 13, 30

Адрес автора

Paul Hoffman
VPN Consortium

EMail: paul.hoffman@vpnc.org

John C Klensin
1770 Massachusetts Ave, Ste 322
Cambridge, MA 02140
USA

Phone: +1 617 245 1457
EMail: john+ietf@jck.com