Dotaz: Kompletní převod MySQL na UTF-8

[Dalibor Smolík]

Zdravím, mám takový problém: asi před 8 lety jsem vytvořil databázi s mnoha tabulkami a záznamy v iso-8859-2 a rád bych převedl celý systém na serveru na UTF-8. Taktéž databázi se všemi údaji. Našel jsem na netu různé možnosti, jak nastavit správně kódování (např. tady, ale jak převést veškeré existující záznamy v tabulce zpětně, případně v celé databázi najednou? díky.

---

---

Odpovědi

[frEon]

Dumpnout s vhodnými parametry mysqldump, překódovat dump přes recode a znovu nalít s jiným kódováním na serveru. Chce si to předem vyzkoušet, ale dělali jsme to a v pohodě.

[Dalibor Smolík]

vyzkoušel jsem to takto:
mysqldump databaze --default-characterset=utf8 > databaze.sql
mysql databaze_zalozni < databaze.sql
Tohle ovšem nepomohlo ..objevují se tam údaje typu "pøes"
Převod jsem dělal na stroji s kódování UTF 8 (nikoliv na serveru s iso-8859-2)

[dustin]

Cituji naši wiki (jeden z místních čtenářů určitě pozná svá slova :) ):

Řádkový klient mysql bude načítat data ze souboru (příkaz source) a ta jsou v utf-8.

$ mysql -u user -p --default-character-set=utf8

Vytvořím databázi s nastavením znakové sady a řazení – takhle to úplně stačí, protože v dumpu žádné informace o kódování nejsou a tento default se tak použije pro všechny tabulky i sloupce.

mysql> drop database nase_db;

mysql> create database nase_db DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_czech_ci;

V dumpu nejsou příkazy pro vytvoření databáze ani přepnutí do ní, tak to musím udělat ručně.

mysql> use nase_db;

Vypnutí referenční integrity je pro import nutnost.

mysql> set foreign_key_checks = 0;

GO!

mysql> source nase_db_utf8.sql

[Dalibor Smolík]

Díky, vyzkouším, jen mi není jasné, jak dostat data ze zálohy zpět do nové databáze, je nutné jít do shellu a zadat příkaz mysql databaze_zalozni < databaze.sql?
Vy píšete

mysql> use nase_db;
...
GO!
mysql> source nase_db_utf8.sql 

Nevím, zda tento poslední příkaz lze provést přímo z mysql a pokud ano, kde má být umístěn záložní soubor databaze.sql .

[dustin]

Přesměrování souboru na standardní vstup příkazu mysql (tj. mysql klienta) je stejné, jako v klientovi se přihlásit do databáze a použít příkaz source cesta_k_souboru.sql . Ta cesta je buď absolutní, nebo relativní vzhledem k aktuálnímu adresáři, ve kterém byl klient mysql spuštěn.

Ano, je nutné jít do shellu, stejně jako na dumpnutí a spoustu dalších užitečných činností :)

[Dalibor Smolík]

Všechno jsem učinil, databázi převedl, ale při zadání nového řádku do převedené databáze (přes konzoli) "Příšerně žluťoučký kůň úpěl" se (opět v konzoli) objevilo P?íšern? žlu?ou?ký k?? úp?l .. chyba bude ještě někde jinde. Locale mi vypisuje

LANG=cs_CZ.UTF-8
LANGUAGE=
LC_CTYPE="cs_CZ.UTF-8"
LC_NUMERIC="cs_CZ.UTF-8"
LC_TIME="cs_CZ.UTF-8"
LC_COLLATE="cs_CZ.UTF-8"
LC_MONETARY="cs_CZ.UTF-8"
LC_MESSAGES="cs_CZ.UTF-8"
LC_PAPER="cs_CZ.UTF-8"
LC_NAME="cs_CZ.UTF-8"
LC_ADDRESS="cs_CZ.UTF-8"
LC_TELEPHONE="cs_CZ.UTF-8"
LC_MEASUREMENT="cs_CZ.UTF-8"
LC_IDENTIFICATION="cs_CZ.UTF-8"
LC_ALL=

Výstup v PHP je stejný, v PHP mi příkaz echo mb_internal_encoding(); stále vyjíždí ISO-8859-1 ..

[dustin]

Napiš v mysql konzoli show variables a postni je sem. Zřejmě máš mišmaš mezi client/connection/server kódováním.

[Dalibor Smolík]

Příloha:

• variables.txt (37859 bytů)

Tady to je, myslel jsem si, že to kódování někde nehraje ..

[dustin]

To vypadá OK. A show create table vypisuje taky to utf8? To chybné kódování je v konzolovém mysql klientovi? A jde přímo v tom klientovi psát česky, podporuje terminál zobrazení UTF-8?

[Dalibor Smolík]

v klientovi mysql lze psát takto:
mysql> select nazevfirmy from telseznam where nazevfirmy like 'Příšerně žluťoučký kůň';
tady problém nevidím. Pokud ale takový údaj do databáze zadám, výsledek je ovšem

mysql> select nazevfirmy from telseznam where nazevfirmy like 'P%';
P?íšern? žlu?ou?ký k?? úp?l 

[Dalibor Smolík]

Pokud ale vytvořím novou databázi na stroji s utf8, změním ji tímto způsobem
alter database xxx character set utf8 collate utf8_czech_ci
a vytvořím novou tabulku, do níž pak zadám data,pak

mysql> select * from xxxx;
+----------------------------------+
| pole                             |
+----------------------------------+
| Příšerně žluťoučký kůň |
+----------------------------------+
1 row in set (0.00 sec)

je vše v pořádku.
Tak to vypadá, že problém je v tom převodu ..

[Šangala]

Zkuste si vypsat tyto dva příkazy, jaká je tam uvedená znaková sada a to i u konkrétních sloupců.

mysql> show create database MyDatabase;
mysql> show create table MyTable;

[Dalibor Smolík]

mysql> show create database pracex;                                                                                                                            
+----------+---------------------------------------------------------------------------------------+                                                           
| Database | Create Database                                                                       |                                                           
+----------+---------------------------------------------------------------------------------------+                                                           
| pracex   | CREATE DATABASE `pracex` /*!40100 DEFAULT CHARACTER SET utf8 COLLATE utf8_czech_ci */ |                                                           
+----------+---------------------------------------------------------------------------------------+                                                           
1 row in set (0.06 sec)                                                                                                                                        
                        

mysql> show create table telseznam;                                                                                                                            
+-----------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+                                                                                                                 
| Table     | Create Table                                                                                                                                                                                                                                                                                                                                                 |                                                                                                                 
+-----------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+                                                                                                                 
| telseznam | CREATE TABLE `telseznam` (                                                                                                                       
  `pismeno` char(1) CHARACTER SET utf8 COLLATE utf8_czech_ci DEFAULT NULL,                                                                                     
  `nazevfirmy` text,                                                                                                                                           
  `FAX` text,                                                                                                                                                  
  `TEL` text,                                                                                                                                                  
  `poznamka` varchar(250) DEFAULT NULL,                                                                                                                        
  `datum` date DEFAULT NULL,                                                                                                                                   
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,                                                                                                               
  PRIMARY KEY (`id`)                                                                                                                                           
) ENGINE=MyISAM AUTO_INCREMENT=1025 DEFAULT CHARSET=latin1 |  

Vidím, že v tabulce to stále není ono ..

[Dalibor Smolík]

zkusil jsem ještě pak
alter table telseznam convert to character set utf8 collate utf8_czech_ci;
pak se objevilo na konci
ENGINE=MyISAM AUTO_INCREMENT=1025 DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci
ale zobrazování se nezměnilo. Pokračovat mohu v pondělí.

[Šangala]

Problém je tam jasně vidět, příčina je v dumpu a to v CREATE TABLE.
Návod kulhá zde „protože v dumpu žádné informace o kódování nejsou“.
V dumpu totiž ty informace jsou, tudíž se vytvoří tabulky opět v latin1.
Něco jako %s/DEFAULT CHARSET=latin1//g na dump přet zpětným nalétím do db by mohlo pomoct. Navrhoval bych:

1. Udělat dump: mysqldump -u user -p --default-character-set=utf8 DB4export > dbdump.sql
2. Na dbdump.sql aplikovat %s/DEFAULT CHARSET=latin1//g (vi-čkem, sed-em nebo čím :) ) - vymazání znamená použítí defaultu DB
3. Zkontrolovat jestli se v dbdump.sql ještě někde nevyskytuje latin1. (vi-čkem, grepe-em nebo čím :) ) - mohly by mít kódování i samotné sloupce :(
4. V mysql clientovi:
   • CREATE DATABASE novadb DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_czech_ci;
   • USE novadb;
   • \W zapnutí varování (to 'W' je velké! :))
   • \T vystupnisoubor od fčul všechno také zapíše do 'vystupnisoubor' (to 'T' je velké! a do toho soubor se to připojuje, takže by neměl existovat :))
   • source dbdump.sql
   • \q
5. checknút 'vystupnisoubor'

Dump je v UTF8 a přepíná si i patřičné kódování clienta, takže to není třeba řešit.

[dustin]

Jasně. Návod byl totiž psán pro přechod ze starší verze MySQL na aktuální plus součásně přechod na UTF-8. V dumpu ve starších verzích to info o kódování nebylo :) Už jsem to nijak neověřoval, sorry.

[Dalibor Smolík]

Díky, tohle po neděli vyzkouším, měl jsem ten pocit, že samostatné kódování mají i sloupce, při počtu tabulek to bude moc pěkné

[dustin]

To nahradíš hromadně regulární výrazem :)

[Šangala]

Myslím že když aplikujete tyto patterny v následném pořadí, mělo by to být:

1. %s/DEFAULT CHARSET.latin1//g - rozšířený zápis pro tabulku, asi je v tom dumpu použitý
2. %s/CHARSET.latin1//g - zkrácený zápis, který asi v dumpu nebude
3. %s/CHARACTER SET.latin1 COLLATE.latin1[0-9a-zA-Z_-]*//g - zápis včetně řazení pro sloupec
4. %s/CHARACTER SET.latin1//g - zápis bez řazení pro sloupec

PS: samořejmně to lze naspat lépe a přesněji( místo tečky jen mezerr a '=') atd.

Pokud chcete mít jistotu v nepozměnění dat, je nejsnazší to udělat dvou-kolově - všimněte si přepínačů.

1. Udělat dump struktury: mysqldump -u user -p --default-character-set=utf8 --no-data --routines DB4export > dbdump-struct.sql
2. Udělat dump dat: mysqldump -u user -p --default-character-set=utf8 --skip-triggers --no-create-info --skip-add-drop-table --disable-keys --hex-blob DB4export > dbdump-data.sql
3. Na dbdump-struct.sql aplikovat:
   • %s/DEFAULT CHARSET.latin1//g
   • %s/CHARSET.latin1//g
   • %s/CHARACTER SET.latin1 COLLATE.latin1[0-9a-zA-Z_-]*//g
   • %s/CHARACTER SET.latin1//g
   (vi-čkem, sed-em nebo čím :) ) - vymazání znamená použítí defaultu DB
4. Zkontrolovat jestli se v dbdump.sql ještě někde nevyskytuje latin1. (vi-čkem, grepe-em nebo čím :) )
5. V mysql clientovi:
   • CREATE DATABASE novadb DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_czech_ci;
   • USE novadb;
   • \W zapnutí varování (to 'W' je velké! :))
   • \T vystupnisoubor od fčul všechno také zapíše do 'vystupnisoubor' (to 'T' je velké! a do toho soubor se to připojuje, takže by neměl existovat :))
   • source dbdump-struct.sql
   • SELECT '--- TADY zacianji DATA ---' AS info; - jen pro do očí bijícího oddělení do výstupu
   • source dbdump-data.sql
   • \q
6. checknút 'vystupnisoubor'

Na co jsem zapomněl?… :)

[Dalibor Smolík]

Příloha:

• vystupnisoubor (96464 bytů)

Zdravím a díky za podrobný návod, nicméně jsem se nepohnul dále .. vše jsem provedl správně, v bodě 3) se ve vi objevuje hlášení "no pattern found", v bodě pět

mysql> select 'příšerně žluťoučký kůň' as info;
+----------------------------------+
| info                             |
+----------------------------------+
| příšerně žluťoučký kůň |
+----------------------------------+
1 row in set (0.00 sec)

Nové údaje se do databáze zadávají správně, ale staré se nepřevedou.

[Šangala]

Toto by mělo zabrat:
V bodě 2. to změňte na:

mysqldump -u user -p --skip-set-charset --default-character-set=latin1 --skip-triggers --no-create-info --skip-add-drop-table --disable-keys --hex-blob DB4export > dbdump-data.sql

PS: ano některé patterny to pravděpodobně nenajde jak jsme psal…

[Dalibor Smolík]

Po této úpravě se mi objevilo: mysql> show create table telseznam;

| telseznam | CREATE TABLE `telseznam` (
  `pismeno` char(1) COLLATE utf8_czech_ci DEFAULT NULL,
  `nazevfirmy` text COLLATE utf8_czech_ci,
  `FAX` text COLLATE utf8_czech_ci,
  `TEL` text COLLATE utf8_czech_ci,
  `poznamka` varchar(250) COLLATE utf8_czech_ci DEFAULT NULL,
  `datum` date DEFAULT NULL,
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=1022 DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci |

a dále:

mysql> select 'příšerně žluťoučký kůň' as info;
+----------------------------------+
| info                             |
+----------------------------------+
| příšerně žluťoučký kůň |
+----------------------------------+
1 row in set (0.00 sec)

ale pokud zadám příkaz

select * from telseznam;

dostanu m.j. "pí. Bednáøová" ...

[Šangala]

Definice tabulky je OK, zkuste na data latin2 nebo cp1250:

mysqldump -u user -p --skip-set-charset --default-character-set=latin2 --skip-triggers --no-create-info --skip-add-drop-table --disable-keys --hex-blob DB4export > dbdump-data.sql

[Šangala]

Nějak mi to nedocvaklo, píšete iso-8859-2, což není latin1, ale latin2 :)

[Dalibor Smolík]

Zdravím, stále nic nepomohlo. Napadlo mě, zda nelze převést soubor dbdump-data.sql nějak přímo do utf8 - což jsou zkusil příkazem
iconv -f iso-8859-1 dbdump-data.sql -t utf-8 dbdump-data.sql > dbdump-datax.sql
což také nevedlo k cíli (nevím, zda u vstupního souboru je to kódování správně)

[dustin]

Proč používáš to iso-8859-1, když jsou i zdrojová data česky? Buď je to dumpnuté rovnou do utf-8, nebo předpokládám do latin2 (tedy iso-5589-2). V jakém kódování jsi to vlastně dumpoval? mysqldump na to má parametry.

[Dalibor Smolík]

No, abych to vzal od začátku. Databáze vznikla na stroji s iso-8859-2, při jejím vzniku jsem nezadával žádné kódování, takže default.. Výpis vypadá takto:

mysql> show create database prace;
+----------+------------------------------------------------------------------+
| Database | Create Database                                                  |
+----------+------------------------------------------------------------------+
| prace    | CREATE DATABASE `prace` /*!40100 DEFAULT CHARACTER SET latin1 */ |
+----------+------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> show create table telseznam;
+-----------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Table     | Create Table                                                                                                                                                                                                                                                                                                                                                  |
+-----------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| telseznam | CREATE TABLE `telseznam` (
  `pismeno` char(1) character set utf8 collate utf8_czech_ci default NULL,
  `nazevfirmy` text,
  `FAX` text,
  `TEL` text,
  `poznamka` varchar(250) default NULL,
  `datum` date default NULL,
  `id` int(10) unsigned NOT NULL auto_increment,
  PRIMARY KEY  (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=1025 DEFAULT CHARSET=latin1 |
+-----------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql>   

Takto se to zobrazilo na původním stroji. Vidím, že default charset je "latin1"
Tuto databázi přenesu na stroj s utf8 a pak teprve budu provádět dump nebo provést dump s příslušnými parametry ještě na původním stroji a pak přenést na nový server?

[Šangala]

K dumpu, mělo bys e dumpovat na původním a přenášet na druhý, nebo stejný - jak to bude utf8 tak už je to jedno.
V tabulce latin1 mohou být klidně data latin2, vždy záleží na nastavení více faktorů: character_set_client, character_set_connection, charset sloupce(tabulky či databáze) či co tam opravdu pošlete.
Např. z web-php stránky Win-1250 s character_set_connection a character_set_client na utf8 v tabulce latin1 budou data, jestli se nepletu ve Win-1250 ale standardně se budou třídit dle latin1. (nejsem si jist co s tím udělá v tomto případěcharacter_set_client - prostě je třeba mít nastaveno vše správně)
A když je chci vysypat ven, tak mám problém bo vlastně nevím co tam je - vše utf8, je v tomto případě bezproblémové.

A fčul mi něco došlo (bohužel až fčul):
Pokud se do db vloží záznam s hodnotou stejnou cestou jak tam putují/putovala ta data např. 'ěščřžýáíéďťňúůĚŠČŘŽÝÁÍÉĎŤŇÚŮ' a dumpne se to:

mysqldump -u user -p --skip-set-charset --default-character-set=binary --skip-triggers --no-create-info --skip-add-drop-table --disable-keys DB4export > dbdump-data.sql

(znaková sada binary, a bez --hex-blob)
Dostanete opravdu to co tam je, jak to leží a běží a pak se stačí podívat na data 'ěščřžýáíéďťňúůĚŠČŘŽÝÁÍÉĎŤŇÚŮ', či je švihnout sem.
A dále se podle toho zařídit.

[Šangala]

Holt bude třeba zkoušet, bo je zmatek v kódování :(
iso-8859-1 - latin1, iso-8859-2 - latin2
a kdoví co je opravdu v těch tabulkách za data.
Důležité je dostat ven data do dumpu čitelná.
A pokud neuspějete plně jako např. pí. Bednáøová, tak bych se asi přestal trápit a vložil do nějakého pole: ěščřžýáíéďťňúůĚŠČŘŽÝÁÍÉĎŤŇÚŮ případně plus äëïöüÄËÏÖÜ stejnou cestou jak se data do db dostávala doposud.
A hlídal to pole v dumpu případně nasadil iconv na převod a zkoušel varianty.
Ještě sem můžete hodit:

• SHOW CREATE TABLE t; v původní databázi
• Výpis hodnoty pole z původní db: ěščřžýáíéďťňúůĚŠČŘŽÝÁÍÉĎŤŇÚŮ vloženého cestou jako doposud (mysql> SELECT pole FROM tabulkaVpuvodnidb WHERE poleid=idpoleprotest)
• Výpis hodnoty pole z původní db: ěščřžýáíéďťňúůĚŠČŘŽÝÁÍÉĎŤŇÚŮ vloženého přes mysql klienta
• A případně dump tohoto pole s příkazem, kterým to bylo vysypáno ven (mysqldump...).

Pokud to neklapne, tak v dummpu znaky 'ø' hromadně zaměnit za 'ř' atd. - je otázkou jestli to půjde jednoznačně.

PS: A příště všechno UTF8 a správné nastavení klienta :):):)

[Dalibor Smolík]

V původní databázi to bylo tak:

| telseznam | CREATE TABLE `telseznam` (
  `pismeno` char(1) character set utf8 collate utf8_czech_ci default NULL,
  `nazevfirmy` text,
  `FAX` text,
  `TEL` text,
  `poznamka` varchar(250) default NULL,
  `datum` date default NULL,
  `id` int(10) unsigned NOT NULL auto_increment,
  PRIMARY KEY  (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=1026 DEFAULT CHARSET=latin1 |

Přes vi jsem se snažil hromadně znaky 'ø' zaměnit za 'ř', což se v dumpu povedlo, ale v databázi místo toho byly jen otazníky, i když se nová databáze i tabulka hlásily jako charset utf8 ..

[Šangala]

Si nerozumíme, „v jakém kódování ta data tam opravdu byla?“ To že je tabulka latin1 ještě neznamená, že tam nemůžou být data třeba v utf8 či Windows-1250. To platí i pro „i když se nová databáze i tabulka hlásily jako charset utf8“ - data tam mohou být klidně latin1 a tím pádem nečitelná

„ale v databázi místo toho byly jen otazníky“ - to je nějaký renónc,

• pokud inserty provedete ze souboru v UTF-8 (buď je to definováno dumpem, nebo to přes iconv, převedete)
• databázi/tabulky/[sloupce] máte UTF8 (dump struktury neobsahuje změnu znak. sady pro tabulky - to zařídily ty mazací regexp na strukturu - a stvořená DB je utf8 ),
• všechny parametry máte UTF-8 (character_set_client a character_set_connection - což bylo vidět ve výpise co jste posílal) a
• dump neobsahuje změnu znakové sady (při vytváření dumpu přepínač --skip-set-charset)

bude to tam správně, jestli ne, něco nebylo splněno.

[okbob]

Kdysi jsem se trápil s něčím podobným - problém byl v tom, že data byla v MySQL reálně ve win1250, nicméně MySQL byla nakonfigurována z defaultu na Latin1. Pokaždé, když jsem při dumpu zadal kódování - tak vylezlo něco zmršené - až jsem udělal dump bez jakéhokoliv požadavku na kódování - v podstatě MySQL vytlačila to co měla v db a pak jsem iconv převedl data, která již byla v pořádku.

[Šangala]

Tipnu si: na MySQL 4.x ?

[Dalibor Smolík]

Na původním serveru:

mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 301
Server version: 5.0.51a-24+lenny4 (Debian)

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> 

Na novém stroji:

server:/home/dalibor# mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 33
Server version: 5.1.49-1 (Debian)

Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved.
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL v2 license

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> 

Obojí je pětková verze ..

[Šangala]

Reaguji na příspěvek okbob-a '...v podstatě MySQL vytlačila to co měla...'

[okbob]

ju - pravděpodobně to bylo ještě ve 4ce. Jádro pudla bylo v rozporu mezi konfigurací MySQL a realitou. A pak zákonitě, při jakémkoliv pokusu a konverzi na straně MySQL muselo dojít k nesmyslné koverzi.

[Dalibor Smolík]

Ano, tvorba byla ještě v ve verzi 4 .. Jestli to nejde, je to lépe vědět, abych neztrácel čas ..

[okbob]

ono to jde, ale konfigurace musí odpovídat uloženým datům. U dumpu nelze použít parameter "from" protože to je dané. Jenomže pokud je dané kódování iso8859-1 a ve skutečnosti jsou data v latin2, tak při jakékoliv konverzi na serveru dojde k zmatenému výstupu. Takže data nesmí konvertovat - musí se provést pouze dump.

[Dalibor Smolík]

No, tak jsem si uvědomil, že první data byla ukládána ve verzi 3.52 nebo tak nějak .. počátkem roku 2002. Jinak ale ani samotný dump dat bez konverze nepomáhá.
Pøíšernì žluouèký kùò úpìl ïábelské ódy.

[Šangala]

Jsem to zkusil, „pouze dump“ lze udělat přes kódováni binary viz výše.

[Dalibor Smolík]

Po tomto návodu se neobjevily v databázi ani znaky 'ø', nýbrž jen otazníky, čitelnost ještě horší.

[Šangala]

Nevím jaká je čitelnost, ale to je to, co jste do DB uložil a lze to převést, pokud ovšem to sám nerozpoznáte co je to za znakovou sadu a správně to nepřevedete nebo sem ten soubor nevložíte tak se neustále bavíme jen o tom, že je někde špatně znaková sada.
Vysypte:

mysqldump -u user -p --skip-set-charset --default-character-set=binary --disable-keys DB4export telseznam > dbdump-telseznam.sql

Mělo by to vysypat jen tabulku telseznam, promažte inserty a nechte tam jen ten „ěščřžýáí…“ a vložte to sem jako přílohu.

[Dalibor Smolík]

Příloha:

• dbdump-telseznam.sql (103252 bytů)

Zatím nejpříznivějšího výsledku jsem docílil, když jsem dumpoval strukturu i data s kódováním utf8 a pak následně tabulku telseznam převedl příkazem ALTER TABLE telseznam CONVERT TO CHARACTER SET utf8 COLLATE utf8_czech_ci. Poté mohu nové údaje nebo upravovat jednotlivě původní údaje již se správným kódováním. Kdyby šel opravit každý znak t hromadně za celou databázi, bylo by to postačující. Takto upravenou tabulku jsem nyní dumpnul dle výše uvedeného pokynu.

[Šangala]

No a je to to tady data jsou 'Windows-1250'.
Trochu nám to komplikuje fakt, že tabulka obsahuje i UTF8 sloupec.
Čisté řešení by mělo být, aplikovat na každý sloupec bez kódování (ty latin1):

ALTER TABLE tabulka MODIFY sloupec TEXT CHARACTER SET cp1250;

v původní db.

Pak je již možné udělat dump:

mysqldump -u user -p --skip-set-charset --default-character-set=utf8 --disable-keys --hex-blob DB4export > dbdump.sql

a tento dump naimportovat do DB s utf8;

Je otázkou je kolik máte tabulek, jestli jednu dvě, tak ručně je to v poho, jinak bych napsal asi phkovy scriptík….

PS: nechci hádat co je v tom UTF sloupci ve skutečnosti, nebo co tam má být v našem případě sloupec 'pismeno', asi je to 1. písmeno z názvu firmy (i když ne vždy).
Pokud by jste tento sloupec převedl (ne modifikoval tj. ALTER TABLE telefoniseznam MODIFY pismeno CONVERT TO CHARACTER SET cp1250; (nebo tak nějak :)) v původní db.)
tak se může binární dump normálně převest z WINDOWS-1250 na UTF8 a vložit do db utf8.

[Dalibor Smolík]

jo, díky moc .. těch tabulek je asi třicet, některá má dvacet sloupků .. kompletní firemní výrobní evidence. Tu, cojsem ukázal je jen příklad
Skripty PHP jsou v kódování Windows-1250, apache taky - asi odtamtud je to kódování v mysql. Prozkoumám to..asi nějaký skriptík to bude potřebovat.

[okbob]

Napadlo mne ještě něco jiného - pokud Vám chodí diakritika na aplikační úrovni, tak použít jakousi verzi php dumpu - a výsledek načíst do korektně nainstalované databáze. např. http://snipplr.com/view/173/mysql-dump/, http://odvarko.cz/mysqldump-pro-php či http://davidwalsh.name/backup-mysql-database-php. Další možnost je použít třeba Adminner Jakuba Vrány a exportovat tabulky do CSV.

[Šangala]

Snazší je asi tohle, ale je to asi třeba upravit.
Asi bych si udělal skriptík, který využije SHOW TABLES pak SHOW COLUMNS FROM x a vyhodnocení nějakého regexp a pak bych vygeneroval SQl dotaz a až by se mi líbil, tak bych ho pustil :).

Pro rozhodnutí by mohlo napomoci

mysqldump -u user -p --default-character-set=utf8 --no-data db | grep -i "CHARACTER SET"

bo jak se zjistí, že jiné kódování než latin1 je jen u dvou sloupců v celé db, tak se lehce převedou tyto dva sloupce na cp1250 (ALTER TABLE x MODIFY xx CONVERT TO CHARACTER SET cp1250), udělá se binary export dat a přes iconv se převede z cp1250 na utf8 a to se naimportuje do nove vytvořené db dle tohoto (bod 1, 3, 5-prvních pět bodů)

[Dalibor Smolík]

Jako první pokus jsem se snažil udělat to ruční "čisté řešení". V původní databázi jsem změnil všechny sloupce tabulky (nebylo možné změnit sloupec id a datum, ale to asi nevadí) a provést dump. Importoval jsem jej do db s utf8 (vzniklé příkazem create database pracex DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_czech_ci;) ..bez výsledku. Zobrazení: ?echofracht LETIŠT?

[okbob]

Ten čistý pokus je špatně - chybí tam mezistupeň s binárním kódováním. Viz výše uvedený odkaz na článek Jakuba Vrány.

[Šangala]

S Váma je to to trochu těžké, nevím co jste vlastně udělal :).
'Změnil ...' může znamenat cokoliv a taky je třeba zjisti jak to dopadlo (jak vypadá nyní 'SHOW CREATE TABLE telseznam' v původní DB, jak vypadá 'binary' export z původní DB /--skip-set-charset --default-character-set=binary /).
Pokud je sem přiložíte, - opravdu stačí jen jedna tabulka a jen jeden/dva záznamy s nějakou diakritikou jako šřžýů a diakrityckým písmenem v poli 'pismeno'.
Mně je to samozřejmě putna, klidně sem dejte cokoliv - my si rádi počtem :).

[Dalibor Smolík]

Díky všem za pomoc a trpělivost. Nakonec jsem to vyřešil následovně:
dumpnul jsem zvlášť strukturu a zvlášť data v UTF8, na novém stroji jsem vytvořil databázi v UTF8, naimportoval jsem strukturu. Potom přes vi jsem opravil všechny špatné znaky v dbdum-data.sql, což byla práce, ale bylo to pro celou databázi najednou a nakonec jsem importoval data. Funguje to. Teď si jen musím pohrát s "omáčkou" okolo ve skriptech PHP na zobrazování pro uživatele