Кратко

  • RFC 3536 различил кодированные октеты, абстрактные символы, системы письма, языки и глифы, выбранные механизмом отрисовки; успех одного слоя не доказывал следующий.
  • Глоссарий 2003 года был информационным, ненормативным и заведомо неполным, а RFC 6365 отменил его в 2011 году. Его урок сохраняется: читаемая форма подтверждает отрисовку, но не язык и не смысл.

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

RFC 3536 вышел в мае 2003 года под названием Terminology Used in Internationalization in the IETF. Это не кодировка и не профиль совместимости, а информационный словарь для дискуссий, где близкие слова обозначали разные уровни. Авторы прямо указали, что определения не нормативны, список неполон, а согласия по некоторым понятиям — особенно по «языку» — нет. В замороженной выдаче RFC Editor нет errata, однако пустой список исправлений не делает терминологию окончательной.

В сети исходным материалом служат биты и октеты. Charset объясняет, как октеты соответствуют абстрактным символам: RFC 3536 описывает его как кодированный набор вместе со схемой кодирования под зарегистрированным IANA именем. UTF-8 в RFC 3629 решает эту задачу декодирования. Метка не сообщает, написана ли строка по-русски, по-арабски или по-японски, и не гарантирует ни грамматику, ни понимание.

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

Письменность и язык тоже не образуют взаимно однозначную пару. Одна система письма обслуживает много языков, один язык может использовать несколько систем. Определение script помогает отрисовке, но не называет язык. RFC 3066, а затем RFC 5646 задали языковые теги как отдельные метаданные. Даже синтаксически правильный тег может быть угадан или ошибочен и не доказывает естественность текста либо понимание.

RFC 2277 уже поставил в центр человека: протокол сам не говорит на естественном языке, но переносимые строки предназначены людям. Поэтому приём не-ASCII октетов — лишь начало. Ввод, хранение, сравнение, поиск, сортировка, визуальный, звуковой и тактильный вывод, а затем возможность действовать — самостоятельные переходы.

Нормализация показывает слабость внешнего сходства. Unicode допускает разные последовательности, канонически эквивалентные друг другу. Unicode Standard Annex #15 задаёт формы нормализации, RFC 5198 позже предложил формат подготовки сетевого текста. Главное процедурное требование RFC 3536 — протокол должен указать, где происходит нормализация. Если вход, база и сравнение решают сами, одинаковые на вид строки становятся разными ключами или разные записи сливаются без аудиторского следа.

Эта тема не повторяет существующую статью о RFC 5137. Та посвящена Unicode-экранированию, нормализованным идентификаторам и неоднозначности учётных записей. Здесь предмет шире: октеты превращаются в символы, получают контекст письменности и языка, а затем отображаются глифами. Политика идентификаторов — лишь одно применение этой цепочки.

Сортировка имеет собственный уровень. Ожидаемый людьми порядок зависит от языка и традиции и обычно не совпадает с числовым порядком кодовых точек. Сообщества с одной письменностью могут ожидать разные словарные порядки. База данных безошибочно завершит детерминированную сортировку и всё же покажет неправильный указатель. «Запрос выполнен» не доказывает пригодность collation.

Двунаправленный текст разделяет порядок в памяти и на экране. Скриншот не всегда раскрывает исходную последовательность; курсор, копирование или синтез речи могут показать скрытую структуру. Кроме того, rendering в RFC 3536 бывает визуальным, звуковым и тактильным. Правильная картинка может сочетаться с неверным произношением или бесполезным выводом Брайля.

Статус документа нужно датировать точно. RFC 3536 никогда не был Internet Standard. В сентябре 2011 года RFC 6365 вышел как BCP 166 после консенсуса и открытого рассмотрения IETF и явно объявил RFC 3536 устаревшим. Позднее RFC 7997 изменил правила не-ASCII знаков в самих RFC. Эти шаги не делают определения 2003 года нормативными задним числом.

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

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

Источники