Кратко

  • В семислойной схеме RFC 2130 набор кодированных символов CCS, способ представления их октетами CES и синтаксис передачи TES отделены от языка, локали, культурных предпочтений и компоновки. Декодирование символов не удостоверяет результат для читателя.
  • Зарегистрированные метки MIME и значения ISO 10646/UTF-8 для новых разработок были рекомендациями с оговорками о старых протоколах и согласовании. Информационный доклад не задавал новый сетевой протокол и не измерял распространение многоязычия.

Машинная команда и человеческий ответ

В почтовом обмене сервер разбирает MAIL FROM, а человек читает пояснение ошибки. Из того, что обе части представлены символами, не следует одинаковая свобода их переводить. RFC 2130 предупреждал: локализованная альтернатива машинной команде может нарушить работу существующих разборщиков. Текст, предназначенный пользователю, напротив, можно было бы локализовать через расширение с ясным указанием языка и представления. Сначала надо установить, кто именно должен интерпретировать строку.

Приглашённый семинар IAB проходил 29 февраля — 1 марта 1996 года; доклад опубликован в апреле 1997-го со статусом Informational. Это не интернет-стандарт. Почта, каталоги и Web выработали неодинаковые способы обращения с текстом. Авторы предложили общую схему описания, а не приказ заменить уже работающие механизмы одной «универсальной» кодировкой.

Три слоя для линии связи

CCS сопоставляет абстрактным символам целые числа. CES преобразует их в октеты. TES меняет уже закодированные данные, чтобы они прошли по конкретному каналу. Примеры — ISO 10646, UTF-8 и Base64 соответственно. Это не три имени одной технологии. В MIME параметр charset может одновременно указывать CCS и CES, а Content-Transfer-Encoding описывает преобразование для переноса. Доклад признавал, что прежние регистрации не всегда разделяют понятия аккуратно, и предлагал уточнять описание будущих наборов.

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

Приёмник может узнать параметры из стандарта, метки транспортной оболочки, сигнала в самом потоке, прежнего соглашения либо согласования в протоколе. Угадать кодировку по стране отправителя — ненадёжный путь. Поэтому семинар советовал применять зарегистрированные MIME-значения для наборов и языков, если надёжного существующего механизма определения нет. Даже верная по форме метка должна соответствовать реальным байтам; заголовок не исправляет ошибочное содержимое.

Для кого существует имя

Доклад различал механизм протокола, идентификаторы и данные. Ссылаясь на RFC 1958, он сохранял регистронезависимый ASCII для широко видимых публичных имён — в частности, DNS и текстовых элементов протокола. Локальное имя папки почтового ящика не требовало столь же жёсткого правила. Прежде чем применять UTF-8 в прежнем ASCII-протоколе, следовало согласовать версию или набор символов и оставить совместимый путь отступления. Сообщения, базы и HTML-страницы как данные нуждались в поддержке разных наборов и прикладного контекста.

Для нового текстового протокола доклад рекомендовал ISO 10646 как CCS и UTF-8 как CES. Старый протокол мог сохранить прежнее значение по умолчанию ради совместимости; семибитный тракт мог потребовать отдельного преобразования. Общего значения TES не назначалось, другие наборы не запрещались. RFC 2044 описывал форму байтов UTF-8, RFC 2066 — согласование Telnet, RFC 2070 — декодирование HTML, RFC 2152 — Unicode в семибитной почте. RFC 2130 задавал границы таких отдельных решений, а не заменял их.

Источники и границы

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