Dotaz: MySQL a fatalni chyba v kodovani ....

[svaca]

Ahoj, mam "asi" neresitelny problem, jelikoz jsem vul.

Mam aplikaci a ta ma SQL databazi, celou databazi co mam v SQL mam vytvorenou s porovnavanim Lati1, webova aplikace bezi samozrejme v UTF-8, proste jsem vul, co si nenastavil to porovnavani na UTF-8 jako default pro tu danou databazi, takze ted to funguje uplne normalne, protoze webova aplikace sice zapisuje do databaze rozsypany caj (z UTF8 do Latin1) , ale zpatky to cte spravne (z LATIN1 do UTF8).

Vysledek je, ze to sice cele funguje, ale JA NEMUZU tokovy paskvil zalohovat, protoze dumpnuli to a vratim to zpet, tak se to cele zlikviduje .. Otazka je jak z toho ven ? Je to uz ostry provoz, Jedine co me napada je vydumpnout to a cele to prepsat rucne, ale jedna se o tisicezaznamu, takze SMRT.

Existuje nejake reseni ? Dekuji.

Odpovědi

[iSteve]

Verze MySQL je predpokladam 4.1/5?

zkus spis udelat dump, upravit kodovani pri vytvareni tabulek a naimportovat.. ale samozrejme testuj to mimo ostry provoz:)

[svaca]

5.0.24 to nejde dump vypada takto:

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

-- 
-- Dumping data for table `ab_addressbooks`
-- 

INSERT INTO `ab_addressbooks` (`id`, `user_id`, `name`, `acl_read`, `acl_write`) VALUES 
(1, 1, 'Admin, Group-Office', 36, 37),
(5, 4, 'Holub, Jaroslav', 62, 63),
(6, 5, 'Svacina, Petr', 64, 65),
(7, 7, 'Láník, Karel', 72, 73),

takze kdyz zmenim charset, tak mi stale misto cestiny zustane toto : Láník

[iSteve]

mno a kdyz pred ten import das SET NAMES=utf8? (nebo neco v tom smyslu, ted se mi to nechce dohledavat v TFM)

[svaca]

myslis export ne ? musim je nejdrive dostat ven ....

[8an]

Musíš tomu dumpu říct, že to chceš v Latin1, aby to nepřekódoval. A nebo to prostě opravit přes iconv (z utf-8 do latin1, naopak než člověka napadne napoprvé).

[svaca]

Ale jak ?? Koukal jsem na mysqldump a umi pouze:

 --set-charset 
 --skip-set-charset 

a to je vse. Oboji nefunguje ... stale rozsypany caj.

[svaca]

jak to muzu opravit pres iconv ??

[8an]

iconv -f utf-8 -t iso-8859-1 database.dump

(ale netestoval jsem to...)

[svaca]

to by mozna jelo, ale ta vydumpovana databaze uz je rozsypany caj, takze nepomaha .... Ja ji prave musim nejak precist spravne ... jsem vul, takovou pakarnu si pripravit ...

[8an]

Aha, co z toho vyleze? To co jsi dával jako příklad vypadalo jako 2x zakódované UTF-8, takže by ten iconv měl pomoct... Můžeš někam dát kus toho dumpu jako soubor?

[svaca]

tady to je

[svaca]

udelal jsem to pomoci: mysqldump -u root -pxxxxxxx groupoffice > go.sql

[8an]

Koukám na to... Ale asi je problém i v té databázi, protože něco je v tom dumpu jako korektní UTF-8 a něco ne, proto asi nepomohlo nic z toho co jsi zkoušel. iconv -c -f utf-8 -t iso8859-1 opraví to co je zakódované 2x, ale zase rozbije to co je správně, takže asi bude potřeba nějaký komplexnější skript

[zelial]

nevim, jestli jsem to dobre pochopil, ale pokud ta aplikace bezi v poradku, takze je schopna se dostat ke spravnym datum (a v utf-8), tak by mohla vyrobit i spravne exporty, ne?

takze bys tu zalohu databaze udelal na aplikacni urovni. proste nasekal do souboru vsechny ty INSERT INTO. databazi s tabulkama vytvoril znova, tentokrat v utf-8 a se spravnym razenim a ten "vlastnorucni" export nasypal zpatky.

[svaca]

PRESNE to me ted napadlo !!! Group office ma v sobe backup databaze, ale vysledek je stejny ..... Nevim jak ten mechanizmus ale funguje, pujde to jinak ? Jak myslis presne ten druhy odstavec ?

[svaca]

Je samozrejme, jedno v jakem to bude kodovani, to vzdy muzu vysledne zmenit, jen potrebuju vysosat ty veci spravne cesky ... Ano aplikace (Group office) jede v UTF8 a cte to z mysql spravne cesky.

[R]

Ako vyzera ten dump, ked ho pozries v editore nastavenom na UTF-8?

[svaca]

Stejne jako ten post nahore ... Otestovano i ve windows s PSPadem ....

[Jiří (BoodOk) Kadeřávek]

mysqldump --default-character-set=binary

Mimochodem, nezoufejte, mít character set a collation utf8_cs nebo jak se to jmenuje způsobuje např nemožnost vložit stringy odlišující se v o-ó a podobných dvojicích do pole s unikátním indexem (pro mysql se jedná o totožné stringy). Takže občas je lepší mít prostě utf8 text v latin1, pokud nepoužijete české řazení.

[svaca]

BoodOK: Reknu to jednoduse: Jste TOTALNI BOREC !!!!!!!!!!!!!!!!!!!!!!!! Proste BOREC.

FUNGUJE.

Jeste se zeptam, mam tedy funkcni zalohu databaze, mam pripravene pred inportem do MySQL, ze dana databaze pojede v utf8 + mam v my.cnf:

[mysqld]
character-set-server=utf8
collation_server=utf8_czech_ci

[mysql]
default-character-set=utf8

Muze takto byt ?? Mam to na jinich serverech a funguje to. Co jste presne myslel tim o a ó ?

[Jiří (BoodOk) Kadeřávek]

Myslel jsem tím to, že např Sója a Soja jsou pro české porovnávání v UTF8 totožné stringy a nevložíte je do pole s unikátním indexem oba. Přesné detaily si už nepamatuji. Však si to zkuste. Pokud použijete collation utf8_binary (snad se to tak jmenuje), je vše v pořádku, ale potom to celé jaksi postrádá smysl

[svaca]

OK. Diky. Mimochodem aby mi to fungovalo spravne, musel jsem jeste pouzit v my.cnf:

skip-character-set-client-handshake