Tři vrstvy textové hodnoty
Člověk vidí text, někdy včetně znaménka spojeného s předchozím písmenem. Unicode přiřazuje abstraktním znakům kódové body a kódování, například UTF-8, mění tyto body na bajty pro uložení nebo přenos. Jeden viditelný znak může zahrnovat více kódových bodů a jeden bod může zabrat více bajtů UTF-8. Počet bajtů proto nemusí odpovídat počtu písmen ani znaků vnímaných uživatelem. Nástroj text na kódové body ukazuje hodnoty Unicode v řetězci; text na bajty UTF-8 ukazuje jinou vrstvu. Tyto pohledy pomáhají diagnostikovat rozdíl, nelze je však bez znalosti kódování příjemce libovolně zaměňovat.
Dva zápisy slova café
Viditelné slovo café může končit jediným kódovým bodem U+00E9, LATIN SMALL LETTER E WITH ACUTE. To je složená podoba. Může končit také bodem U+0065 pro obyčejné e a následně bodem U+0301 pro kombinující čárku. Druhá podoba má o jeden kódový bod více, ačkoli text často vypadá stejně. V UTF-8 má složené slovo hexadecimální bajty 63 61 66 C3 A9; rozložené slovo 63 61 66 65 CC 81. Jde o různé posloupnosti bajtů, takže přesné porovnání či hash se mohou lišit. NFC tento příklad převede na složenou sekvenci, NFD na rozloženou. Vložený převodník ukazuje tyto bajty desítkově: 99 97 102 195 169 u složené a 99 97 102 101 204 129 u rozložené podoby. Porovnejte je s hexadecimálním zápisem výše.
- café: U+00E9 → konec C3 A9
- café: U+0065 U+0301 → konec 65 CC 81
- NFC ⇢ složené · NFD ⇢ rozložené
Co normalizace dělá a nedělá
Normalizace Unicode určuje způsoby zápisu kanonicky ekvivalentních sekvencí. NFC po rozložení provádí kanonické složení, zatímco NFD ponechá kanonicky rozloženou sekvenci. Pomáhá při porovnávání textu z různých klávesnic, souborů nebo systémů. Nepřekládá slova, neodstraňuje diakritiku a nezaručuje shodu všech vizuálně podobných řetězců. Některé podobné znaky pocházejí z odlišných písem nebo mají jiný význam. Kompatibilní formy NFKC a NFKD mohou měnit i širší rozdíly v zápisu, proto je vyberte jen tehdy, když to účel dovoluje. Při porovnávání, indexování a hashování používejte stejné pravidlo normalizace; jinak se podobně vypadající vstupy dál rozejdou.
Spolehlivý postup při hledání chyby
Když se jméno neshoduje, nejprve zachovejte původní vstup. Prohlédněte jeho kódové body: je přízvuk součástí předem složeného znaku, nebo samostatným kombinujícím znaménkem za písmenem? Pak zkontrolujte bajty UTF-8, které skutečně projdou přes API nebo se zapíšou do souboru. Kopie normalizujte na NFC a NFD, porovnejte výsledné body a opačným převodníkem bajtů UTF-8 ověřte platnost a očekávané dekódování. Při výměně souborů zapište zvolené kódování výslovně, nespoléhejte na předvolenou volbu každého programu. Náhradní znak často ukazuje na chybu dekódování; normalizace již špatně dekódovaného řetězce ztracené původní bajty neobnoví.
Zvolte správné porovnání
Při přesné kontrole integrity souboru, hashů a podpisů rozhodují bajty: jiná normalizace změní bajty, a tím i otisk. Při vyhledávání pro uživatele nebo hledání duplicit může produkt normalizovat předem, ale měl by toto pravidlo vysvětlit a otestovat. Velikost písmen, interpunkce, mezery a jazykově závislé řazení jsou samostatné otázky; NFC je nevyřeší. Při zobrazení nebo exportu potichu neměňte uživatelův zápis, pokud to postup nevyžaduje. V nástrojích níže začněte slovem café a prohlédněte jeho bajty UTF-8. Potom vložte podobu napsanou jako e s kombinujícím znaménkem do nástrojů kódových bodů a normalizace. Uvidíte, v jaké vrstvě se malý vizuální rozdíl projeví. Pokud zpracováváte více souborů, napište do importního postupu i pravidlo, kdy se normalizuje: před porovnáním, před indexováním, nebo až při zobrazení. Stejné pravidlo potom vyzkoušejte na původním i kombinovaném zápisu. Jen tak se rozdíl nevrátí v dalším kroku aplikace. Při přesném archivním uložení zachovejte také původní řetězec.