[megoldva] MYSQL - utf-8 karakter íródott latin2-es adatbázisba

Adatbázis: SQL, XML DB

Probléma:

Adott egy latin2-es adatbázis, a netkapcsolat a szerver és a desktop közt megszakad, az addig latin2 kapcsolat helyett a továbbiakban utf-8-ban kommunikál (programozó állítása szerint, lehet nem utf8, de nem latin2-ben), és az ő-ű karakterek helyén valami szemét lesz. Adatbáziskezelő ?-nek jelzi.

(A desktop program nem az enyém, nekem kinyernem kell adatokat innen, egy webes felületen. A desktop program módosítása "nem lehetséges". A fenti állításokat nem volt még eszközöm ellenőrizni, a problémát nem tudom reprodukálni, csak az adatbázisokhoz van hozzáférésem, desktop programom nincs.)

1. kérdés:

A fenti esetben, az adatbázisba ténylegesen "?" kerül be, vagy a nem-latin2-es karakter jelenik meg így, és ott van az adat?

(Nem értek a karakterkódolásokhoz, és a MYSQL működéséhez hibakezelés ügyben.)

2. kérdés: (feltételes, csak akkor aktuális ha előzőre az a válasz, hogy "nem ? kerül be ténylegesen")

Van-e mód ezen karaktert tartalmazó sorok MYSQL lekérdezésben való lekérésére, tehát SQL szinten tudok-e rá szűrni?

  • 4708 megtekintés

( vl v | 2013. 07. 01., h – 16:04 )

Ha az adatbázis latin2, nem utf8, akkor minden oda bekerült karaktert ki tudsz nyerni, akár latin2-re, akár utf8-ra állított kliens kapcsolaton keresztül kérdezed. Ergó ha ?-t kapsz, akkor az adatbázisban is ? van.
Ami logikus, ha bármilyen, latin2-ben nem ábrázolható karaktert kapott a szerver. Tipikus példa: latin1-ben kalapos ő/ű érkezik, amit latin2-ben nem lehet ábrázolni.
Az egyedüli eset, amikor az adatbázis rendben van, de te ?-t kapsz, ha az adatbázistól eltérő, de nem utf8-ra állított klienssel próbálkozol kinyerni az adatokat. Ilyen esetben a helyes megoldás az adatbázissal egyező, vagy utf8 használata a kliens kapcsolaton.

Gyakorlatilag akkor már a letároláskor "?" kerül be, mert a latin2-es adatbázisból latin2-es kliensen "?" jön vissza. Jól értem?

Van bármilyen megoldás, ami a desktop alkalmazás módosítása nélkül megoldhatja a problémát? Rendszergazda oldalról a kapcsolat nekem érthetetlen, hogy miért utf-8-al jön létre szakadás után, illetve hogy miért nincs erre valami default beállítási lehetőség.

Van bármilyen megoldás, ami a desktop alkalmazás módosítása nélkül megoldhatja a problémát?

A már elveszett adatot természetesen semmi nem fogja pótolni.

Egyébként a helyes megoldás, hogy
- az legyen az alkalmazás és a szerver közötti kapcsolaton a karakterkódolás, amiben az adatok az alkalmazásban előállnak (ha latin2-t beszél az alkalmazás, akkor latin2, ha utf8-at, akkor utf8),
- az adatbázis karakterkódolása vagy legyen utf8, vagy egyezzen meg az előző sorban levő értékkel.

A szerver és a kliens közti karakterkódolást alapvetően a kliens választja meg. Ha az alkalmazásba nincs belehardkódolva a dolog, akkor a mysql kliens konfig fájlja dönti el. Szerintem simán lehet, hogy valaki mysql klienst "upgradelt" az alkalmazás alatt...
Az utf8 nem valószínű, mert akkor az összes többi ékezet is elkúródott volna. A latin1 hihetőbb.

Kezdek arra gyanakodni, hogy a rendszergazda oldaláról alapból latin1-re van állítva a kapcsolat, amikor nem kap kapcsolódáskor jelzést hogy milyen legyen a kódolás, akkor latin1-re visszaáll, és netszakadáskor nem küld a program latin2-t.

Egyébként köszönet a segítséget, mostmár tiszta a kép.

Nekem hihetőbb az a verzió, hogy a mysql kliens alapból latin1, az alkalmazás első kapcsolódáskor átállítja a kapcsolatot latin2-re, majd a reconnect, az az alkalmazástól függetlenül történik: pl. a kliens visszaad egy hibaüzenetet, erre az alkalmazás újrapróbálkozik, ekkor pedig a kliens automatikusan újra kapcsolódik a szerverhez, de erről az alkalmazás nem tud, ezért nem állítja be a karakterkészletet magának megint.
Szóval go and edit mysql kliens konfig fájl.