UTF8 -> ISO8859-2

Adatbázis: SQL, XML DB

Sziasztok,

Nem biztos hogy a legjobb helyen nyiitottan ezt a témát ezért elnézést kérek.
Van mysqldump-om UTF8 kodolással ezt én iso-8859-2-re szeretném kodolni iconv-vel probáltam de a (őű-ŐŰ)-t egyszerüen kihagyta a játékból.
iconv -f UTF8 -t ISO88592 -o konvert.sql dump.sql parancsal probáltam.

Van-e valakinek ötlete hogy kellen konvertálni?

Köszi
P.Zoli

  • 8457 megtekintés

( LiRul v | 2006. 04. 11., k – 07:35 )

miert lenne amugy neked erre szukseged? 4-es mysqltol felfele mar van korrekt charset es collation kezeles, automatikus konverziokkal. pl. utf8-ban van minden adatod a tablakban, de lekerdezeskor te latin2-ben kapod vissza, ha ugy kered.

Erre pont azért van szükség, mert 4-es mzsqltől felfele nincs korrekt charset és collution kezelés. Amióta berakták, rengeteget szívás van vele, főleg azért, mert:
1) alapból swedish-re rakja, nemtom mi a f*ért. Az sem segít, ha átállítom, minden mezőnek külön meg kell adni create table-nél, hogy collate utf8 ha biztos akarsz lenni
2) a mysqldump képtelen kezelni a kódlapokat, nekem pl akkor adja vissza jól az utf8-at, ha latin1-ben kérem le...
3) connect után ki kell adni a set names utf8 és set charset utf8 sql parancsokat, ha jót akarsz.

Egyébként meg ez az egész egy baromság szvsz, ha egy adatbázisba berakok egy értéket adott kulcsra, akkor a kulcsot lekérve bitre ugyanazt az adatot akarom, amit beraktam, nem másikat. Ez az egész kódlap mizéria egyáltalán nem tartozik az adatbázisrétegre, az a megjelenítési réteg dolga lenne...

Hibás beállítás a szerveren vagy az adatbázison?

Először is az adatbázisnak kell beállítani a collation-t, utána a tábláknak már automatikusan azt adja, az új mezőknek pedig a tábla collation-jét használja. Nem ismerek olyan beállítást, ami ezt a működést felülírná.

--
http://sandor.czettner.hu

Tudom, hogy ezereves topic, de azert "segitek".

"Egyébként meg ez az egész egy baromság szvsz, ha egy adatbázisba berakok egy értéket adott kulcsra, akkor a kulcsot lekérve bitre ugyanazt az adatot akarom, amit beraktam, nem másikat."

Semmi problema, allitsd a kulcson kivul az osszes mezot blob (vagy binary vagy mittomen) tipusura es ezt a funkcionalitast kapod.

"Ez az egész kódlap mizéria egyáltalán nem tartozik az adatbázisrétegre, az a megjelenítési réteg dolga lenne..."

Azert tartozik a DB retegre, mert valaki ugy dontott, hogy az SQL szabvanyban legyen "order by", ami abc rendet is tud. Ehhez ismernie kell a binaris adatot betukke konvertalo kodlapokat. (Az mar csak nyalanksag, hogy az abc nyelvenkent valtozo (abcd vs aábccsd), lasd collation.)

( toshy | 2006. 04. 11., k – 07:46 )

Szerintem hagyd a konvertalast es csinalj masik dumpot.
Ehez peddig hasznald a "--set-charset" opciot !
En is szivtam mar ezzel, es ez megoldotta !

( xsak v | 2006. 04. 11., k – 08:16 )

Ha nem lehet másik dump-ot csinálni, akkor javaslom a gedit/kate/ConTEXT programok valamelyikét (gnome/kde/winjajj). Az első kettőnél biztosan meg lehet adni megnyitáskor és mentéskor a karakterkészletet...
A ConTEXT-ben meg (ha Winbe vagy szorítva) van lehetőség a konvertálásra.

Én nagyon bunkó módon, de az OpenOffice-t használom a legtöbbször ilyen célra...

Bár van valahol egy perl scriptem is, ami Unicode-ból CP1250/51/52/53/54/57-be konvertál, és az alapértelmezettől eltérőket tag-eli (Quark és Ventura szövegfájlokat gyártottam vele anno)

Baromi primitív módon felvettem a táblákat a 128-as kódtól, és a kódlaphasználati sorrendnek megfelelően feltöltöttem vele egy 64k elemű tömböt, ahol minden elem tartalmazza a megfelelő karaktert, és ha szükséges, akkor a közrefogó tag-et is. Utána egy regex egyszerűen megoldja a problémát:
s/[^\x00-\x7F]/$replace[ord($&)]/eg

Azért primitív, mert pl. azok a karakterek, amelyek egyik kódlapon sem szerepelnek, eltűnnek.

( egmont | 2006. 04. 11., k – 13:35 )

> iconv-vel probáltam de a (őű-ŐŰ)-t egyszerüen kihagyta a játékból.
> iconv -f UTF8 -t ISO88592 [...]

Fogadni mernék hogy azért hagyja ki mert nem ilyen betűk szerepelnek utf8-ban, hanem hullámos-kalapos változatok. Próbáld meg iso8859-1-re konvertálni, ha ekkor jók lesznek az ékezetek, akkor én nyertem. Ebben az esetben (ha magyar szöveget tárolsz utf8-ban) nagyon-nagyon el van rontva valami, mert valójában nem is utf8-ban tárolod, hanem egy abszolút nem szabványos egyéni kódolásban.

( Kayapo | 2006. 04. 21., p – 22:21 )

Ha az a gáz hogy a visszaállításkor egy csomó kriXkraX lesz az ékezetek helyén, akkor, jobb ha tudod, az iconv nem tud rajtad segíteni:
utf8_max_len = 3
latin2_max_len = 1
tehát az utf-8 as karakter hárpm bájtot használ amig a latin2 csak egy bájtot.

Inkább illesztd be a dumb első soraiba: 


set character_set_client=utf8;
set character_set_connection=utf8;
set character_set_database=latin2;

A MySQL elvégzi a megfelelő konverziót (a módszer ki van próbálva megy), de hagy szabadjon megjegyeznem, hogy az utf-8 kódolással szélesebb körű kompatibilitáshoz jutsz (még ha kanjit nem is akarsz használni).

( zoner | 2011. 02. 18., p – 12:59 )

Nem tudom, hogy a parancssoros iconv-al is működik-e, de Ruby-val így lehet csinálni:

ic = Iconv.new('ISO-8859-2//IGNORE//TRANSLIT', 'UTF-8')
ic.iconv(str)

//IGNORE és //TRANSLIT kapcsolók sorrendje számít, de neked szerintem csak a translit kell. Lehet, hogy az ő-kből o betüt csinál

--
http://sandor.czettner.hu