2. Fórumok
  3. Szoftverfejlesztés
  4. MySQL topic
Keresés

Új hozzászólás Aktív témák

  • #183 Rici tag Panther #182
    Új Válasz #183
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Rici

    tag

    válasz Panther #182 üzenetére

    A hullámos ő és rendes ő, illetve kalapos ű és rendes ű általában elég sok galibát tud okozni. A dolog mélyén az van, hogy egyik latin kódtábla sem tartalmazza egyszerre ezeket a karaktereket, a hullámos és kalapos változat a latin1-ben szerepel, a rendes magyar változat meg a latin2-ben. Tehát amíg a feldolgozásban részt vevő összes program nem utf8 vagy ucs2 kódolással dolgozik, addig tuti nem lehet egy szövegen belül a hullámos és rendes magyar változatot is látni, valahová kérdőjelek vagy egyebek fognak kerülni.

    Egyébként az lenne a követendő, hogyha a websiteok mind utf8-cal működnének, és az adatbázisokban is utf8-cal vagy kétbájtos (ucs2) karakterkódolással lennének tárolva az adatok, akkor nem lenne probléma a karakterkészletekkel, mert igazából mindig ott jön be a gond, amikor konvertálás történik, és az új karakterkészlet nem tud ábrázolni bizonyos karaktereket. Az utf8 és az ucs2 pedig ''minden'' Unicode karaktert tud ábrázolni, csak mégsem használják, pedig már elég régóta ki lettek találva.

  • #181 Rici tag VladimirR #180
    Új Válasz #181
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Rici

    tag

    válasz VladimirR #180 üzenetére

    Amit a mysqld súgója ír ki, az valószínűleg távol áll az igazságtól. A phpmyadmin által megadott értékek már jobban néznek ki. Igazából azt kellene tudni, hogy milyen program is akar hozzáférni valójában az adatbázishoz, gondolom egy php alapú site-ról van szó, a phpmyadmin csak karbantartasra van, ha jól gondolom.

    Röviden összefoglalom, hogy hogyan is működik ez a karakterkészlet dolog: amikor a szerver eltárol egy sztringet, azt egy bájtsorozatként tárolja el, és a szerver / adatbázis / tábla / oszlop szintjén meg lehet határozni, hogy az eltárolt bájtsorozatot hogyan is kell értelmezni (milyen karakterkódolásban van). De ez igazából csak a mysql szerver számára fontos, hogy pl. hogyan hasonlítsa össze a bájtsorozatokat rendezéskor. Tehát ez a tárolási kódolás, ami pl. a character_set_server vagy a character_set_database változó értéke, ill. a táblákhoz és oszlopokhoz rendelt tárolási kódolást a SHOW CREATE paranccsal lehet megnézni. Ennek a tárolási kódolásnak a kliens felé menő lekérdezések szempontjából sok jelentősége nincs, legfeljebb annyit érdemes tudni, hogy a latin_ kezdetű dolgoknál 256 féle-karaktert lehet tárolni, az ucs2- és utf-8 kódolással pedig a Unicode kódtábla alsó 65536 karakterét.

    Amikor a mysql kliens felé jönnek sztringek vagy a kliens küld sztringeket, akkor ugyebár azok is egy bájtsorozat formájában léteznek, és hozzájuk is tartozik egy karakterkódolás, hogy hogyan is kell értelmezni a bájtsorozatot. Itt jön a lényeges, a kliens számára is érdekesebb rész. A kliensnek meg kell mondania, hogy mi is legyen ez a bizonyos kódolás, amivel szeretné a sztringek bájtsorozatát megkapni. A konverziót a szerver automatikusan elvégzi. Elméletileg tehát mindegy, hogy miben van tárolva a sztring, a szerver mindig azzal a kódolással küldi, amivel a kliens kéri. Persze a konverziónál bekerülhetnek kérdőjelek a sztringekbe, mert pl. egy utf8-ban tárolt arab betűt nem lehet egy 256 féle karaktert támogató latin2 karakterkódolással ábrázolni. És persze az ő/ű betűk is ebbe a kategóriába tartozhatnak, ha pl. utf8-ról latin1-re kell konvertálni, de pl. utf8-ról latin2-be már menniük kell. Gyakorlatilag persze nyilván érdemes abban tárolni a sztringeket, amiben le lesz kérdezve, mert akkor nem kell a szervernek állandóan konvertálgatni.

    Ezek a kliens oldali dolgok a character_set_client, character_set_connection, és character_set_results változókban vannak tárolva, amiket a megfelelő paranccsal a kliensnek be kell állítania, mert alapból nem számíthat rá, hogy a szerver pont abban küldi, amiben a kliens gondolná.

    Általában itt szokott lenni a gond. Pl. ha egy .php oldal iso-8859-2 kódolással küldi az oldalakat a böngésző felé, de az adatbázisból utf8-cal kéri le a sztringeket, akkor ott gáz lesz. (feltéve ha nem használ maga a php karakterkonvertálást az iconv_ vagy a mb_ függvényekkel.)

    Tehát a lényeg: a kliensnek kapcsolódás után pl. egy SET CHARACTER SET latin2; és SET NAMES latin2; parancsot kell kiadnia, és akkor már latin2-ben érkeznek a válaszok.

    Egyébként ez az egész karakterkódolás téma _nagyon_ összetett, de ha tényleg át akarod látni, akkor nagyon ajánlom, hogy nézz utána, hogy pl. mi is az a Unicode, az utf8 kódolás, a latinX kódolások stb.

  • #179 Rici tag VladimirR #178
    Új Válasz #179
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Rici

    tag

    válasz VladimirR #178 üzenetére

    Nézd meg, hogy mit ad ki a SHOW VARIABLES; parancs végrehajtása, és az eredményből a character_set -tel és collation_ -nel kezdődő sorok közül az összeset írd le ide. Akkor remélhetőleg okosabbak leszünk, és tudunk továbblépni.

Új hozzászólás Aktív témák