Проект ICU (який також тепер має бібліотеку PHP ) містить класи, необхідні для нормалізації рядків UTF-8, щоб полегшити порівняння значень під час пошуку.

Однак я намагаюся розібратися, що це означає для додатків. Наприклад, у яких випадках я хочу "Канонічну еквівалентність" замість "Еквівалентність сумісності" чи навпаки?

Все, чого ти ніколи не хотів знати про нормалізацію Unicode

Канонічна нормалізація

Unicode включає кілька способів кодування деяких символів, особливо помітних символів. Канонічна нормалізація змінює кодові точки на канонічну форму кодування. Отримані в результаті кодові точки повинні бути ідентичними вихідним, що забороняють будь-які помилки в шрифтах або системі відображення.

Коли використовувати

Оскільки результати здаються однаковими, завжди безпечно застосовувати канонічну нормалізацію до рядка перед його збереженням або відображенням, якщо ви можете допустити, що результат не є бітовим для біт-ідентичного вводу.

Канонічна нормалізація буває 2 форм: NFD і NFC. Дві рівнозначні в тому сенсі, що можна конвертувати між цими двома формами без втрат. Порівняння двох рядків під NFC завжди дасть той самий результат, що і порівняння їх за NFD.

НФД

У NFD символи повністю розширені. Це швидша форма нормалізації для обчислення, але результати в більшій кількості кодових точок (тобто використовується більше місця).

Якщо ви просто хочете порівняти два рядки, які вже не нормалізовані, це найкраща форма нормалізації, якщо ви не знаєте, що вам потрібна нормалізація сумісності.

NFC

NFC рекомбінує кодові точки, коли це можливо після запуску алгоритму NFD. Це займе трохи більше часу, але призводить до коротших рядків.

Нормалізація сумісності

У Unicode також входить багато символів, які дійсно не належать, але були використані у застарілих наборах символів. Unicode додав їх, щоб дозволити обробляти текст у цих наборах символів як Unicode, а потім конвертувати назад без втрат.

Нормалізація сумісності перетворює їх у відповідну послідовність "реальних" символів, а також виконує канонічну нормалізацію. Результати нормалізації сумісності можуть бути не ідентичними оригіналам.

Символи, які включають інформацію про форматування, замінюються на такі, які не мають. Наприклад, персонаж ⁹перетворюється на 9. Інші не передбачають відмінностей у форматуванні. Наприклад, римський цифровий символ Ⅸперетворюється на звичайні букви IX.

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

Коли використовувати

Консорціум Unicode пропонує думати про нормалізацію сумісності як про ToUpperCaseперетворення. Це щось, що може бути корисно в деяких обставинах, але ви не повинні просто застосовувати його мимоволі.

Відмінним випадком використання буде пошукова система, оскільки ви, ймовірно, хочете, щоб пошук 9відповідав ⁹.

Одне, що ви, мабуть, не повинні робити, - це відображати результат застосування нормалізації сумісності до користувача.

NFKC / NFKD

Форма нормалізації сумісності складається у двох формах NFKD і NFKC. Вони мають ті ж стосунки, що і між NFD та C.

Будь-яка рядок у NFKC притаманна також NFC і однакова для NFKD та NFD. Таким чином NFKD(x)=NFD(NFKC(x)), і NFKC(x)=NFC(NFKD(x))т.д.

Висновок

Якщо сумніваєтеся, перейдіть до канонічної нормалізації. Вибирайте NFC або NFD, виходячи з можливих компромісів простір / швидкість або на основі того, що вимагається тим, з чим ви взаємодієте.

Деякі символи, наприклад, букву з наголосом (скажімо, é), можна представити двома способами - єдиною кодовою точкою U+00E9або простою літерою, за якою слід поєднувати знак наголосу U+0065 U+0301. Звичайна нормалізація вибере одне із них, щоб завжди представляти його (єдина кодова точка для NFC, поєднуюча форма для NFD).

Для символів, які можуть бути представлені кількома послідовностями базових символів та комбінуючими позначками (скажімо, "s, крапка внизу, крапка вгорі" проти поставлення крапки вище, ніж точка нижче, або використання базового символу, у якого вже є одна з крапок), NFD буде також виберіть один із них (нижче йде перший, як це відбувається)

Декомпозиції сумісності включають в себе ряд символів, які "насправді не повинні" бути символами, але є тому, що вони використовувались у застарілих кодуваннях. Звичайна нормалізація не уніфікує їх (для збереження цілісності в обидва кінці - це не є проблемою для комбінуючих форм, оскільки жодне застаріле кодування (крім кількох в'єтнамських кодувань) не використовує обох), але нормалізація сумісності буде. Подумайте, як кілограмовий знак «кг», який з’являється в деяких східноазіатських кодировках (або напівширока / повна ширина катакана і алфавіту), або «фі» лігатура в Макромані.

Докладнішу інформацію див. У розділі http://unicode.org/reports/tr15/ .

Нормальні форми (Unicode, а не бази даних) стосуються переважно (виключно?) Символів, які мають діакритичні позначки. Unicode надає деяким символам "вбудовані" діакритичні позначки, такі як U + 00C0, "Латинська столиця A з могилою". Той самий символ може бути створений з `Latinski Capital A '(U + 0041) з" Combining Grave Accent "(U + 0300). Це означає, що навіть якщо дві послідовності створюють один і той же результуючий символ, байт-байт порівняння покаже їх як абсолютно різні.

Нормалізація - це спроба впоратися з цим. Нормалізація запевняє (або принаймні намагається), що всі символи кодуються однаково - або всі, використовуючи окремий комбінуючий діакритичний знак, де це необхідно, або всі, використовуючи єдину точку коду, де це можливо. З точки зору порівняння, це насправді не має значення всієї партії, яку ви обираєте - майже будь-яка нормалізована рядок буде належним чином порівнюватися з іншою нормованою рядком.

У цьому випадку "сумісність" означає сумісність з кодом, який передбачає, що одна кодова точка дорівнює одному символу. Якщо у вас є такий код, ви, ймовірно, хочете використовувати звичайну форму сумісності. Хоча я ніколи не бачив, щоб це було прямо зазначено, назви звичайних форм означають, що консорціум Unicode вважає за краще використовувати окремі комбінуючі діакритичні позначки. Для цього потрібно більше інтелекту для підрахунку фактичних символів у рядку (а також таких речей, як інтелектуальне розбиття рядка), але є більш універсальним.

Якщо ви повноцінно використовуєте ICU, швидше за все, ви хочете використовувати канонічну нормальну форму. Якщо ви намагаєтеся самостійно написати код, який (наприклад) передбачає, що точка коду дорівнює символу, вам, ймовірно, потрібна нормальна форма сумісності, яка робить це правдивим якомога частіше.

Якщо два рядки Unicode канонічно еквівалентні, то рядки дійсно однакові, лише використовуючи різні послідовності unicode. Наприклад, Ä може бути представлений або за допомогою символу Ä, або комбінації A і ◌̈.

Якщо рядки є лише еквівалентною сумісністю, то рядки необов'язково однакові, але вони можуть бути однаковими в деяких контекстах. Наприклад, ff можна вважати таким же, як і ff.

Отже, якщо ви порівнюєте рядки, ви повинні використовувати канонічну еквівалентність, оскільки еквівалентність сумісності не є реальною еквівалентністю.

Але якщо ви хочете сортувати набір рядків, може бути доцільним використання еквівалентності сумісності, оскільки вони майже однакові.

Це насправді досить просто. UTF-8 насправді має кілька різних уявлень одного і того ж "характеру". (Я використовую символи в лапках, оскільки байтові вони різні, але практично вони однакові). Приклад наведено у пов'язаному документі.

Символ "Ç" може бути представлений у вигляді послідовності байтів 0xc387. Але він також може бути представлений C(0x43) з наступною послідовністю байтів 0xcca7. Тож можна сказати, що 0xc387 та 0x43cca7 - це один і той же персонаж. Причина, яка спрацьовує, полягає в тому, що 0xcca7 - це поєднувальний знак; це означає, що він приймає персонажа перед ним (a Chere) і модифікує його.

Тепер, що стосується різниці між канонічною еквівалентністю та еквівалентністю сумісності, нам потрібно переглянути загальні символи.

Існує 2 типи символів, ті, які передають значення через значення , і ті, які приймають інший символ і змінюють його. 9 - значущий персонаж. Супер-сценарій ⁹ приймає це значення і змінює його поданням. Так канонічно вони мають різні значення, але вони все ще представляють базовий характер.

Канонічна еквівалентність - це те, коли послідовність байтів надає той самий символ із тим самим значенням. Еквівалентність сумісності - це те, коли послідовність байтів надає інший символ з тим самим базовим значенням (навіть якщо він може бути змінений). 9 і ⁹ є еквівалентом сумісності, оскільки вони обидва означають "9", але не є канонічно еквівалентними, оскільки не мають однакового представлення.

Чи буде більш доречним для вас канонічна еквівалентність чи сумісність, залежить від вашої заявки. Спосіб роздуму ASCII про порівняння рядків приблизно орієнтується на канонічну еквівалентність, але Unicode представляє багато мов. Я не думаю, що можна припустити, що Unicode кодує всі мови таким чином, що дозволяє поводитися з ними так само, як західноєвропейський ASCII.

На малюнках 1 і 2 є хороші приклади еквівалентності двох типів. Згідно з еквівалентністю сумісності, схоже, що однакове число у формі суб- та супер-скрипту порівняно б рівним. Але я не впевнений, що вирішить ту саму проблему, що і курсивна арабська форма або обертаються символи.

Важка правда обробки тексту Unicode полягає в тому, що вам потрібно глибоко задуматися над вимогами щодо обробки тексту вашої програми, а потім вирішити їх, як можна, за допомогою доступних інструментів. Це безпосередньо не стосується вашого питання, але більш детальна відповідь потребує мовних експертів для кожної з мов, які ви очікуєте на підтримку.

Проблема порівняння рядків : два рядки із вмістом, еквівалентним для більшості програм, можуть містити різні послідовності символів.

Див . Канонічну еквівалентність Unicode : якщо алгоритм порівняння простий (або повинен бути швидким), еквівалент Unicode не виконується. Ця проблема виникає, наприклад, у канонічному порівнянні XML, див. Http://www.w3.org/TR/xml-c14n

Щоб уникнути цієї проблеми ... Який стандарт використовувати? "розширений UTF8" або "компактний UTF8"?
Використовувати "ç" або "c + ◌̧."?

W3C та інші (наприклад, імена файлів ) пропонують використовувати "складені як канонічні" (майте на увазі C "найкомплектніших" коротших рядків) ... Отже,

Стандарт - C ! сумнівайтеся, використовуйте NFC

Для інтероперабельності та для вибору "конвенції щодо конфігурації" рекомендацією є використання NFC для "канонізації" зовнішніх рядків. Наприклад, для зберігання канонічного XML, наприклад, зберігайте його у "FORM_C". CSV W3C у Веб-робочій групі також рекомендує NFC (розділ 7.2).

PS: de "FORM_C" - це форма за замовчуванням у більшості бібліотек. Вих. в нормалізаторі PHP.isnormalized () .

Термін " композиційна форма" ( FORM_C) використовується для обох, щоб сказати, що "рядок знаходиться в С-канонічній формі" (результат перетворення NFC) і щоб сказати, що використовується алгоритм перетворення ... Див. Http: //www.macchiato.com/unicode/nfc-faq

(...) кожна з наступних послідовностей (перші дві є односимвольними послідовностями) представляють один і той же символ:

1. U + 00C5 (Å) ЛАТИНСЬКИЙ КАПІТАЛ ЛІТИН А З КОЛЬЦОМ НАД
2. U + 212B (Å) АНГСТРОМ ЗНАЧ
3. U + 0041 (A) ЛІТИНСЬКИЙ КАПІТАЛЬНИЙ ПІСЛЯ A + U + 030A (̊) ОБ'ЄДНАННЯ КОЛЬКОГО ПРОБЛЕМУ

Ці послідовності називаються канонічно еквівалентними. Перша з цих форм називається NFC - для форми нормалізації C, де C - для композиції . (...) Функція, що перетворює рядок S у форму NFC, може бути скорочена як toNFC(S), а функція , яка перевіряє, чи є S у NFC, скорочується як isNFC(S).

Примітка: для перевірки нормалізації невеликих рядків (чисті посилання UTF-8 або XML-сутності) ви можете використовувати цей тест / нормалізувати онлайн-конвертер .