Кратко

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

Сравнение предшествовало идентификации

Unicode вывел протоколы за пределы ASCII, но один визуально воспринимаемый текст мог состоять из разных последовательностей, вариантов регистра, совместимых символов и невидимых меток. Опубликованный в декабре 2002 года RFC 3454 определил stringprep для подготовки строки перед хранением или сравнением.

Обещание было осторожным: повысить вероятность, что два человека, считающие свой ввод одинаковым, получат посимвольно одинаковый результат. Документ не обещал свести воедино все варианты написания во всех языках. Текст, запись RFC Editor, Datatracker, история, ссылки, последующие цитирования и исправления подтверждают стандарт, но не намерение пользователя и не владельца аккаунта.

Политику задавал профиль

Stringprep не был самостоятельным правилом. Протокол должен был назвать область применения, репертуар, таблицы отображения, нормализацию, запрещённый вывод, bidi-проверку и дополнения. Разные профили могли законно обработать один ввод по-разному.

Отображение могло удалить, заменить или развернуть символ; созданные результаты на том же этапе повторно не проверялись. Если профиль выбирал нормализацию, RFC 3454 требовал NFKC, описанную в Unicode Standard Annex #15. Больше форм сходилось, но это не гарантировало одинаковый вид во всех шрифтах или одинаковый смысл во всех языках.

Порядок был частью исполняемого договора

Отображение, нормализация, запрет, bidi-проверка должны были идти именно так. Перестановка могла изменить результат. Проверка запрета возвращала либо строку, либо ошибку. Профиль мог исключить управляющие и частные символы, несимволы, суррогаты и теги. Bidi-правила стабилизировали границы строк с письмом справа налево, но не аутентифицировали автора.

Unicode Technical Report #36 позднее подробнее описал визуальные подмены. Правильная нормализация не устраняет все похожие знаки, а равенство вывода не доказывает общего владельца.

Версия входила в доказательство

RFC 3454 закрепил таблицы Unicode 3.2 и запретил автоматически переносить их на будущие версии. Это обеспечивало воспроизводимость, но делало утверждение «строка допустима» неполным без профиля и версии.

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

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

Nameprep показал пользу и долг обновления

RFC 3491 сделал Nameprep профилем исходного IDNA, а RFC 3490 встроил его в процесс. RFC 4690 зафиксировал проблемы, а словарь IDNA2008 в RFC 5890 отказался от stringprep.

Сравнение не перестало быть нужным; устарел привязанный к версии каркас. RFC 6885 сформулировал задачу PRECIS, RFC 7564 заменил RFC 3454, а RFC 8264 заменил первый PRECIS. Эта последовательность доказывает ремонт, а не мгновенную перемену смысла всех старых идентификаторов.

Дисциплина слоёв реальности Heng Lu разделяет ввод, профиль, таблицы, этапы, вывод или ошибку, сравнение, привязку аккаунта и авторизацию. Приоритет работающего кода позволяет программе доказать вычисление, но не назначить собственника. Минимальная начальная спецификация объясняет, почему личность и полномочия оставались использующему протоколу. Это поздняя редакционная интерпретация.

RFC 3454 сделал нормализацию сильной внутри названной границы. Детерминированное сравнение всё равно не стало идентичностью.

Источники