Кратко

  • RFC 3987 определил место для интернационализированных идентификаторов ресурсов (IRI), способных содержать Unicode, рядом с программами, ориентированными на URI. Правило преобразования зависит от компонента: хост в виде доменного имени может требовать обработки IDNA, а Unicode в пути или запросе представляется через UTF-8 и процентное кодирование.
  • В RFC 3987 соавторами указаны Martin J. Dürst и Michel Suignard; университетское резюме Dürst называет его основным автором спецификации IRI. Стандарт связывает привычные читателю письменности с более старым программным обеспечением, но не регистрирует имя, не устанавливает контроль над доменом и не доказывает, что визуально похожие строки указывают на один ресурс.

Сначала восстановить последовательность обработки

Представим веб-адрес с японскими знаками в пути и именем хоста в другой письменности. Человек воспринимает его как одно целое. Клиенту, однако, нужно разобрать схему, authority, путь, запрос и, возможно, фрагмент. Затем для каждой части действуют свои правила. Читаемая форма и форма, переданная компоненту, принимающему только URI, могут соответствовать друг другу, не совпадая посимвольно.

Для этого и появились Internationalized Resource Identifiers, или IRI. RFC 3986 задаёт общую синтаксическую структуру Uniform Resource Identifiers (URI), ограничивая набор символов частью US-ASCII. Опубликованный в январе 2005 года RFC 3987 добавил Unicode-совместимое дополнение, а не стал незаметно менять прежнее определение URI. Авторы объяснили, что новый элемент протокола сохранит ясную границу и позволит избежать несовместимости с уже существующим программным обеспечением.

Компонент, понимающий IRI, может работать с более широкой последовательностью символов; если же на пути получения ресурса есть компонент, принимающий только URI, IRI нужно преобразовать в соответствующую форму URI.

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

Хост и путь не должны смешиваться

Самая важная граница проходит после //, в части authority веб-адреса. Если хост — доменное имя, используемое в DNS, описанное RFC 3987 в 2005 году преобразование применяет операцию ToASCII из IDNA к каждой метке между точками. Получается ASCII-совместимая форма, пригодная для программ эпохи URI. Пример из RFC преобразует хост résumé.example.org в xn--rsum-bpad.example.org.

Этот пример показывает и возможности Punycode, и её пределы. Алгоритм кодирует доменную метку в ASCII-совместимую форму; он не преобразует весь URL и не предназначен для каждой не-ASCII части. Префикс xn-- также не является знаком качества: RFC 5890 отличает проверенную по правилам IDNA A-метку от строки, которая только выглядит как A-метка. Важна проверка протоколом, а не внешний вид.

Есть и временная граница между поколениями стандартов. Для преобразования хоста RFC 3987 ссылается на RFC 3490 — протокол IDNA 2003 года. Более поздняя система IDNA2008, в том числе RFC 5890 и RFC 5891, изменила терминологию и протокольные правила. RFC 5895 — информационный документ о преобразовании пользовательского ввода до обработки IDNA2008; он отмечает, что подходящий вариант может зависеть от языка, приложения и способа ввода. Поэтому пример RFC 3987 нужно читать в контексте 2005 года, а не как гарантию единого преобразования во всех современных браузерах.

Путь — не доменная метка

Если те же знаки перенести в путь, способ обработки изменится. Фрагмент пути /研究 можно представить в URI как /%E7%A0%94%E7%A9%B6, кодируя октеты UTF-8 процентами. Punycode здесь не применяется. Путь может интерпретировать веб-сервер, прикладной фреймворк, файловое хранилище или собственный маршрутизатор; DNS не разрешает каждый его сегмент.

У запроса и фрагмента также своя семантика. Знак процента, косая черта, вопросительный знак или решётка могут быть структурными разделителями, а не обычными данными, поэтому важны порядок разбора и экранирования. RFC 3987 сохраняет синтаксис компонентов URI и расширяет набор знаков, которые можно непосредственно использовать в IRI. Это не правило «заменить каждый символ Unicode на ASCII-написание». Подходящую операцию определяют схема и компонент.

Именно поэтому стандарт рекомендует откладывать преобразование до самого позднего этапа — пока идентификатор не попадёт в компонент, который не умеет работать с IRI. Слишком раннее преобразование может удалить понятную человеку форму до передачи её другой IRI-совместимой программе. Если сервер по-иному нормализует или декодирует строку, два компонента могут по-разному истолковать запрошенный путь. Дизайн Dürst и Suignard относится к стыку систем, а не только к отображению нелатинских символов в адресной строке.

Корректное кодирование не регистрирует имя

IDNA отвечает на узкий вопрос: можно ли представить и проверить метку по применимым правилам? RFC 5891 разделяет регистрацию и DNS-запрос. Обработка у регистратора до передачи запроса администратору зоны находится вне определения протокола IDNA; реестр или администратор зоны проверяет конкретную строку, поданную на регистрацию. Поэтому синтаксически допустимая A-метка не доказывает, что имя зарегистрировано, делегировано в DNS или контролируется службой, которую ожидает пользователь.

Эту разницу легко упустить, когда знакомое Unicode-имя копируют в документ. Есть несколько отдельных свидетельств: символы, введённые человеком; преобразование, выполненное интерфейсом; метка хоста, отправленная в DNS; и ответ веб-службы. Данные регистрации и доказательства контроля над службой — дополнительные факты, а не иные написания той же строки. Успешное преобразование не подтверждает ни одного из них.

Это также вопрос безопасности. RFC 3987 предупреждает о подмене и в хосте, и в пути: похожие знаки, разные ожидания нормализации или несовпадающая обработка на клиенте и сервере могут привести к разным ресурсам, хотя адреса выглядят схоже. Стандарт не объявляет Unicode опасным сам по себе. Он требует понимать, на какой компонент и какое преобразование опирается система. Отображённая строка свидетельствует о представлении, но не удостоверяет личность или контроль.

Вклад Dürst без легенды об одиночном изобретателе

В RFC указаны два автора: M. Dürst и M. Suignard. Официальное краткое резюме Dürst на сайте Университета Аояма Гакуин называет его основным автором спецификации IRI и описывает более раннюю работу по интернационализации веба, применению Unicode и нормализации составных символов. В нём также говорится, что значительную часть периода подготовки RFC 3987 он руководил деятельностью W3C по интернационализации. Университет указывает его профессором College of Science and Engineering.

Эти данные говорят о существенном вкладе, но не о единоличном авторстве. Значение работы проявляется в архитектурном решении: вместо того чтобы заставлять программы URI угадывать смысл новых знаков, IRI даёт Unicode-совместимому ПО своё символьное представление и указывает, когда нужно преобразование. Вклад Dürst был частью более широкой стандартизации; в самом RFC соавтором также указан Suignard.

Связь с «правом на точные реестровые данные» из заметки Heng Lu намеренно ограничена. Note 72 посвящена региональным интернет-регистратурам и интернет-ресурсам нумерации; это не политика DNS и не правила для доменных имён. Здесь это лишь аналитический вопрос: точно ли запись описывает состояние, которое она якобы фиксирует? Unicode-написание, A-метка, DNS-делегирование и ключ ресурса веб-службы связаны, но относятся к разным слоям. Ни одно из них не заменяет остальные.

Источники