Кратко

  • RFC 5137 нужен протоколам, которым требуется ASCII-escape; если доступен нативный UTF-8, обычно следует использовать его.
  • Документ рекомендует обозначать кодовую точку Unicode, а не повторно кодировать октеты UTF-8 или единицы UTF-16 без веской причины.
  • Протокол обязан определить полную грамматику и способ буквальной передачи символа, который вводит escape.
  • Явные ограничители показывают конец значения из четырёх, пяти или шести шестнадцатеричных цифр.
  • Префикс \u не задаёт единую грамматику: C, Java, JSON и другие среды трактуют похожие формы по-разному.
  • Интернет-протоколам не следует использовать суррогатные пары как общий механизм escape.
  • Среди рекомендуемых форм есть ограниченная backslash-u запись и XML-ссылка с обязательной точкой с запятой.
  • Успешное восстановление кодовой точки не доказывает валидность, нормализацию или допустимость всей строки как идентификатора.
  • Проверка безопасности на неверной стороне unescape или нормализации может быть обойдена другой записью того же результата.
  • Числовое значение, видимый глиф, равенство идентификаторов и привязка к субъекту — разные утверждения.
  • Журнал должен раздельно хранить входные байты, escape, скаляры, профиль, ключ сравнения и решение.
  • Руководству следует ограничить полномочия каждого слоя тем объектом, который он действительно наблюдал.

Почему точное число не закрывает расследование

Пограничный сервис получает ASCII, библиотека выполняет unescape, каталог нормализует имя, а система доступа ищет внутренний субъект. Все четыре компонента могут писать в журнал слово «имя», хотя фиксируют разные представления.

RFC 5137 регулирует первый переход. Если Unicode нельзя передать напрямую, лучше сослаться на кодовую точку, а не заставлять человека собирать её из октетов UTF-8 или единиц UTF-16. Такая запись ближе к таблице Unicode, короче для большинства не-ASCII символов и удобнее при отладке.

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

В отчёте нужно спрашивать: что именно проверял фильтр, что нормализовал каталог, какой ключ сравнивала база и какой внутренний ID получил право? Пока эти переходы не связаны, точная кодовая точка не объясняет конечное действие.

Кодовая точка не равна транспортным единицам

Кодовая точка — число в пространстве Unicode. UTF-8 превращает её в один–четыре октета, UTF-16 — в одну или две 16-битные единицы. Escape октетов описывает упаковку, escape кодовой точки непосредственно обозначает значение.

Если записывать октеты UTF-8 по отдельности, один символ распадается на несколько чисел. Аналитику надо знать encoding и выполнить дополнительное декодирование. При этом легче пропустить обрыв, перестановку или неверное предположение о кодировке. RFC 5137 предпочитает прямую ссылку, если предметом не является именно сериализованная форма.

Сырые байты всё равно надо сохранять. Итоговый скаляр не доказывает, что входной UTF-8 был минимальным и корректным или что библиотека не вставила символ замены. На транспортной границе нужны байты и объявленная кодировка, на смысловой — скаляры и ошибки.

В UTF-16 символы вне BMP образуют пару суррогатов. Каждая половина помещается в четырёхзначную запись, но не является самостоятельным скалярным значением. Если контроль пропускает половины, а следующий сервис соединяет их, действующий символ возникает после проверки. Поэтому RFC 5137 не рекомендует суррогатные пары для интернет-протоколов.

Ограничитель показывает границу ответственности

Диапазон до U+10FFFF требует четырёх, пяти или шести шестнадцатеричных цифр. Без конца записи следующий шестнадцатеричный символ можно принять за часть числа. Разные ожидания ширины дают разные результаты.

Один рекомендуемый вариант заключает цифры в апострофы после backslash-u. Другой использует числовую XML-ссылку и сохраняет финальную точку с запятой. Удаление её в HTML-подобной форме уничтожает преимущество явного окончания. Способ передать сам вводный символ также должен быть указан.

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

Тесты должны включать границы длины, соседнюю hex-цифру, потерянный конец, суррогаты, U+10FFFF, превышение диапазона, вводный символ и обрыв. Согласие независимых реализаций при отказе не менее важно, чем успешные примеры.

Почему знакомый \u ничего не гарантирует

В C варианты различаются регистром и длиной. Java трактует четыре цифры как единицу UTF-16. JSON тоже имеет четырёхзначные escapes и пару для некоторых символов. Другие языки используют скобки или переменную длину. Внешний вид не сообщает тип числа.

В собственной среде эти правила правомерны. Ошибка возникает, когда API называет всё «Unicode-escape». Производитель может посылать единицы UTF-16, а потребитель проверять кодовые точки. На BMP тесты совпадут; дополнительные символы обнаружат разрыв уже после запуска.

Для JSON грамматику задаёт RFC 8259. Профиль I-JSON требует корректных скалярных значений и устраняет непредсказуемость одиночных суррогатов. Строгость появляется из явно названного профиля, а не из трёх видимых знаков.

При миграции старое и новое толкования должны различаться до декодирования. Телеметрия обязана связывать вариант с производителем. Иначе терпимость не имеет условия завершения и превращается в постоянную двусмысленность.

Нормализация — следующий, а не встроенный шаг

Разные последовательности кодовых точек могут быть канонически эквивалентны. UAX #15 задаёт NFC, NFD, NFKC и NFKD. RFC 5198 выбирает UTF-8 и NFC для Net-Unicode. Модель W3C требует объявлять принимаемые, выдаваемые и сравниваемые формы.

Корректный escape не выбирает ни одну из них. Он может точно восстановить строку, которая ещё должна нормализоваться или быть запрещена профилем. Синтаксис, скалярная корректность, нормальная форма и пригодность идентификатора — отдельные проверки.

Порядок имеет значение. Фильтр до unescape не увидит символ, записанный числом. Проверка уникальности до NFC и поиск после NFC могут свести два принятых значения в один ключ. Нормализация только при показе создаёт видимое равенство при разных правах.

След нормализации должен назвать форму, версию Unicode, библиотеку, этап, вход и выход. Ограничение длины и case mapping тоже привязаны к этапу. Слово «нормализовано» без параметров так же неоднозначно, как \u без владельца грамматики.

От строки к субъекту

PRECIS создаёт классы и профили для международных идентификаторов и свободного текста. IDNA задаёт категории, NFC и связь A-label с U-label для DNS. Они начинают работу после восстановления кодовых точек.

Валидный Unicode-скаляр может быть запрещён в конкретном поле. Допустимость зависит от соседей, письменности и версии. DNS-метка требует специальных преобразований и обратной проверки. Числовая ссылка не доказывает регистрацию, владение или маршрут.

Визуальное сходство — ещё один слой. Разные значения могут выглядеть одинаково, а один ряд меняется от шрифта, shaping и направления. Показ кода помогает следователю, но не мешает пользователю перепутать подписи.

Критические идентификаторы требуют репертуара, правил письменности, поиска confusable, обработки коллизий и восстановления вне видимого имени. Права лучше связывать с устойчивым непрозрачным ID, оставляя международное имя проверяемым атрибутом.

Собрать цепочку, а не один красивый лог

На входе сохраняются байты, encoding и канал. Парсер сохраняет ASCII-запись, грамматику и ошибку. Следующий слой — скаляры. Профиль — версию, нормализацию, контекст и ключ сравнения. Авторизация — внутренний субъект, ресурс, правило и результат.

Если решение принимает человек, нужны шрифт, locale, направление и окружение. Скриншот доказывает вид, но не хранимый ряд. Сырой лог доказывает данные, но не восприятие. Их надо связывать.

Сквозные тесты проходят реальные Java-, JSON-, UTF-8-, БД- и клиентские границы. В набор входят дополнительные символы, комбинируемые последовательности, RTL-текст, литеральный ввод и ошибки. Тихая замена — изменение идентичности, не успех.

Так инцидент локализуется в конкретном преобразовании. Unicode не становится общей причиной, а интерфейс с самым понятным числом не получает власть над тем, чего не измерял.

Тонкий стандарт и толстое местное решение

RFC 5137 полезен своей узостью. Он делает ссылку на кодовую точку через ASCII понятнее и не объявляет себя реестром, системой идентичности или авторизации. Содержательную политику задают специализированные протоколы.

Владелец протокола отвечает за грамматику, runtime — за скаляры, интернационализация — за нормализацию, продукт — за равенство, безопасность — за порядок и сходство, авторизация — за связь с субъектом.

Вторичный риск возникает, когда самый наглядный факт начинает решать всё. Точный номер принимают за точный аккаунт, ожидаемый глиф — за равные данные. Локальная истина превращается в глобальную ошибку после удаления границы.

RFC 5137 даёт хороший первый чек. Расследование заканчивается только после последнего.

Источники

  1. RFC 5137 в HTML
  2. RFC 5137 в тексте
  3. Карточка RFC 5137
  4. RFC 5137 в IETF Datatracker
  5. История RFC 5137
  6. Поиск исправлений RFC 5137
  7. RFC 3629: UTF-8
  8. RFC 2781: UTF-16
  9. RFC 5198: Net-Unicode
  10. RFC 6365: терминология интернационализации
  11. RFC 2277: политика IETF по языкам и кодировкам
  12. RFC 8259: JSON
  13. RFC 7493: I-JSON
  14. RFC 8264: PRECIS
  15. RFC 5890: определения IDNA
  16. RFC 5891: протокол IDNA
  17. Приложение 15 стандарта Unicode
  18. Модель символов W3C
  19. Минимальная начальная спецификация, локальное будущее решение и добровольное принятие
  20. О слоях реальности, символической власти и враждебности ясности
  21. Running-Code Primary