Digitális és informatikai

Azonosnak látszó szöveg, eltérő találat: Unicode-normalizálás import előtt

Két magyar címke látszólag megegyezhet, miközben eltérő karakterláncként szerepel. Külön összehasonlítási kulccsal elkerülhető a hamis duplikáció és az eredeti adat elvesztése.

Dajka Gábor6 perc olvasás

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.

Négy rekorddal ellenőrizd, melyik szabály von össze neveket

Készíts négy saját próbát: az első „Szőlő” előre összeállított ő betűkkel, a második ugyanennek felbontott ékezetes alakja, a harmadik „szőlő” kis kezdőbetűvel, a negyedik pedig „Szőlő” egy záró szóközzel. Mindegyikhez külön rekordazonosító tartozzon.

Az összehasonlítás szabályaEgyedi kulcsok számaMi marad megkülönböztetve?
Nyers karakterlánc4Mind a négy bemenet
Csak NFC3A kezdőbetű és a záró szóköz eltérése
NFC, majd kisbetűs összehasonlítás2A záró szóköz eltérése
NFC, kisbetűs összehasonlítás és a szélső szóköz levágása1Ebben a négyes mintában nincs eltérő kulcs

A forrásrekordok száma mindvégig négy. A háromról kettőre csökkenő kulcsszámot a kisbetűsítés, a kettőről egyre csökkenőt a szóközkezelés okozza. A naplóban ezért külön műveletként rögzítsd őket. A teljes folyamat második futása ugyanazt a kulcsot adja; ha tovább változik az adat, a lépések sorrendjét és az alkalmazott szabályokat is vizsgáld meg.

Egy külön ellenpélda az m² és az m2. NFC mellett különböznek, NFKC után azonos karakterlánccá válhatnak. Egy műszaki megjegyzésben a felső index jelentéssel bírhat. Az ilyen találatot ne vond össze egy általános „minden hasonló szöveg azonos” szabállyal. A Unicode-szabvány kanonikus és kompatibilitási alakjai pontosan ezt a kétféle egyezést különítik el.

A hasonló alakú latin és cirill betű külön eset

A latin a kódpontja U+0061, a cirill а betűé U+0430. Sok betűkészletben nagyon hasonlítanak egymásra, de ez a két betű NFC és NFKC után is különbözik. A normalizálás tehát nem általános eszköz minden szemre hasonló név összevonására.

A Unicode összetéveszthető karakterekről szóló leírása ezt külön problémaként kezeli. Ha egy importmezőben meghatározott írásrendszert vársz, az attól eltérő betűt jelöld ellenőrzésre, és őrizd meg az eredeti értéket. Ne cserélj automatikusan minden hasonló betűt latinra: egy valóban cirill nevű termék vagy személy adatát ez megváltoztatná.

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.

Záró tudáspróba

Válassz kérdésenként egy választ. A megoldások ellenőrzése után minden helyes válaszért 1 pontot adj magadnak; a hibás, kihagyott vagy több válasszal megjelölt kérdés 0 pont. Összesen 0–3 pont szerezhető.

1. A kétféle felépítésű ő betű NFC után egyezik. Mit bizonyít ez?

  • A) A két teljes forrásrekord üzletileg is azonos.
  • B) A két betűfelépítés kanonikusan egyenértékű.
  • C) Az eredeti UTF-8 bájtok is azonosak voltak.

2. A négy próbából csak NFC használatával hány egyedi kulcs marad?

  • A) 1
  • B) 4
  • C) 3

3. Miért kíván külön döntést az m² és m2 NFKC szerinti összevonása?

  • A) A kompatibilitási átalakítás a felső index megkülönböztetését is eltünteti.
  • B) Az NFC minden számjegyet töröl.
  • C) A szövegek hossza alapján biztosan azonos a jelentésük.

Megoldások és pontszám

1. B. Az NFC a kanonikus karakteregyezést vizsgálja. A nyers bájtok és a rekordok jelentése ettől még különbözhet.

2. C. Az előre összeállított és felbontott Szőlő egy kulcs lesz. A kis kezdőbetű és a záró szóköz külön-külön eltérés marad.

3. A. Az NFKC a ² jelet 2-re alakítja. Ez technikai egyezést hoz létre, de az adott műszaki adatban jelentős különbséget fedhet el.

3 pont: A kódolási egyezést és a további tisztítási szabályokat is elkülönítetted. Saját importodban a négyes mintával ellenőrizd a kulcsszám változását.

2 pont: Az 1. kérdéshez az ő betű kódpontjait, a 2.-hoz a négyrekordos táblázatot, a 3.-hoz az m² ellenpéldáját ismételd át.

0–1 pont: Először csak NFC-t alkalmazz a négy próbára, és írd melléjük a kapott kulcsokat. A kisbetűsítést és a szóközlevágást utána külön ellenőrizd.

További cikkek

Kapcsolódó olvasnivalók

Gyorskereső

Kalkulátorok és útmutatók keresése

↑↓ választásEnter megnyitásEsc bezárás