Problem sa Mysql import-om / unosom Latin2 karaktera

Imam ozbiljan problem oko prenosa podataka sa Mysql 4 na Mysql 5 bazu:

Stare Mysql 4.0.20 baze (latin1 swedish) exportujem u .sql. Tada je sve u .sql fajlovima latin2 enkodinga i to lepo vidim iz svih klijenata (kedit, firefox, console...)

Problem nastaje kada to treba importovati ili unositi rucno u nove Mysql 5 baze.
Probao sam dosta stvari:
- definisao latin2 u my.cnf za sve promenljive (character setove, colacije), rucno dodaovao SET NAMES, SET CHARACER SET...
- definisao latin2 po konfiguracionim fajlovima klijenata (phpmyadmin...)
- promenio locale promljive (LANG, LC_ALL...) i (u i18n i iz konzole) u linuxu na sr, sr_latin2
- probao importe sa mysql, mysqlimport naredbama, phpmyadmin, MySQL Browser... - ucitava ih sa znakovima pitanja (???) umesto nasih karaktera
- probao na raznim verzijama mysql i mysql-max serverima dosta verzija 5.0.xx
- probao na raznim operativnim sistemima feodra, mandriva, vista, 32 i 64 bita...


SHOW variables LIKE 'charac%';

| character_set_client | latin2
| character_set_connection | latin2
| character_set_database | latin2
| character_set_filesystem | binary
| character_set_results | latin2
| character_set_server | latin2
| character_set_system | utf8
| character_sets_dir | /usr/share/mysql/charsets/

Ni na koji nacin ne mogu importujem i na drugi nacin ubacim u bazu nase latin2 karaktere.
Tabele i baze su normalno definisane u latin2, a probao sam i razne kolacije latin2_general_ci, latin2_bin...

Nijedan drugi enkoding mi ne igra jer je stotine i hiljade stranica uradjeno u njemu, nikakve preporuke da predjem na utf-8 i slicno ne dolaze u obzir.
Da li neko ima slican problem i kako ga resava? Hvala unapred...

Potpis

http://www.linuxsrbija.net http://www.poslovnisvet.com

Pa sad - jel' latin1 ili latin2?

Potpis

Kad sve ostalo zakaže, pročitaj uputstvo...

Na Mysql serveru 4.0.20 i nema bas izbora - encoding je latin1 swedish. Tako je kompajliran, iako nisam ja kompalirao bas taj server vec je tako dosao uz distibuciju.
Kada se u takvu bazu ubacuju nasi karakteri u latin2 encoding-u (iz php aplikacije ili phpmyadmin-a recimo, ti karakteri se cuvaju kao hijeroglifice :) u samoj bazi). Medjutim, svi klijenti te karaktere citaju kao latin2 (ako se tako definise), tako i kad exportujem bazu, bilo preko phpmyadmin-a ili mysqldump-a.

Znaci, .sql fajlovi koje imam, koji su mi i beckup ovog MySQL-a 4.0.20, su zasigurno latin2 (iso-8859-2) jer kada ih otvorim u bilo kom klijentu sa tim i jedino tim encodingom vidim nase karaktere (openoffice-a, kate, kwrite, kdeveleop, dreamveaver...).

Ono sto je problem jeste import tih fajlova. Mada, napominjem, da ni rucno (nekim INSERT-om ili UPDATE-om) ne mogu ubaciti bilo kakarav karakter latin2 encodinga u jasno definisane latin2 baze, sa latin2 varijablama mysql-a, phpmyadmina etc... Ono sto je interesantno, jeste da se ponekad, kod tako importovanih fajlova vide nasa slova, ali iskljucivo u UTF-8 encodingu, koji je ujedno i default encoding MySQL-ova 5 i kompajliran je tako.

Ajd, jos prostije. Napravimo bilo kakav latin2 fajl sa par naredbi i unesimo ga u MySQL 5.xx latin2 bazu. Ili rucno. Sta dobijate?

Potpis

http://www.linuxsrbija.net http://www.poslovnisvet.com

Ajde snimi deo tog sql fajla gde imas hijeroglife pa zakaci ovde. Meni deluje da je tu izvrsena konverzija prilikom unosenja iz latin2 u latin1 kako ih zoves (pretpostavljam da je to ISO-8859-1 I ISO-8859-2 a ne WIN-1250), i da kad ih ubacujes u bazu sa latin2 - onda on dodatno te hijeroglife pretvara iz latin1 u latin2 i tu napravi tek haos.

Resenje bi bilo da isto bazu postavis na latin1, on ce je ubaciti fino - kao original hijeroglife, a charset opis stranice ce mu reci da to bez konvertovanja ispise u latin2 i sve ce biti ok.

Potpis

Kad sve ostalo zakaže, pročitaj uputstvo...

Par cinjenica:

MySQL Server 4.0.x nema podrsku za karakter setove.
MySQL Server 4.0, 4.1, 5.0, 5.1 latin1 nije ISO/IEC 8859-1 vec "malo" promenjeni latin1 (ista prica i za latin2)

Na zalost, najsigurniji upgrade, bez gubitka karaktera sa 4.0 je "preko" 4.1, dakle, uradite upgrade na 4.1 pa onda na 5.0. Trebalo bi da funkcionise ista procedura i direktno na 5.0 ali to toliko dugo nije testirano da se i dalje savetuje 4.0 -> 4.1 -> 5.0 ako se koriste karakteri koji nisu "ascii7"

Pogledaj ovaj link.

Kratko uputstvo za upgrade sa 4.0 na 5.0

1. pre bilo cega - napravite bekap (najlakse je da zaustavite MySQL Server i iskopirate ceo datadir direktorijum na sigurno)

recimo da imamo tabelu:



u `latin1f` smo cuvali "latin1 enkodovane stringove", u `latin2d` smo cuvali "latin2 ekodovane stringove" i u `utf8f` smo cuvali "utf8 enkodovane stringove"

?kako je to moguce kada MySQL 4.0 ne podrzava karakter setove?

Lako, upisuje ih binarno i ne interpretira ih, "podska za karakter setove" znaci da je RDBMS svestan u kom formatu je podatak sacuvan, u kom formatu ga dobija od klijenta i u kom formatu ga klijent trazi nazad te u letu radi potrebnu konverziju. MySQL 4.0 nema tu podrsku te sve to prima, salje i cuva "binarno".




Dakle ovde imamo klasican primer navedenog, klijent salje i ocekuje karaktere kao "latin2", RDBMS toga apsolutno nije svestan i cuva te karaktere binarno, dakle ovo je primer " `latin2f` CHAR(50), "

Dump sa 4.0 -> Restore na 4.1 ovde nece mnogo pomoci, nego prvo, promenimo onu nasu tabelu tako da one karakter setove koji nisu latin prebacimo u ono sto oni zapravo jesu:


Zaustavimo server i uradimo upgrade sa 4.0 -> 4.1
Startujemo MySQL 4.1 na postojecim podacima i sada ponovo promenimo ona dva polja u "valjane" tipove sa definisanim karakter setom:


onda opet to lepo sve ugasimo, uradimo upgrade na 5.0
startujemo mysql_upgrade script po zavrsetku upgrade-a da isproverava i update-uje tabele i spremni smo za rad

Obratite paznju da se mnogo toga promenilo od 4.0 do 5.0, neke od tih promena nisu kompatibilne
na linku za upgrade 4.1 -> 5.0 mozete naci listu nekompatibilnih izmena izmedju 4.1 i 5.0
a na linku za upgrade sa 4.0 -> 4.1 mozete naci listu nekompatibilnih izmena od 4.0 do 4.1

EDIT: code tag ne radi "word wrap" ubi se da nadjem sto mi siri div :)

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Resen je problem jos ranije, ali koga zanima:
Import MySQL baza, koje sam prethodno exportovao u fajlove (sa definicijama tabela) je uspeo tako sto sam kreirao prvo baze u latin2 encodingu sa croatian_ci kolacijama (ima sva redjanja kao srpska laticina, ostali latin2 nemaju). Onda, iz konzole, koja nije bitno u kom je encodingu, ucitavam definicije i podatke sa:

Posto je sustina "problematike" u uspostavaljanju veze izmedju klijenta(console, phpmyadmin, php, java.. aplikacija...) i Mysql servera, bitno je da klijentu kazete kojim enkodingom da se poveze sa doticnim MySQL serverom, posto svi volsebno uzimaju razlicita podesavanja, neki iz definicije my.cnf ya klijente, neki zasebno, neki sa sistema.... Ja to radim tako sto, prilikom uspostavljanja konekcije sa bazom u php-u odmah nakon konekcije opalim jednu naredbu kojom mu u stvari kazem u kom enkodingu ocekujem podatke:
MySQL 5 sam radi konverziju podataka u letu podataka, sto ce reci, ako su podaci u latin2 enkodingu u bazi, u tabeli ili na drugom mestu, Vi mozete da izvlacite upitom jednu tabelu u utf8 recimo, a drugu u latin2 ili cp1250... dok god su enkodinzi "kompatibilni". To se lepo vidi kada koristite phpmyadmin u recimo default-nom utf8 enkodingu, ubacuje podatke u definisanu bazu latin2, a on sam vrsi automatsku konverziju. Lepo, elegantno, brzo.

Potpis

http://www.linuxsrbija.net http://www.poslovnisvet.com