Кратко

  • RFC 3987 ввела читаемые Unicode-идентификаторы, но не превратила отображаемую форму в доказательство регистрации, разрешения имени или ресурса.
  • Исходная строка, URI, U-label, A-label, DNS-ответ и результат приложения требуют самостоятельных квитанций.

RFC 3987 в январе 2005 года определила IRI как последовательность символов Unicode и как отдельный элемент, дополняющий URI. Статус, исправления и история Datatracker сохраняют мотив: не менять существующее определение URI, а дать детерминированное преобразование для совместимости со старым программным обеспечением.

Детерминированность преобразования не означает единой власти над именем. Пользователь вводит строку; приложение получает точки кода; кодировка превращает их в октеты; контейнер экранирует данные; IRI отображается в URI; компонент host может пройти IDNA; резолвер обращается к DNS; сервер отвечает. Это одна цепочка, но каждое звено отвечает на собственный вопрос.

RFC 3986, её статус, исправления и история сделали сравнение URI зависимым от цели. RFC 3987 добавила различие символов и байтов. Одинаковая строка в UTF-8 и UTF-16 не совпадает побайтно, поэтому простое сравнение сначала приводит значения к общей форме кодирования, а затем идёт по кодовым точкам.

Перед таким сравнением нельзя преобразовывать IRI в URI. Стандарт объясняет запрет тем, что отображение способно создать дополнительные ложные эквивалентности. Совместимая транспортная форма не является универсальным ключом идентичности. По той же причине IRI не следует изменять в пути, если строка может использоваться как идентификатор.

Нормализация применяется на обозначенной границе. При вводе с бумаги или из известной не-Unicode-кодировки используется NFC. Уже представленную в UTF-8 или UTF-16 строку этот шаг преобразования не нормализует снова. Создателю рекомендуется NFC, но третья сторона не должна произвольно переписывать существующий IRI, не зная правил владельца.

RFC 5198, статус, исправления и запись описывают NFC для сетевого Unicode-текста и ожидаемую стабильность нормализованных назначенных символов. Это аргумент за согласованное создание и обмен, но не разрешение посреднику уничтожить полученный оригинал.

Для локального сравнения можно выровнять percent-encoding: привести регистр шестнадцатеричных цифр и убрать определённые различия экранирования. Если значение будет передано дальше, RFC 3987 требует сохранить исходную форму. Производный ключ ускоряет индекс, но не заменяет запись о получении.

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

Для международного имени хоста действует последующая модель IDNA2008. RFC 5890, статус, исправления и история разделяют читаемый U-label, ASCII-форму A-label, регистрацию и поиск. RFC 5891, её статус, исправления и история задают проверку и симметрию. Увидеть имя — не то же самое, что подтвердить допустимую DNS-метку.

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

Поэтому современная проверка международного адреса должна хранить исходные символы и способ их получения, версию Unicode и NFC, кодировку и экранирование, преобразованный URI, правила сравнения, U-label/A-label и проверку IDNA, DNS-ответ и результат приложения. RFC 3987 сделала Интернет-идентификатор ближе к языку пользователя. Сохранение оригинала не позволило удобному отображению незаметно стать доказательством регистрации, власти или результата.

Источники