Normalizátor Unicode

Unicode dáva pre niektoré znaky viac než jeden spôsob zápisu. Písmeno é môže byť jediný kódový bod, U+00E9, alebo obyčajné e za ktorým nasleduje kombinujúca akútová značka, U+0065 U+0301. Obe vyzerajú na obrazovke rovnako, vytlačia sa rovnako, a ako reťazce sú rôzne: majú iné dĺžky, iné bajty UTF-8 a 'é' === 'é' je false.

To nie je zvedavosť, je to trieda chýb. To, či sa dostane jedna alebo druhá forma, závisí od rozloženia klávesnice, operačného systému, vstupnej metódy a od toho, či sa text niekedy skopíroval cez textový procesor. Kontrola hesla, jedinečný index databázy, zoznam zakázaných alebo kľúč vyrovnávacej pamäte, ktorý porovnáva reťazce bajt po bajte, bude obe podoby považovať za dve rôzne hodnoty — takže používateľ môže nastaviť heslo na jednom zariadení a nemôže sa prihlásiť z iného a to isté slovo sa môže v zozname „už obsadených“ mien objaviť dvakrát.

Rozdelenie existuje, pretože slúžia dva rozdielne ciele. Zloženie a rozklad textu je kanonická zmena: výsledok znamená to isté a pri prvých dvoch formách sa nič nestráca. Zjednotenie ligatúr, horných indexov, krúžkovaných písmen a plnošírkových tvarov je zmena kompatibility: robí sa kvôli pohodlnosti porovnávania a naozaj zrušuje rozlíšenie dvoch reťazcov, ktoré Unicode považuje za rozdielne. Štyri formy sú všetky kombinácie oboch rozhodnutí.

Tabuľka vyššie je zoznam prípadov z dátového súboru tejto stránky, overený voči vlastnému String.prototype.normalize platformy, a Samotest každý jej riadok znovu overí pred zobrazením. Prvé dva riadky sa čítajú spoločne: je to ten istý text zapísaný dvoma spôsobmi a po normalizácii je to ten istý reťazec.

Toto sú reťazce, ktorými prechádza tlačidlo Vzorka; stránka ich normalizuje naživo namiesto toho, aby ich ponúkala ako hotové odpovede. Každý bol vybraný preto, že na ňom forma urobí niečo viditeľné.

NFKC a NFKD sú stratové a strata je zámerná. Odpovedajú na otázku „je to to isté slovo“, nie na otázku „je to ten istý reťazec“. Z toho vyplývajú tri dôsledky, všetky sa v produkčnom kóde ľahko pokazia:

• Heslo, token ani podpis sa nikdy neukladajú v tvare kompatibility. Dva rôzne vstupy by sa zlúčili do rovnakej uloženej hodnoty, čo kontrolu dĺžky alebo znakov oslabí. Heslá sa normalizujú cez NFC (alebo vôbec) a porovnávajú sa ako bajty po tom, čo sa na oboch stranách urobí presne to isté.
• Zhodnocovanie kompatibility môže jeden znak premeniť na niekoľko. Ligatúra fi je jeden kódový bod, ktorý sa stane dvomi písmenami, takže pole overené na dĺžku pred normalizáciou môže byť po nej dlhšie. Najprv sa normalizuje, potom overí a až potom uloží.
• NFKC neodstráni všetko neviditeľné. Výberový znak variácie prežije NFKC aj NFKD a rovnako nulová spojka. Preto má táto stránka režim skenovania: normalizácia odpovedá na otázku o tvare a identite znaku, skener odpovedá na otázku, či tam niečo vôbec je.

Normalizácia mení druhý z týchto počtov a zvyčajne prvý nechá tak. Všetky tri čísla sú „dĺžka textu“ a všetky sú rôzne, a preto môže pole s limitom 20 znakov obsahovať reťazec, ktorý má 20 kódových bodov, 30 jednotiek UTF-16 a 47 bajtov.

Číslo v stĺpci grafém je to, čo človek spočíta. Rozdiel oproti počtu kódových bodov je presne to, čím sa zaoberá skener: meno zložené z 12 kódových bodov sa môže zobraziť ako 12 písmen, ako 3 písmená s 9 neviditeľnými značkami medzi nimi, alebo ako jedno emoji.

Nulová šírka medzery nezaberá žiadnu šírku, nemení glyf a je to skutočný znak so skutočným kódovým bodom. Dva identifikátory, ktoré vyzerajú na obrazovke rovnako, sa môžu líšiť práve jedným z nich, a tak môže meno v zozname byť podvrhnuté: triedi sa, vyhľadáva a overuje inak než meno vedľa neho. To isté platí pre obojsmerné riadiace znaky, ktoré môžu spôsobiť, že reťazec sa vykreslí v inom poradí, než v akom bol zapísaný — tento trik sa použil na maskovanie názvov súborov.

Skener v treťom režime vypíše každý z nich s pozíciou: nulová šírka a spojky, obojsmerné riadiace znaky, výberové znaky variácií, nezvyčajné medzery, riadiace znaky C0 a C1, kódové body súkromného použitia a náhradný znak, ktorý nie je polovicou platnej dvojice, čo vôbec nie je znak. Tabuľka tried vyššie na tejto stránke hovorí, čo každá trieda robí, a tlačidlo odstránenia odstráni kópiu týchto znakov bez toho, aby sa dotklo vstupu.

• Porovnávanie dvoch reťazcov bez normalizácie. 'é' === 'é' je nepravda. Obe strany sa normalizujú rovnakou formou pred porovnaním a rovnaká forma sa použije aj v indexe, s ktorým sa porovnáva.
• Normalizácia iba na jednej strane. Vyhľadávanie, ktoré normalizuje dopyt, ale nie uloženú hodnotu, nič nenájde a vyzerá to ako problém s dátami, nie s normalizáciou.
• Štylizovanie formulára formou kompatibility a označenie za bezpečné pre NFC. NFKC aplikovaný na heslo zmenší priestor možných hesiel a zlúči vstupy, ktoré mali byť rozdielne.
• Predpoklad, že normalizačná forma opraví podvrh. Neodstráni nulovú spojku, výberový znak variácie ani homoglyf — cyrilské а a latinské a sú rôzne kódové body, ktoré NFC nechá tak, ako sú.
• Dôverovanie počtu znakov. Počet, ktorý vidí používateľ, počet, ktorý vynucuje stĺpec databázy, a počet, ktorý vynucuje limit bajtov, sú tri rôzne čísla a riadky vyššie ukazujú, ako ďaleko od seba môžu byť.
• Predpoklad, že text je už v NFC. Text, ktorý príde zo vstupnej metódy, zo súboru alebo z iného systému, je v tej forme, akú vytvoril ten systém. Táto stránka začína na NFC, lebo to je forma, ktorú web očakáva, nie preto, že to je to, čo je na vstupe.

„Prečo nie sú tieto dva reťazce rovnaké, keď vyzerajú rovnako?“

Pretože jeden z nich je zapísaný zloženým znakom a druhý základným písmenom plus kombinujúcou značkou, alebo jeden obsahuje znak, ktorý sa vôbec nekreslí. Prepne sa do režimu Porovnanie a jeden reťazec sa vloží do každého políčka: stránka nahlási prvú pozíciu, kde sa normalizované reťazce líšia, a čo je na tej pozícii v každom z nich.

„Ktorú formu mám použiť v aplikácii?“

NFC pre všetko, čo bude čítať, zobrazovať, ukladať a vyhľadávať človek; je to forma, ktorú W3C odporúča pre web. NFD je správna voľba, keď kód na strane spracovania chce základné písmená a samostatné značky, čo je bežné pri spracovaní textu a v niektorých súborových systémoch na macOS. NFKC alebo NFKD sa použijú len tam, kde sa niečo zhoduje, a nie ukladá: vyhľadávacie indexy, filtre kľúčových slov, detekcia duplicít.

„Zostáva reťazec, ktorý je už normalizovaný, normalizovaný aj po tom, čo k nemu niečo pripojím?“

Nie nutne. Normalizácia sa spojením nezachováva: spojenie dvoch reťazcov NFC môže vytvoriť postupnosť, ktorú by NFC zapísalo inak, lebo kombinujúca značka na začiatku druhého reťazca sa môže pripojiť k znaku na konci prvého. Normalizuje sa až po zostavení, nie len pred ním.

„Odstraňuje normalizácia neviditeľné znaky?“

Nie, s jednou čiastočnou výnimkou: NFKC a NFKD nahradia nezalomiteľnú medzeru obyčajnou medzerou, čo je viditeľný výsledok zhodnotenia kompatibility. Všetko ostatné — nulové medzery, spojky, obojsmerné riadiace znaky, výberové znaky variácií — prejde všetkými štyrmi formami nedotknuté. Na to slúži tretí režim.

„Prečo sa mení počet bajtov, keď sa počet znakov nemení?“

Pretože tieto dve formy sú zostavené z rôznych kódových bodov, ktoré v UTF-8 stoja rôzny počet bajtov. Predskladané é sú dva bajty; rozložený pár sú tri. Tabuľka počtov vyššie vypíše všetky štyri čísla vedľa seba pre vstup a pre každú formu, takže rozdiel je viditeľný, nie len opísaný.

„Ako viem, že výsledky na tejto stránke sú správne?“

Kliknutím na Samotest sa normalizuje každý prípad v dátovom súbore tejto stránky, znovu overí štyri formy voči sebe navzájom pre zdokumentované vzťahy (NFC je idempotentné, NFD reťazca NFC je rovnaké ako NFD pôvodného atď.), prevedie každý znak uvedený v tabuľkách neviditeľných a riadiacich znakov skenerom a porovná počty grafém s Intl.Segmenter.

Štyri formy a ich definície pochádzajú z Unicode Standard, Annex 15 (Unicode Normalization Forms). Kódové body použité ako príklady rozkladu sú tie, ktoré štandard priraďuje; táto stránka nevykonáva tabuľky rozkladu sama — volá vlastné String.prototype.normalize prehliadača, teda rovnakú implementáciu, akú platforma používa na vstup textu, triedenie a porovnávanie, takže to, čo sa tu uvádza, je to, čo s tým istým reťazcom robí zvyšok systému. Zhluky grafém pochádzajú z Intl.Segmenter, ak ho prehliadač má, a z zdokumentovanej aproximácie, ak nie.

Text stránky bol napísaný pre tento web. Každý prepracovaný príklad na tejto stránke vytvoril kód tejto stránky a potom bol overený voči zaznamenanému zoznamu prípadov v dátovom súbore, ktorý bol zase overený voči dátam NormalizationTest Unicode pre tie isté znaky. Tabuľky neviditeľných a nebezpečných znakov sú kurátorská podmnožina napísaná na čitateľné upozornenia, nie úplný bezpečnostný profil Unicode (UTS #39), a stránka to hovorí otvorene, namiesto toho, aby naznačovala úplnosť, ktorú nemá.