openlang
Текст и Unicode

Ключи поиска NFC и подписи JCS

Разговор продолжается 1 ↓Посмотреть источники ↓

Подпись усложняет вопрос, который раньше задал kim_dh, где отправленное имя отделено от ключа поиска NFC. В JSON-нагрузке есть имя, записанное как e с последующим U+0301, и эта строка участвует в подписи на основе JCS.

RFC 8785 сохраняет разобранные строковые данные Unicode без нормализации. При этом JCS всё равно выполняет каноническую сериализацию JSON, так что подписывается не просто исходный набор байтов. Если до канонизации заменить имя на U+00E9, изменятся те самые строковые данные, которые протокол сохраняет.

Мой вариант такой. Значения, переданные в JCS, не трогать, а ключ поиска NFC выводить в собственное поле приложения. Это лишнее представление, зато преобразование для поиска остаётся на виду. Две нагрузки смогут иметь общий ключ приложения и при этом сохранить разные строковые данные Unicode для JCS.

Неясно мне пока одно. Где должно происходить это вычисление, чтобы код поиска не мог тихо подставить свой ключ в нагрузку, уходящую в JCS.

Разговор продолжается 1

Следуя доводам
  1. Ссылка на ответ

    Вынесите вычисление в конструктор и сделайте его единственным способом получить ключ поиска. Если у типа LookupKey есть только одна фабрика, которая принимает исходное имя и хранит его форму NFC, код поиска держит LookupKey, а не голую строку, и в типе полезной нагрузки такого поля просто нет. В C# это record с приватным конструктором и статическим From, который вызывает Normalize(NormalizationForm.FormC). Это не помешает кому-то вручную вызвать Normalize на значении из нагрузки, но такая строка бросается в глаза на ревью.

Другие стороны того же вопроса

  1. Текст и Unicode

    Разумно ли по умолчанию искать имена по ключу NFC?

    Так, вставляю имя, а в конце у него e и следом U+0301. Через неделю ввожу то же имя руками, и клавиатура даёт U+00E9. Для мен…

    Ответы 3typescriptkotlinjavascript