Нормализация и Microsoft - что у нас за история с ними?

Это перевод Normalization and Microsoft -- whats the story? Автор: Майкл Каплан.

Нормализация - это слово, которое явно перегружено смыслами. С тех пор, как я пришёл в Microsoft, к сегодняшнему дню я услышал, по меньшей мере, четыре отдельных случая:

• Оно используется командой SQL сервера, когда они говорят о сравнениях строк.
• Оно используется API сопоставления NLS по той же причине (флаги NORM_*), ссылаясь на потенциально игнорируемые различия в строках при сравнении.
• Robert A. Wlodarczyk использовал термин строковой нормализации, ссылаясь на более общий тип поиска, включающий в себя нечёткое сравнение строк.
• В Unicode есть технический отчёт, названный Unicode Normalization Forms (формы/виды нормализации Unicode), который определяет технику для "сворачивания" (folding out) различий в эквивалентных последовательностях.

А смотря на определения этого слова в dictionary.com:

• Сделать что-то нормальным, в смысле соответствия норме или стандарту
• Сделать (текст или язык) регулярным и согласующимся, особенно по отношению к стилю и орфографии
• Удалить штаммы и снизить грубую кристаллическую структуру (металл), особенно нагреванием и охлаждением
• Уменьшение до стандартного или нормального состояния

Я считаю, что только в случае с Unicode это слово используется правильно, хотя, быть может, случай "строковой нормализации" не так далёк от этого. Ну, команде SQL сервера не повезло (хотя у них есть преимущество, что это слово не наплюхано по их официальной документации и заголовочникам - только те из клиентов, кто связывается с ними, слышат это слово). И, конечно же, тем из нас, кто работает над NLS. Упс!

Но, отстраняя вопросы терминологии, поддерживает ли сопоставление/collation (как операция) концепции, описанные в нормализации Unicode? Другими словами, рассматривает ли функция CompareString символ U+00c5 (Å, LATIN CAPITAL LETTER A WITH RING ABOVE) как эквивалент U+0041 U+030a (Å, LATIN CAPITAL LETTER A + COMBINING RING ABOVE)?

Ответ: да. Но не потому, что используется нормализация Unicode.

Как и вчера, когда я указал, что UCA был написан через много лет после того, как Microsoft (и другие компании) сделали свою работу, Unicode Normalization была предложена в виде черновика весной 1998. Она стала техническим отчётом летом 1999-го. Функции сопоставления (CompareString и LCMapString) поддерживали этот тип операции за много лет до этого момента.

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

• в Арабских формах представления (где множество precomposed-литералов не рассматривались равными в их скомбинированной форме)
• в Korean Old Hangul (где Jamo-последовательности получали весы близкие, но не идентичные к их 'скомбинированной' Hangul-форме)

Когда-то я был поражён отличиями, к которым может приводить "лингвистический" подход в сравнении с "техническим", даже хотя он номинально работал для тех же (или похожих) клиентов. В двух категориях выше, были конкретные причины для этих различий, связанные с отзывами пользователей. В некоторых случаях, имеет смысл устранить эти различия (к примеру, некоторые из Арабских), но в большинстве случаев эти различия вынуждены остаться.

Есть и другой путь (кто-то может сказать, что более важный), в котором Microsoft поддерживает нормализацию Unicode - в функции FoldString, с её флагами MAP_PRECOMPOSED, MAP_COMPOSITE и MAP_FOLDCZONE. Хотя таблицы, которые используются для этого, несколько устарели, но они, очевидно, имеют ту же самую цель. В перспективе имеет смысл обновить эту информацию.

Я не хочу сказать, что нормализация Unicode не важна - она важна. Как стандарт, он был взят на вооружение IETF, W3C и многими другими. Люди, работающие над бетой Whidbey, уже могут видеть String.IsNormalized и String.Normalize в их Intellisense (аналог CodeInsight), а те, кто видели сборку PDC или выше Longhorn-а, заметили функции IsNormalized и Normalize. Вероятно, найдутся люди, кто захочет быть уверенным, что их текст находится в правильной нормализованной форме, прежде чем сохранять или передавать его.

Но поскольку все методы текстового ввода в Windows уже используют конкретную форму нормализации (form C), и поскольку ввод, очевидно, является операцией, длительной по времени, то не имеет значения, как быстро он выполняется, здесь это опциональная задача, которая может быть выполнена, когда это важно. Особенно, когда всё и так работает почти всегда.

(Это была та область, в которую я вошёл потрясённым, что мы не поддерживаем стандарт Unicode, но вышел я, довольный тем, насколько именно мы отстаём в отсутствии поддержки. Обычно, когда я что-то не поддерживаю, то у меня получается намного хуже удовлетворять чьим-то ожиданиям!)

Так поддерживаем ли мы нормализацию Unicode сегодня? Ну, вроде того. По крайней мере, в FoldString и сравнениях. Не на 100%, но мы отрабатываем во всех самых частых случаях.

Планируем ли мы поддерживать её в будущих версиях продукта? Несомненно. Те, кто следит за бетами, могут видеть это уже сейчас (а остальные могут найти упоминания об этом в Интернете - что удивило меня больше, чем должно бы).