Weblabor

A Weblabor adatbázisa vidáman él (korábbi verziókról való frissítés okán) latin-1-esnek beállított, de UTF-8-as adatokat tároló tábla beállításokkal, hiszen az adatbázis kiszolgálónak mindegy, hogy milyen kódolású táblában milyen adatokat tárolunk, egészen addig, amíg sorrendezni nem kell az adatokat, vagy (ezesetben sajnos) indexet nem kell készíteni hozzájuk. Itt jönnek ugyanis a galibák. Ha felismertetjük a MySQL szerverrel a valós magyar karaktereket, rögtön kiderül, hogy a program azt állítja, hogy tud magyarul, de mégsem.

A probléma egyrészt ott jelentkezik, hogy ha olyan adatokat szeretnénk sorrendezni, amit a MySQL valamiért azonosnak tekint. Ilyenkor nem fogunk helyes sorrendet kapni a magyar nyelv szabályai szerint. Ez azonban még a kisebb probléma. Nagyobb gond, hogy ha indexünk is van egy adott mezőre, akkor nem fogunk tudni beilleszteni olyan mezőket, amikkel "egyenértékű" már van az adatbázisban. Az egyenértékűséget itt a használt egybevetés alapján dönti el a MySQL, lásd Bártházi András cikkét a témában.

Sajnos mi is szembesültünk ezzel a problémával, ugyanis a Weblabor Drupal 4.6-ról 5.0-ra történő frissítése során az egyik kellemesnek szánt mellékhatás, hogy a kellően magas MySQL verziószámot látva a Drupal valós utf8 kezelésre téríti át az adatbázist. Nos, eközben meg is kaptuk az adatbázistól, hogy nem lehet "Nagy Peter" és "Nagy Péter" nevű felhasználónk, hiszen ezek az egybevetés szerint azonosak. Itt jelentkezett számunkra a hiba, bár nyilván nem csak a Nagy Péterek érintettek a problémában, a hibakereséshez ez is kiváló információt adott. Nem is kellett messzire menni, hiszen épp a napokban volt nálunk szó erről a problémáról.

A szálakat felgöngyölítve úgy tűnik, hogy még a 3.23-as vagy még korábbi MySQL verzióban egy magyar adta meg a jelenleg is használt magyar nyelvi egybevetése szabályokat a MySQL fejlesztői számára. Ugyanazokat az egybevetése szabályokat használja a MySQL függetlenül attól, hogy latin2 vagy utf8 alapú kódolást használunk. Mivel esetünkben az utf8 alapú kódolásnál jelentkezett a hiba, megnéztem, hogy mégis mi a konkrét probléma az egybevetéssel. Készítettem egy kis programot erre a célra:Az egyszerű ellenőrző szkript célja, hogy kiderüljön: a gyakorlatban milyen problémákat okoz a hibás magyar összevetés. Ennek érdekében utf8 kódolással mentettem el a teszt fájlt, és mindkét karaktersorozatnál megadtam, hogy utf8 kódolással kezelje a MySQL, valamint kényszerítettem ezen belül a magyar összevetést (ez még András cikkében nem szerepelt, azóta jelent meg). Lássuk egy OpenOffice.org-ban színezett eredménytáblán, hogy mit kapunk:

Az ábrán a zöld színűek a helyes sikeres egybevetések (kis és nagybetűkre nem érzékeny összehasonlítás lévén a kis és nagybetűk azonosnak tekintendők). A kék színek a helyes sikertelen egybevetéseket jelzik, ahol tehát nem szabad azonosnak tekinteni két karaktert, és a MySQL jól is viselkedik. A piros (sajnos többségben lévő) szín pedig a hibás egybevetéseket jelöli, tehát ahol nem szabadna azonosnak tekinteni a két karaktert a magyar helyesírás szabályai szerint, a MySQL mégis így tesz. Ez azt jelenti, hogy nem lehet például szurok és szúrok az értéke két sorban egy egyedinek definiált mezőnek, pedig ezek teljesen mást jelentenek a magyar nyelvben.

Mit lehet mégis tenni a probléma ellen? Gondolhatnánk, hogy ha hibás a magyar egybevetés, akkor próbálkozzunk az utf8_general_ci-vel. Átírva a fenti szkriptben az egybevetést legalább egységes képet kapunk: minden tesztelt esetben egyes értéket kapunk, azaz a MySQL ilyenkor minden magyar betűt minden ékezetes formájával és minden nagybetűs ékezetes formájával is azonosnak tekint. Így például nem lehet szúr és szűr egy egyedinek definiált mezőben, hiszen egybevetés szerint ezek azonosak (ugyanez a kettős még az utf8_hungarian_ci szerint lehetséges). A helyzet tehát legfeljebb annyiban jobb, hogy most már nincsenek kivételek, egységesen minden ékezetes karakter hibás.

Törekedhetünk viszont arra, hogy javuljon a helyzet! A MySQL álláspontját Peter Gulutzan foglalta össze a 12519-es MySQL hibajelentésben. Egyrészt linkeket ad mások hibajelentéseire, elismerve, hogy nem jó a MySQL működése ebben az esetben. Másrészt viszont lehetőleg hivatalos magyar álláspontra vár, azaz egy angol nyelvű hivatalos dokumentumra, ami a magyar helyesírás vonatkozó szabályait részletezi. Elvégre is a több kapcsolódó hibajelentést is beküldő magyar fejlesztők véleménye ugyanúgy csak vélemény, mint az eredeti magyar egybevetést beküldő álláspontja, akinek a fenti ábrából is láthatóan érdekes elképzelései voltak a magyar karakterek egyenértékűségéről. Ha már kijavítják a hibát, szeretnék a hivatalos szabályokat figyelembe venni. Ha minden jól megy, a MySQL valamikori későbbi verziójába kerül egy javított, más nevű egybevetés, és a jelenlegi helytelen magyar egybevetést idővel kiveszik a rendszerből. Ehhez elsősorban egy hivatalos dokumentumra lenne szükség, úgyhogy aki segíteni tud ebben, az ne habozzon!

Hogy a Weblabor számára mi lesz a rövid távú megoldás, az egyelőre nyitott kérdés. Lehetséges, hogy megpróbálunk együtt élni a MySQL adott hibájával, és néhány felhasználónkat név módosításra kell kérnünk az ütközések elkerülése érdekében. Lehetséges, hogy bináris egybevetést kell alkalmaznunk, aminél értelemszerűen ilyen problémák nem merülnek fel, hiszen ott csak a binárisan pontosan megegyező karaktersorozatok azonosak. Sajnos egyik sem túl csábító út.