Mysql - rozhozené kódování přímo v db

Dobrý den,

na svých stránkách mám kódování utf8 (konkrétně -cs) a všude to mám nastavené i v db i v hlavičkách, v každé tabulce, prostě všude a stejně se mi to v databázi uloží jako změť zvláštních znaků, která se sice načítá správně do stránky, ale nemůžu db zálohovat, protože by se mi načetly ty zvláštní znaky :) neví někdo co s tím?

díky

Tu změť paznaku vidíte v phpMyAdmin? Pokud ano, tak se nic neděje. To jen phpMyAdmin neumí dobře zobrazovat znaky. Samotná tabulka je ve správném kódování.

Pokud jde o import nebo export db v phpMyAdmin, tak to klidně proveďte. Data předá taková jaká jsou. Nemělo by to tedy poškodit kódování. Aspoň já jsem zatím nenarazil na problémy.

problém právě je, že mě to vyexportuje ty data poškozená jak to vidim v myadminovi

To jo. Ale když si je znovu importuješ, tak dostaneš to, cos měl před exportem.

Už ani nevím, na čí straně je chyba. Mám skoro pocit, že MySQL si prohazuje kódování. Prostě má uvedeno jako utf8, ale text je v něčem jiném. MySQL si mezi sebou rozumí, ale když si to prohlídneš třeba v editoru, tak tam se text nereprezentuje jako utf8.

Jsem si to právě zkoušel a zjistil jsem pěknou ironii. V DB uvádím vše v utf8. Stránky zobrazuji data dobře. Ale phpMyAdmin nebo jiné frontendy je zobrazí špatně. Pomůže, když předtím zadám SET NAMES latin1; Pak to zobrazí hezky česky. Což je blbost, protože latin1 neumí pracovat s češtinou.

no já jsem zase zjistil, že mi to krásně valí při latin2 :D fakt tomu nerozumi, každopáně funguje a díky za tip

Tomík (tom.czweb.org)
Nerozumis tomu. Uz jsem to parkrat vysvetloval...

A stranka kodovani -> B kodovani pro sql -> C kodovani sql -> D dekodovani pro sql -> E stranka

C - jestlize mas tabulku nastavenou na latin1
B - a posilas do ni data pres funkci SET NAMES latin1
A - a data mas v UTF
pak ti data prekoduje do tabulky tak, ze uz je nikdo neda dohromady.
Aspon PHPAdmin se bude ridit podle nastaveneho kodovani tabulky, to je C = latin1 a nastavi D i E na latin1. Jenomze E musis mit UTF, aby ti to spravne zobrazil.

To je mozna jeste nesrozumitelnejsi nez driv. Proste, pokud nemas vsechno ve stejnem kodovani, tak to phpadmin neumi zpracovat spravne.

Obvykla chyba je, ze se nepodivaji lide, co maji nastavene v tabulce. Jak maji nastavene pripojeni k databazi. Obvykle je to nastaveno
SET NAMES latin1 = a pokud neuvedes SET NAMES, tak se pouzije toto
soubor php/html header() = latin1
CREATE TABLE COLLATE latin1
A je to problem starych serveru a kdyz pak prijdes nekam, kde je nastaveno
SET NAMES utf = a pokud neuvedes SET NAMES, tak se pouzije toto
soubor php/html header() = utf
CREATE TABLE COLLATE utf
a nebo napopak...
Vetsina lidi nepouziva SET NAMES a spoleha na server. Spis se to pro SQL4 neuvadelo a i tady se ucitelka divila, co to po ni chci, nejake SET NAMES a to uci MySQL :)

A sakryš. Peta má pro jednou pravdu ;)

Hadám, že málokomu napadne používat SET NAMES ve skriptech. A to nemluvím o tom, že na stránkách se to zobrazuje dobře. Takže proč to řešit, že? Už je pak nenapadne, že text ukládají v jiném kódování než zamyšlí.

Zůstává však otázkou, proč peta použil
SET NAMES latin1
místo
SET NAMES latin2

Asi bydlí v Německu.

Kit: To nevím, ale asi to vzal ode mne. Protože u mně ten zápis nepochopitelným důvodem fungoval.
Jinak mám ale pocit, že latin1 je defaultní kódování mysql. A ještě ke všemu collate jako latin1_swedish_ci. Ale asi dost záleží, jak kdo si mysql instaloval a nastavoval.

Kit (ekobrikety.vyrobce.cz)
Tomík (tom.czweb.org) Datum: 16. 05. 2009 21:06
Pomůže, když předtím zadám SET NAMES latin1;
---
V zakladni skole se uci cist. Nesmis chodit za skolu. Ano, mne to bylo divne, ze se pouziva latin-2 a iso-blabla-2, ale budu se s nim prit?
Stejne jsem to asi napsal nesrozumitelne. Zkuste to nekdo vymyslet lip a dame to nekam na web :) Aspon ja bych si to dal k sobe.

Podle Petova modelu nastal problém už v bodě B.

UI (A) i samotné tabulky (C) můžeme mít nastavené na utf8. Ovšem celý ten proces selže na bodu B (SET NAMES). Pokud není uveden, tak se použije defaultní nastavení podle serveru (třeba latin2). Tím ovšem dojde k tomu, že data z UI (A) se překonvertují z utf8 do latin2 a v tabulce (C) pak budou uloženy data nikoli v utf8, jak je uvedeno, ale v latin2.
Dochází tedy ke konfliktu mezi metadata (utf8) a skutečným obsahem (latin2).
Při zpětném procesu se jde stejně. Pokud není uveden bod D (SET NAMES), tak se opět použije defaultní kódování (latin2). Takže dojde k překonvertování dat tabulky z latin2 do utf8. A UI (E) pak zobrazí data v utf8.

Takže pokud se body B a D nepoužiji, tak z pohledu vlastní aplikace (UI) se nic neděje. Dostane data jaké sama dodala. Toto je nejčastěji používaná varianta.

Pokud se použije jiná aplikace, a využívá bodu D (SET NAMES), tak výstup selže. Podle metadat očekává utf8, ale už neví, že data jsou ve skutečnosti v latin2. Takže UI (E) zobrazí data špatně.

Což je právě ten případ, který tady řešíme. PhpMyAdmin očekává utf8, ale neví, že data jsou v latin2 a zobrazí paznaky. A to vše jen kvůli tomu, že nebyl použit uživatelský SET NAMES (B), ale defaultní SET NAMES ze serveru.

Je to srozumitelnejsi, ale jeste to neni ono. Hlavne posledni 2 vety jsou nej.
Misto B D treba vymyslet 1-2 slova, ktera to vystihnou.
Vzdycky jsem nesnasel slovni ulohu z fyziky typu jede vlak A a vlak B a pak vlak C. Jsem se v tom ztratil :) vlak-ostrava, vlak-praha , to ma konkretni vyznam, AB jsou jen abstraktni symboly nic neznamenajici.

Body B a D - vstupně-výstupní kontrola ;). Tyto body jsou jednoduše SET NAMES.