Использование нормализации Юникода для представления строк
Приложения могут использовать Юникод для представления строк в нескольких формах. По мере того как принятие Юникода растет, особенно через Интернет, возникла необходимость устранить несущественные различия в строках Юникода. Несколько представлений для сочетания символов усложняют программное обеспечение, например, когда веб-сервер отвечает на запрос страницы или компоновщик ищет определенный идентификатор в библиотеке.
Внимание!
Различные строки Юникода могут казаться визуально идентичными, что повышает безопасность. Дополнительные сведения см. в разделе Вопросы безопасности: международные функции.
В ответ на это требование консорциум Юникода определил процесс под названием "нормализация", который создает одно двоичное представление для любого из эквивалентных двоичных представлений символа. После нормализации две строки эквивалентны, если и только в том случае, если они имеют идентичные двоичные представления. Нормализация устраняет некоторые различия, но сохраняет регистр.
Чтобы использовать нормализацию Юникода, приложение может вызывать функции NormalizeString и IsNormalizedString для изменения порядка строк, аккордированных в Юникоде 4.0 TR#15. Нормализация может помочь повысить безопасность за счет сокращения альтернативных строковых представлений, имеющих одинаковое лингвистическое значение. Однако помните, что нормализация не может полностью исключить альтернативные представления.
Подробное описание стандартов Юникода для нормализации см. в приложении к Стандарту Юникода No 15: Формы нормализации Юникода (UAX 15).
Внимание!
Так как нормализация может изменить форму строки, механизмы безопасности или алгоритмы проверки символов обычно следует реализовать после нормализации. Дополнительные сведения см. в разделе Вопросы безопасности: международные функции.
Предоставление нескольких представлений одной и той же строки
Во многих случаях Юникод допускает несколько представлений того, что является лингвистическим значением одной и той же строки. Пример:
- Прописная буква A с диерезами (umlaut) может быть представлена как одна кодовая точка Юникода "Ä" (U+00C4) или сочетание прописной буквы A и объединяющего символа Dieresis ("A" + " esis", то есть U+0041 U+0308). Аналогичные рекомендации относятся ко многим другим символам с диакритических знаков.
- Прописная буква A может быть представлена обычно (латинская прописная буква A, U+0041) или полной прописной буквой A (U+FF21). Аналогичные рекомендации относятся к другим простым латинским буквам (как прописным, так и строчным) и символам катаканы, используемым при написании японского языка.
- Строка "fi" может быть представлена символами "f" и "i" (U+0066 U+0069) или лигатурой "fi" (U+FB01). Аналогичные рекомендации применимы ко многим другим сочетаниям символов, для которых Юникод определяет лигатуры.
Использование четырех определенных форм нормализации
Приложения могут выполнять нормализацию Юникода с помощью нескольких алгоритмов, называемых "формами нормализации", которые подчиняются различным правилам. Консорциум Юникода определил четыре формы нормализации: NFC (форма C), NFD (форма D), NFKC (форма KC) и NFKD (форма KD). Каждая форма устраняет некоторые различия, но сохраняет регистр. Win32 и платформа .NET Framework поддерживают все четыре формы нормализации.
Тип перечисления NLS NORM_FORM поддерживает четыре стандартные формы нормализации Юникода. Формы C и D предоставляют канонические формы для строк. Неканонические формы KC и KD обеспечивают дополнительную совместимость и могут выявить определенные семантические эквивалентности, которые не очевидны в формах C и D. Однако они делают это за счет определенной потери информации и, как правило, не должны использоваться в качестве канонического способа хранения строк.
Из двух канонических форм форма C является "составной" формой, а форма D является "разложенной" формой. Например, в форме C используется одна кодовая точка Юникода "Ä" (U+00C4), а в форме D — ("A" + " 1", то есть U+0041 U+0308). Они отображаются одинаково, так как "ирование" (U+0308) является объединяющим символом. Форма D может использовать любое количество кодовых точек для представления одной кодовой точки, используемой формой C.
Если две строки идентичны в форме C или D, они идентичны в другой форме. Кроме того, при правильной отрисовке они отображаются неотличимо друг от друга и от исходной ненормализованной строки.
После нормализации строки не могут быть последовательно возвращены в исходное представление. Например, если строка со смесью составных и разлагаемых символьных представлений преобразуется в нормализованную форму, невозможно отменить нормализацию в исходную смешанную строку. Таким образом, если приложению требуется исходное представление строки, оно должно хранить это представление явным образом. Однако преобразование между двумя каноническими формами является обратимым. Строка в форме C может быть преобразована в форму D, а затем обратно в форму C, и результат идентичен исходной строке C.
Формы KC и KD похожи на формы C и D соответственно, но эти формы совместимости имеют дополнительные сопоставления совместимых символов с базовой формой каждого символа. Такие сопоставления могут привести к потере незначительных изменений символов. Они сочетают в себе определенные символы, которые визуально отличаются. Например, они объединяют полноширинные и полуширинные символы с одинаковым семантическим значением или различными формами одной и той же арабской буквы или лигатуры "fi" (U+FB01) и пары символов "fi" (U+0066 U+0069). Они также объединяют некоторые символы, которые иногда могут иметь другое семантическое значение, например цифры, написанные как надстрочный, как подстрочный или заключенный в круг. Из-за этой потери информации формы KC и KD обычно не должны использоваться в качестве канонических форм строк, но они полезны для определенных приложений.
KC формы — это составная форма, а KD формы — разложенная форма. Приложение может переходить между формами KC и KD, но нет согласованного способа перехода от формы KC или KD к исходной строке, даже если исходная строка находится в форме C или D.
Windows, приложения Майкрософт и платформа .NET Framework обычно создают символы в форме C с помощью обычных методов ввода. В большинстве случаев в Windows форма C является предпочтительной формой. Например, символы в форме C создаются с помощью ввода с помощью клавиатуры Windows. Однако символы, импортированные из Интернета и других платформ, могут ввести другие формы нормализации в поток данных.
Следующие примеры взяты из UAX 15 и иллюстрируют различия между четырьмя формами нормализации.
| До преобразования | Форма D | Форма C | Примечания |
|---|---|---|---|
| "Äffin" | "A\u0308ffin" | "Äffin" | Ffi_ligature (U+FB03) не разлагается, так как имеет сопоставление совместимости, а не каноническое сопоставление.${REMOVE}$ |
| "Ä\uFB03n" | "A\u0308\uFB03n" | "Ä\uFB03n" | |
| "Генрих IV" | "Генрих IV" | "Генрих IV" | РИМСКОЕ ЧИСЛО IV (U+2163) не разлагается.${REMOVE}$ |
| "Генри \u2163" | "Генри \u2163" | "Генри \u2163" | |
| ga | ka +ten | ga | Разные эквиваленты совместимости одного японского символа не приводят к одной и той же строке в форме C.${REMOVE}$ |
| ka +ten | ka +ten | ga | |
| hw_ka +hw_ten | hw_ka +hw_ten | hw_ka +hw_ten | |
| ka +hw_ten | ka +hw_ten | ka +hw_ten | |
| hw_ka +десять | hw_ka +десять | hw_ka +десять | |
| kaks | k i + a m + ks f | kaks | Хангыльские слоги поддерживаются при нормализации. |
| До преобразования | KD формы | KC формы | Примечания |
|---|---|---|---|
| "Äffin" | "A\u0308ffin" | "Äffin" | Ffi_ligature (U+FB03) разлагается в форме KC, но не в форме C.${REMOVE}$ |
| "Ä\uFB03n" | "A\u0308ffin" | "Äffin" | |
| "Генрих IV" | "Генрих IV" | "Генрих IV" | Полученные здесь строки идентичны по форме KC.${REMOVE}$ |
| "Генри \u2163" | "Генрих IV" | "Генрих IV" | |
| ga | ka +ten | ga | Разные эквиваленты совместимости одного японского символа приводят к одной и той же строке в форме KC.${REMOVE}$ |
| ka +ten | ka +ten | ga | |
| hw_ka +hw_ten | ka +ten | ga | |
| ka +hw_ten | ka +ten | ga | |
| hw_ka +десять | ka +ten | ga | |
| kaks | k i + a m + ks f | kaks | Хангыльские слоги поддерживаются при нормализации. В более ранних версиях Юникода символы jamo, такие как ks f, имели сопоставления совместимости с k f + s f. Эти сопоставления были удалены в Юникоде 2.1.9, чтобы обеспечить сохранение слогов Hangul. |
Примечание
2 приведенные выше таблицы имеют авторские © права в 1998-2006 годах Unicode, Inc. Все права защищены.
Использование составных форм для одиночных глифов
Многие последовательности символов, соответствующие одному глифу, не имеют составных форм. Даже при нормализации в форме C один визуальный глиф или логический текстовый элемент может состоять из нескольких кодовых точек Юникода. Например, некоторые символы, используемые в письменном виде, имеют двойные диакритические знаки, так как они имеют только разложенные формы. Примером является строчная буква U с макроном и тильдой ("ū̃", U+016b U+0303, где первая кодовая точка — это нижний регистр U с макроном, а вторая — сочетание острого акцента).
Пример
Соответствующий пример можно найти в разделе NLS: пример нормализации Юникода.
Связанные темы
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по