中文 PHP-ben

Nemrégiben az a gondolatom támadt, hogy írok egy kínai szótárat. Mármint kínai–magyar szótárat, természetesen, hiszen kínai–angol már rengeteg van. A igazán megérdemli, hogy az ember behatóbban foglalkozzon vele.
  Ami azt illeti, a munkában alig-alig jelent hátrányt, hogy nem tudok kínaiul. Épp csak egy kicsikét. Most a programozási részéről szeretnék mesélni.
  Mivel online szótár lesz, logikusan PHP-ben készül, bár az is igaz, hogy a munka legnagyobb részét az adatok megírása teszi ki. Van egy kedvenc adatbázis-formátumom, amit ősidők óta minden célra előszeretettel alkalmazok, az olvasónak is csak ajánlani tudom. A sima szöveg. Előkelőbb nevén plaintext vagy ASCII text, illetve jelen esetben, mivel kínairól van szó, UTF-8 szöveg. Nincs párja, sokkal egyszerűbb és kényelmesebb, mint a mindenféle SQL-ek meg Excelek meg egyéb trükkös dolgok.
  Ebben a formátumban vannak a nyers adatok, amik nem lesznek részei a kész szótárnak. Én mindig az olyasféle markupolást szerettem, ami így néz ki:

hozzávalók
tojás
tej
liszt
élesztő
felszerelés
keverőtál
fakanál
műveletek
keverd össze

Az utasítások sor elején vannak, minden jelzés nélkül, a program is arról ismeri föl őket, amiről a szerzője: hogy szerepelnek az utasítások listájában [array('hozzávalók', 'felszerelés', 'műveletek')]. Például a szócikkekben használok ilyeneket, megjelölni a szócikk különböző szakaszait, amik aztán a végleges adatbázis különböző mezeibe kerülnek. Máskor meg olyan szövegeket használok, amiket karakterenként kell értelmezni, és aszerint, hogy a karakter micsoda, mást és mást kell vele csinálni.
  A végleges adatbázis viszont PHP-ben van. Minden adatbázis egy-egy PHP tömb, benne az adatokkal. Ez a módszer a LAttilaD.org statisztikamotorjánál tökéletes kudarcot „aratott”, örökké eltörtek a tömbök, teljes leállást okozva – itt viszont a file-okat egyszer megírjuk, aztán csak olvassuk, többé nem változtatunk rajtuk.
  A szótár előállításánál rengeteg aprólékos művelet van, amikre általában egyszer használatos programokat írok. Van egy „sokszor egyszer használatos” programom is, ami csak arra kell, hogy a forrásfile-okból előállítsa a végleges adatbázist, aztán eldobom, de valahányszor elkészülök a forrásfile-ok egy-egy újabb részletével (néhány új szócikkel vagy mással), lefuttatom, hogy megnézhessem az adatbázist a különböző viewerekkel. Ez utóbbiak még csak lassan készülgetnek, csak néhány van meg belőlük vázlatosan.
  Most a rekurzív dekompozíciót mutatom be. Az olvasó bizonyára pontosan tudja, hogy az micsoda, de ha mégsem, akkor elmondom. Én találtam ki, eddig még egyetlen szótárban se láttam effektíve működés közben.
  Mint tudjuk, minden írásjegynek van egy gyöke. Például a jel gyöke a szív, alul. A szótárak gyökkeresőiben a felhasználó csak rábök a gyökre, és máris megtalálja a jelet. („Máris”… a gyökhöz éppenséggel 581 írásjegy tartozik, ha csak a sima CJK tartományt nézzük.)
  No igen, de mi van, ha a felhasználó nem tudja, hogy mi a gyöke? Mert lehet a vagy a is. Vagy ha csak nem ismeri föl a gyököt? Például a jelben elég nehéz felismerni a szívet, ha az ember nem tudja, hogy ezt az alternatív alakot is fölveheti. Végezetül pedig: a szívhez tartozó 581 jelet általában már csak a vonások száma szerint szokták csoportosítani, ami azt jelenti, hogy számolgatni kell; például a tíz, a tizennyolc vonást tartalmaz a gyökön felül.
  De mi van, ha szétszedjük az írásjegyeket? Mondjuk, hogy a felhasználó felismerte a szívet és a holdat , és azokat az írásjegyeket szeretné látni, amik szívet és holdat egyaránt tartalmaznak. Abból vajon mennyi van?
  Pillanatnyilag nem tudom a választ, de a szótár eddig feldolgozott részében csak ez az egy.
  Ez tehát a dekompozíció: összetevőikre bontani az írásjegyeket. Rekurzív attól lesz, hogy a forrásfile-okban az egyes írásjegyeknek csak a közvetlen összetevőik vannak. Például a két részből áll, és . De miből áll a ? Oda kell menni és megnézni. De az is állhat további részekből – és így tovább. Az eddig feldolgozott részben akadnak olyan írásjegyek, mint például a , amit tíz részre lehet fölszeletelni, vagy a , amit tizenháromra. Legalábbis a jelenlegi helyzet szerint, mert ha némelyik alkotóelemük még nincs feldolgozva, akkor azok később tovább bomolhatnak.
  Később majd persze felület is lesz hozzá, amin az felhasználó bejelölheti, hogy mely alkotóelemek szerepelnek az általa keresett írásjegyben – de ezt addig nem tudom létrehozni, amíg sejtelmem sincsen, hogy hány alkotóelem kerül ki a szótárba tervezett több mint négyezer írásjegyből. Eddig alig 489 darabot dolgoztam föl belőlük, és máris van 394 alkotóelemem, de utóbbi szám növekedésének előbb-utóbb le kell állnia. A kérdés az, hogy akkor még áttekinthetőek lesznek-e egyben vagy ravaszkodásokra lesz szükség.

»»»»»»