Egy termékimport után kétszer jelenik meg ugyanaz a kategória. A két név szemre azonos, mégis külön találatként szerepel a keresőben. Ilyenkor érdemes a szóközök és az írásjelek mellett a Unicode-karakterek felépítését is ellenőrizni. Egy ékezetes betű többféle, egymással kanonikusan egyenértékű kódsorozatból állhat.
Ez különösen akkor érdekes, amikor több rendszerből érkező magyar szövegeket egyeztetsz. A látható címke, az eredeti bájtsorozat és a kereséshez készített összehasonlítási kulcs három eltérő feladatot szolgálhat. Ezek megőrzése megbízhatóbb, mint az eredeti adat visszafordíthatatlan átírása.
Egyetlen ő betűn is megmutatható
Az ő előállhat a U+0151 kódpontból. Ugyanennek kanonikusan egyenértékű felbontása az o betű U+006F kódpontja és a kombináló kettős éles ékezet U+030B kódpontja.
Az első alak egy kódpont és UTF-8 kódolásban két bájt. A felbontott alak két kódpont, összesen három UTF-8 bájt. A megjelenítésük megfelelő betűkészlet mellett azonosnak látszhat, a nyers karakterláncok összehasonlítása viszont eltérést ad.
A Unicode normalizálási szabványa határozza meg többek között az NFC és NFD alakokat. A példában mindkét bemenet NFC-re alakítva ugyanahhoz az ő karakterhez jut. Ez a kanonikus egyezés vizsgálata; nem általános helyesírás-javítás.
Külön kulcsot készíts az egyeztetéshez
Tegyük fel, hogy két forrásból egy-egy „Szőlő” kategórianév érkezik, eltérő Unicode-felbontással. A saját importfolyamatod őrizze meg a forrásazonosítót és az eredeti nevet. Mellé készülhet egy dokumentált NFC összehasonlítási kulcs.
A kulcsok egyezése alapján a rendszer jelölheti a két rekordot kézi ellenőrzésre. Ettől még a két forrásrekord nem válik automatikusan ugyanazzá a kategóriává. Az egyik rendszerben a címke gyümölcsöt, a másikban akár díszítőmintát is jelölhet. A technikai egyezés és az üzleti azonosság külön ellenőrzést kíván.
Hasznos importnapló például: eredeti rekordok száma kettő, egyedi nyers címkék száma kettő, egyedi NFC-kulcsok száma egy. Így a változást pontosan meg tudod magyarázni, és az eredeti adatok visszakereshetők maradnak.
Ne csomagolj minden javítást egyetlen műveletbe
Az NFC-normalizálás nem teszi kisbetűssé a szöveget, nem törli az ékezeteket, és nem vonja össze automatikusan a felesleges szóközöket. Ezek külön döntések. Egy azonosítóban a kis- és nagybetű vagy a szóköz jelentős lehet, miközben egy egyszerű keresési kulcsban más szabályt szeretnél.
A kompatibilitási normalizálás, például az NFKC, további megkülönböztetéseket is eltüntethet. Ezért a hasonló nevű műveleteket ne tekintsd felcserélhetőnek. Egy matematikai jelölés vagy formázott azonosító eltérő adatkezelést igényelhet, mint egy termékkategória.
A szöveg-összehasonlítóban az eredeti és az átalakított szöveget külön is megvizsgálhatod. A szövegtisztító egyéb tisztítási feladatokhoz kapcsolódik; a megnyitott eszköz által ténylegesen támogatott műveletet ellenőrizd, ne feltételezz automatikus NFC-átalakítást.
Az ellenőrzőösszeget az eredeti adathoz kösd
Ha egy fájl sértetlenségét vizsgálod, az eredeti bájtok számítanak. Két kanonikusan egyenértékű szöveg nyers UTF-8 bájtjai eltérhetnek, ezért különböző ellenőrzőösszegük lehet. Az import előtti és utáni hash ilyenkor jogosan különbözik.
Aláírt üzenetet, jelszót vagy hitelesítési tokent ne alakíts át általános címketisztítási szabállyal. A hozzá tartozó protokoll előírása az irányadó. Az adatminőségi naplóban külön jelöld a nyers sértetlenségi ellenőrzést és a normalizált tartalmi egyezést.
Gyakori kérdések
Az NFC eltünteti a magyar ékezeteket?
Nem. A kanonikusan egyenértékű felépítéseket egységesíti. Az ő betűből nem készít egyszerű o betűt.
Minden egyező normalizált nevet összevonhatok?
Csak az üzleti azonosítók és a jelentés ellenőrzése után. Különböző termékeknek vagy kategóriáknak lehet azonos nevük.
A karakterszámláló eltérő eredménye biztosan hibás?
Nem feltétlenül. Kódpont, kódegység és felhasználó által érzékelt karakter eltérő számlálási egység lehet. A mutató definícióját is rögzíteni kell.