Upravoval jsem dnes prezentaci Města Český Brod (do redakčního systému byla doplněna například automatická expirace článků či zobrazení počtu článků v dané sekci, což jsou velice podstatné funkce pro funkci Úřední deska) a při té příležitosti jsem chtěl i přesunout data z MySQL 4.0 databáze (mysql) do MySQL 4.1 (mysqli).
Požádal jsem tedy webhosting tojeono.cz o vytvoření nové databáze v MySQL 4.1, a zkopírování datových souborů. Problém ovšem byl, že pouhé zkopírování dat nestačí. Tabulky v MySQL 4.0 jsou po převodu do MySQL 4.1 v latin2 kódování (což je hlavní důvod pro úpravu, celý redakční systém jede v UTF-8), a v MySQL 4.1 jsem potřeboval UTF-8. Výsledkem ovšem byla změť znaků, přestože binárně se o unicode jednalo. Nepomohla ani změna typu tabulky z latin2 na binary a poté z binary na UTF-8. PHPMyAdmin zobrazoval pořád nesmyslné znaky.
Jediná cesta, která fungovala, bylo vytvořit novou databázi v MySQL 4.1 s UTF-8 kódováním, exportovat danou tabulku, starou dropnout, vytvořit ji následně znovu, a následně importovat dříve exportovaná data. Za pomoci PHPMyAdmina práce na 10 minut, a web je poté plně fukční, a řadí hezky česky, nicméně, stejně nechápu, proč běžné postupy jako je nastavení COLLATE a CHARACTER SET nefungují, a tabulku je potřeba fyzicky DROPnout a udělat pomocí CREATE novou.
V tomhle nedám dopustit na řádkový klient a hostingy, které poskytnou vzdálený přístup k MySQL. Práce na 5 minut a navíc funguje i pro databáze o velikosti, která neproleze MyAdminem ať už kvůli velikost souboru nebo timeoutu skriptu.
Radku, mohl bys prosím napsat i článek MySQL 4.1 -> 4.0? Docela by se hodil, jelikož na hostingu mám 4.0 a na lokále 4.1 (latin2).
taky nechápu... obdobné problémy. Ví někdo proč?
Má nějaký význam přecházet na MySQL 4.1, když už je finální verze MySQL 5 ve verzi 5.0.16?
[4] samozřejmě, MySQL 5.0 je zatím nepoužitelná (podpora pro VIEWS a TRIGGERS je sice pěkná, ale tipoval bych si, že i bugová, to raději použiji PSQL), kdežto MySQL 4.1 nabízí stále svoji primitivost, ale i stabilitu a funkční podporu pro kódování.
[5] Views a pod. samozřejmě nevyužívám, ale když už tu tahle verze je, tak proč na jí nepřejít. Stejně to bude v budoucnu potřeba.
Tak mě napadlo, co třeba udělat porovnání MySQL a Firebird.. zajímalo by mě, jak na tom jsou výkonově apod..
Já jsem stejný problém řešil nedávno taky, web jsem psal v UTF-8 data se ukládala do mysql 4, no a na psu se rozhodli pro upgrade a přelili mi databázi z 4 do 4.1. Výsledkem bylo nesmyslné abecední řazení a v myadminu rozsypaný čaj. Když jsem chtěl, ať mi data dumpnou na konzoli, ať je můžu nahrát do nově vytvořených tabulek, tak mi poslali sql soubor s rozsypaným čajem.
Asi to sprostě vyexportovali v myadminu (což zvládnu taky). Takže zatracená ruční práce s nahrazováním rozdrbané diakritiky sql souboru v texťáku a následný import do nových tabulek...
[7] Na root.cz bolo pred nedávnom porovnanie. To prvé je trošku komické a to opravné už trošku lepšie.
Vysvětlení a řešení problému: Převod kódování MySQL.
[8] psa nemam rad hostuji tam taky sice totalni **** protoze jsem si nenasel cas vytvorit neco sam sobe ale to ze tam nemaji php 5 a ani nevi kdy ho budou davat nemluve o mysql 5 mna zacina pit krev nemyslim si ze je pri jejich velikosti takovy problem mit jeden stroj s temito instalacemi...
[10] já myslím, Jakube, že píšeš o něčem jiném. Převod z latin2 na binary a poté na utf8 jsem udělal, ale data se zobrazovala pořád špatně, až po DROP a CREATE table a importu dat to bylo ok. Jinak řečeno, tvůj skript jsem na pár tabulkách z 4.0->4.1 vyzkoušel ručně, a nefungoval.
[12] V článku píšeš . Můj článek je o tom, že nestačí změnit typ tabulky, ale je potřeba změnit typ všech sloupců. Kromě toho je potřeba samozřejmě mít ve skriptech správně nastavené
SET CHARACTER SET(pokud není správně nastavený default).[13] "změnou typu tabulky" myslím samozřejmě i sloupce v dané tabulce, nefunguje to. Jediné co fungovalo je DROP a CREATE. Ověřeno mnou i supportem na webhostingu.
MySQL 4.1 je první verze MySQL, která rozlišuje kódování. Interně pracuje v UTF-8, ve kterém má také všechny databáze. Při nahrávání databáze stačí MySQL říct, v jakém kódování je dump. Náslečně při používání databáze stačí říct v jakém kódování s MySQL chcete pracovat.
Když jsme začínali zhruba před rokem s MySQL 4.1, měli jsme s převody podobné problémy... Pokud si MySQL klient (např. phpMyAdmin) nastavíte na češtinu a latin2 a nahráváte tam dump, který je reálně v UTF-8 (bez znakových definic, které dump z MySQL 4.0 stejně nemá), pak je výsledkem rozsypaný čaj...
Ke stabilitě MySQL 5 souhlasím s Radkem. Ona ani stabilita MySQL 4.1 není žádný zázrak... ;(
Zdravim vsetkych, viem ze toto bude asi mimo clanku ale vazne potrebujem pomoc s UTF-8, teraz som v gruzinsku a musim urobit jednoduchy forum pre univerzitu a nefunguje mi spravne UTF-8 na localhoste. Problem je, ze ked pridavam nejake udaje cez phpAdmina tak toto phpAdmin zobrazuje spravne ale moj php-script nie, naopak ked udaje vkladam do databaze cez moj script tak script zobrazuje udaje spravne ale phpAdmin vypisuje nejake nezrozumitelne znaky (to iste sa stava i s rustinou). Za vseliaku pomoc dakujem, Vlado.
PS: moje nastavenia - collation: utf_general_ci, character set: UTF-8 Unicode (utf8)