Dotaz: MySQL zase kódování

[Pavel]

Hoj, mám databázi, kde je tento záznam (zobrazeno přes mysql clienta):

21916 | 吴        | 分生        | 1          | 瑞安市仙降镇下社村 | 

Ale když DB dumpuju, kódovaní se zmrší:

(21916,'å�~P´','å�~F�~@| ç�~@~]�

V té samé tabulce jsou ale záznamy v Češtině se správnou diakritikou, které se vydumpují korektně.

Je divné, že něco se vydumpuje správně a něco ne. Také je zvláštní, že terminál mi přes mysql clienta záznamy zobrazí správně, ale když si ve vi/mcedit/kate otevřu dump, tak je to špatně.

Pochází to ze systému, o kterém nic nevím (PHP).

Verze: MySQL 5.0.32-Debian_7etch12-log

Tabulka: DEFAULT CHARSET=latin1

Server variables:

| character_set_client            | latin1                      | 
| character_set_connection        | latin1                      | 
| character_set_database          | latin1                      | 
| character_set_filesystem        | binary                      | 
| character_set_results           | latin1                      | 
| character_set_server            | latin1                      | 
| character_set_system            | utf8                        | 
| character_sets_dir              | /usr/share/mysql/charsets/  | 
| collation_connection            | latin1_swedish_ci           | 
| collation_database              | latin1_swedish_ci           | 
| collation_server                | latin1_swedish_ci           |

V my.cnf není o kódování ani zmínka.

Dump vytvářím takto:

mysqldump --default-character-set=utf8 --set-charset

Vyzkoušel jsem i --default-character-set=latin1, nebo též použít recode na soubor s dumpem, ale vše bez výsledku. Otázka je, jak koretkně vydumpovat DB?

Odpovědi

[Šangala]

Řešili jsme to tady

mysqldump --default-character-set=binary

Vyeexportuje tak jak to leží v db, takže lze zjitit co tam vlastně je.

[Šangala]

A doplním, není problém mít v tabulce data v jiném kódování, než je tabulka(sloupec) nastavena, je to velmi častý jev po přechodu ze 4.x verzí a také u různých, většinou PHP, aplikací, které si správně nenastaví všechny parametry vztahující se ke kódování. Často se to zjistí, až když se DB chce přenést jinam, kde je to jinak nastaveno. Což je ještě dobrá situace, horší je když se něco změní a používá(vkládá) se to dál, to pak máte problém, ale lze to také řešit - pracně a záleží na okolnostech jak úspěšně.
Dále se může jednat o nesprávně provedený export(dump) a import, nebo kombinace všeho, což je nelepší :).
Pokud sem přiložíte soubor stvořený pomocí příkazu:

mysqldump -u uzivatel -p --default-character-set=binary --skip-set-charset databaze tabulka

lze zjistit jak to tam vlastně je.

[Pavel]

Super, diky za reakci, s binary se to vydumpovalo jako:

(21916,'å<90>´','å<88><86>ç<94><9f>','1','ç<91><9e>å®<89>å¸<82>ä»<99>é<99><8d>é<95><87>ä¸ ...

[Šangala]

Pravděpodobně z toho lze něco zjistit - ale blbě a ne všechno - psal jsem "přiložit" ne zkopírovat do textu. Jsou třeba nezměněná data, klidně je promažte, ale chtěl jsem vidět dump v nezměněné podobě, tj. i CREATE TABLE syntaxi a vlastní data (třeba jen jeden záznam).

[chrono]

Tá časť å<88><86>ç<94><9f> je reťazec "分生" v kódovaní UTF-8 ktorý sa zobrazuje ako 8859-1 (a to za tým je 瑞安市仙降).

[chrono]

Zabudol som napísať, že ak Pavel ten súbor pozerá v inom kódovaní ako 8859-1, tak sú tie údaje zakódované viac krát a bude musieť použiť napr. iconv na odstránenie toho prebytočného kódovania.

[Šangala]

Ju, super - nemusí se to už hledat :).
Nicméně pokud to chce napravit a nebudeme znát jak jsou tabulky nastaveny a bude se to jen přepisovat, tak nezjistíme kde je problém. Pokud dá binární dump včetně CREATE TABLE.. + jeho nastavení, ketré již napsal, lze určit co je špatně a jak to lze spravit.
Třeba nic, prostě v latin1 nezobrazí rozsypaný čaj :).