Unicode-normalizáló

Az Unicode néhány karaktert többféleképpen is leírhat. Az é betű lehet egyetlen kódpont, az U+00E9, vagy egy sima e, amelyet kombináló akut ékezet követ, U+0065 U+0301. A kettő a képernyőn azonosnak látszik, ugyanúgy nyomtatódik, sztringként viszont különbözik: más a hosszuk, más az UTF-8 bájtjuk, és a 'é' === 'é' értéke false.

Ez nem kuriózum, hanem hibaosztály. Az, hogy az egyik vagy a másik alakot kapjuk, a billentyűzetkiosztástól, az operációs rendszertől, a beviteli módszertől és attól függ, hogy a szöveget másolták-e szövegszerkesztőn keresztül. Egy jelszóellenőrzés, egy adatbázis egyedi indexe, egy tiltólista vagy egy gyorsítótár-kulcs, amely bájtonként hasonlítja a sztringeket, a két írásmódot két különböző értékként kezeli — így a felhasználó egyik eszközön beállíthat egy jelszót, és másikról nem tud belépni, és ugyanaz a szó kétszer szerepelhet a „már foglalt” nevek listáján.

Azért van a felosztás, mert két különböző célt szolgáltak. A szöveg összerakása és szétbontása kanonikus változtatás: az eredmény ugyanazt jelenti, és az első két alaknál nem vész el semmi. A ligatúrák, felső indexek, körbe zárt betűk és teljes szélességű alakok összevonása kompatibilitási változtatás: az illesztés kényelméért történik, és valóban megszünteti a különbséget két olyan sztring között, amelyeket az Unicode különbözőnek mond. A négy alak a két döntés összes kombinációja.

A fenti táblázat ennek az oldalnak az adatfájljából származó esetlista, a platform saját String.prototype.normalize függvényével ellenőrizve, és az Önellenőrzés minden sorát újra ellenőrzi a szemünk előtt. Az első két sort együtt olvassa: ugyanaz a szöveg két írásmódban, és normalizálás után ugyanaz a sztring.

Ezek azok a sztringek, amelyeken a Minta gomb végigvezet; az oldal élőben normalizálja őket, nem válaszként beírva. Mindegyiket azért választották, mert valamelyik alak látható hatással van rá.

Az NFKC és az NFKD veszteséges, és a veszteség szándékos. Arra a kérdésre felelnek: „ugyanaz-e a szó”, nem arra, hogy „ugyanaz-e a sztring”. Ebből három következmény adódik, amelyeket éles kódban könnyű elrontani:

• Jelszót, tokent vagy aláírást soha ne tároljunk kompatibilitási formában. Két különböző bemenet ugyanarra a tárolt értékre esne, ami a hossz- vagy karakterellenőrzést gyengébbé teszi. A jelszavakat NFC-vel kell normalizálni (vagy egyáltalán nem), és bájtonként összehasonlítani, miután mindkét oldalon pontosan ugyanazt végeztük el.
• A kompatibilitási redukció egy karakterből többet is csinálhat. Az fi ligatúra egy kódpont, amely két betűvé válik, így a normalizálás előtt hossz szerint ellenőrzött mező a normalizálás után hosszabb lehet. Előbb normalizálni kell, aztán ellenőrizni, majd tárolni.
• Az NFKC nem távolít el mindent, ami láthatatlan. A változatválasztó átvészeli az NFKC-t és az NFKD-t, és a nulla szélességű összekötő is. Ezért van a vizsgálati mód: a normalizálás egy karakter alakjára és azonosságára kérdez rá, a vizsgáló pedig arra, hogy valami egyáltalán jelen van-e.

A normalizálás a második számot változtatja meg, az elsőt általában nem. A három szám mind „a szöveg hossza”, és mind különbözik, ezért egy 20 karakteres korlátú űrlapmező olyan sztringhez tartozhat, amely 20 kódpont, 30 UTF-16 egység és 47 bájt hosszú.

A grafémaoszlopban lévő szám az, amit egy ember megszámol. A köztük lévő különbség és a kódpontok száma pontosan arról szól, amiről a vizsgáló szól: 12 kódpontból álló név megjelenhet 12 betűként, 3 betűként 9 láthatatlan jellel közöttük, vagy egyetlen emojiként.

A nulla szélességű szóköz nem foglal helyet, nem változtat glifet, és valódi karakter valódi kódponttal. Két azonosító, amely a képernyőn azonosnak látszik, egy ilyen karakterben különbözhet, így a listában lévő név hamis lehet, amely másként rendeződik, keres és hitelesít, mint a mellette lévő név. Ugyanez igaz a kétirányú vezérlőkre is, amelyek úgy jelenítenek meg egy sztringet, hogy a megjelenési sorrend eltér az írás sorrendjétől — ezt a trükköt már fájlnevek álcázására használták.

A harmadik módban a vizsgáló mindegyiket felsorolja a helyével együtt: nulla szélességű és összekötő karakterek, kétirányú vezérlők, változatválasztók, szokatlan szóközök, C0- és C1-vezérlőkarakterek, magánhasználatú kódpontok, és olyan helyettesítő, amely nem érvényes pár fele, így az egyáltalán nem karakter. Az oldal fenti osztálytáblázata elmondja, mit tesz mindegyik osztály, az eltávolító gomb pedig a karakterek másolatát távolítja el, a bemenetet érintetlenül hagyva.

• Két sztring összehasonlítása normalizálás nélkül. A 'é' === 'é' hamis. Mindkét oldalt ugyanazzal a formával kell normalizálni az összehasonlítás előtt, és ugyanazt a formát kell használni a keresett indexben is.
• Csak az egyik oldal normalizálása. Az a keresés, amely a lekérdezést normalizálja, de a tárolt értéket nem, semmit nem talál, és inkább adatproblémának látszik, mint normalizálási problémának.
• Kompatibilitási alakkal stilizált űrlap biztonságos NFC-ként kezelése. Az NFKC egy jelszóra alkalmazva csökkenti a lehetséges jelszavak terét, és olyan bemeneteket olvaszt össze, amelyeknek különbözniük kellene.
• Azt feltételezni, hogy egy normalizálási forma megold egy hamisítást. Nem távolítja el a nulla szélességű összekötőt, a változatválasztót vagy a homoglifát — a cirill а és a latin a különböző kódpontok, amelyeket az NFC érintetlenül hagy.
• Egy karakterszámban való bizalom. A felhasználó által látott szám, az adatbázis-oszlop által érvényesített szám és a bájtkorlát által érvényesített szám három különböző szám, és a fenti sorok megmutatják, mennyire távol lehetnek egymástól.
• Azt feltételezni, hogy az NFC lesz az, amit kap. A beviteli módszerből, fájlból vagy másik rendszerből érkező szöveg abban az alakban van, amilyet az a rendszer előállított. Ez az oldal az NFC-vel indul, mert a web ezt az alakot várja, nem azért, mert ez a bemenet alakja.

“Miért nem egyenlők ezek a sztringek, ha azonosnak látszanak?”

Mert az egyiket összerakott karakterrel, a másikat alapbetű plusz kombináló jellel írták, vagy az egyik olyan karaktert tartalmaz, amely egyáltalán nem rajzol semmit. Átváltva az Összehasonlítás módra, egy-egy sztring helyezhető mindkét dobozba: az oldal megmondja az első pozíciót, ahol a normalizált sztringek eltérnek, és azt, hogy mi van ott mindkettőben.

“Melyik alakot használjam egy alkalmazásban?”

Az NFC mindenre, amit ember olvas, megjelenít, tárol és keres, ez az alak ajánlott a weben a W3C szerint. Az NFD akkor a helyes válasz, ha a mögöttes kód alapbetűket és külön jeleket vár, ami szövegfeldolgozásban és egyes macOS-fájlrendszerekben gyakori. Az NFKC vagy NFKD csak ott használandó, ahol illesztés történik, nem tárolás: keresőindexekben, kulcsszűrőkben, duplikátum-felismerésben.

“Normalizált marad-e a már normalizált sztring, miután hozzáfűzök valamit?”

Nem feltétlenül. A normalizálás nem őrződik meg összefűzéskor: két NFC-sztring összefűzése olyan sorozatot adhat, amelyet az NFC másként írna, mert a második sztring elején álló kombináló jel az első sztring végi karakteréhez kapcsolódhat. Összeállítás után normalizálni kell, nem csak előtte.

“Eltávolítja a normalizálás a láthatatlan karaktereket?”

Nem, egy részleges kivétellel: az NFKC és az NFKD a nem törő szóközt közönséges szóközre cseréli, ami a kompatibilitási redukció látható eredménye. Minden más — nulla szélességű szóközök, összekötők, kétirányú vezérlők, változatválasztók — mind a négy alakon változatlanul átmegy. Erre szolgál a harmadik mód.

“Miért változik a bájtszám, ha a karakterszám nem?”

Mert a két alak különböző kódpontokból épül fel, amelyek az UTF-8-ban eltérő számú bájtba kerülnek. Az összerakott é két bájt; a szétbontott pár három. A fenti számláló-táblázat mind a négy számot egymás mellett kiírja a bemenetre és minden alakra, így a különbség látható, nem csak leírva.

“Honnan tudom, hogy az oldal eredményei helyesek?”

az Önellenőrzés gomb megnyomható. Minden esetet normalizál az oldal adatfájljából, újra ellenőrzi a négy alakot egymással a dokumentált összefüggésekre (az NFC idempotens, egy NFC-sztring NFD-je ugyanaz, mint az eredeti NFD-je, és így tovább), minden láthatatlan és vezérlő táblázatban nevezett karaktert átvezet a vizsgálón, és a grafémaeseteket az Intl.Segmenter eredményével veti össze.

A négy alak és definíciói az Unicode Standard 15. melléklet (Unicode Normalization Forms) szövegéből származnak. A bontási példákban használt kódpontokat a szabvány rendeli hozzá; ez az oldal nem implementálja a bontási táblázatokat — a böngésző saját String.prototype.normalize függvényét hívja, amely ugyanaz az implementáció, amelyet a platform a szövegbevitelhez, rendezéshez és összehasonlításhoz használ, így az itt jelentett eredmény azt mutatja, mit kezd a rendszer többi része ugyanazzal a sztringgel. A grafémaklasztereket a böngészőben elérhető Intl.Segmenter adja, ahol nincs, dokumentált közelítésből.

Az oldal szövegét ehhez a webhelyhez írták. Minden kidolgozott példát az oldal saját kódja állított elő, majd az adatfájl rögzített esetlistájával ellenőrizték, amelyet ugyanazon karakterek Unicode NormalizationTest-adataival vetettek össze. A láthatatlan és veszélyes karakter-táblázatok egy kurált részhalmaz, emberi olvasásra szánt figyelmeztetésekhez, nem a teljes Unicode biztonsági profil (UTS #39), és az oldal ezt kimondja, nem sugall olyan teljességet, amelyet nem nyújt.