MySQL 4.1 – kódování

Školení, která pořádám

Z českého pohledu je jedna z nejvýznamnějších změn v MySQL 4.1 podpora různých kódových stránek a to nejen na úrovni databázového serveru, ale i na úrovni jednotlivých databází, tabulek a sloupců. Syntaxe je poměrně jednoduchá, stačí za obvyklé příkazy dopsat COLLATE a odpovídající kódovou stránku spolu s výchozím tříděním:

Seznam všech podporovaných kódových stránek a možných třídění vrací příkaz SHOW COLLATION.

Když s kódováním začnete experimentovat, pravděpodobně se dřív nebo později setkáte s chybou typu Illegal mix of collations (cp1250_general_ci,COERCIBLE) and (latin1_swedish_ci,COERCIBLE). Důvod je ten, že kódování se nenastavuje pouze datům uloženým v databázi, ale i těm přenášeným. A pokud mají data v databázi jinou kódovou stránku než data předaná v dotazu, dojde k uvedené chybě. Říkáte si, proč je výchozí kódování právě latin1_swedish_ci? No hádejte, odkud je MySQL AB

Kromě uložených dat lze tedy určit ještě kódování klienta (tedy v jakém kódování se data posílají) a přenášených a vracených dat. Všechna tři kódování lze nastavit příkazem SET NAMES SET CHARACTER SET. Pro optimální výkon je vhodné používat všude stejné kódování – na serveru, během přenosu i u klienta.

<?php
mysql_connect();
mysql_select_db("databaze");
mysql_query("SET CHARACTER SET utf8");
?>

Pokud chcete explicitně určit kódování jednoho řetězce, můžete použít zápis _cp1250'text', kde řetězec mezi podtržítkem a prvním apostrofem znamená identifikátor kódování. Hodit se to může např. tehdy, když jsou skripty v jiném kódování než v jakém se komunikuje s databází (ne že bych to někomu doporučoval).

Viz též: Převod kódování MySQL.

Přijďte si o tomto tématu popovídat na školení Návrh a používání MySQL databáze.

Jakub Vrána, Seznámení s oblastí, 8.6.2005, diskuse: 138 (nové: 0)

Diskuse

Lukoko:

teď mě tak napadlo ... v čem se liší utf8_general_ci a utf8_czech_ci. Mysles sem si, že utf8 je univerzální ... jak to teda je?
Dík

ikona Jakub Vrána OpenID:

V češtině se např. ch třídí mezi h a i. Dále se např. č třídí až za c - jinak jsou si pořadím rovny, tzn. "člověk" se v general setřídí před "cokoliv", v češtině to je naopak.

Martin S.:

Dobrý den, může mi někdo poradit co se znaky Ť, ť, T, Ň ... (v utf8_czech_ci). Něřadí se správně (Ť je před t apod.). Respektive jsou si rovny? A jde to něják obejít? Nebo je zbytečné toto řešit (nerozlišují se myslím ani velká a malá písmena). Asi je to přímo dáno utf8_czech_ci, ale je to taksprávně?
Děkuji za radu:-)
Martin

ikona Jakub Vrána OpenID:

Myslím, že by to stálo za vyplnění bugu. Ť a T si v češtině nejsou rovny, na rozdíl třeba od A a Á.

Jakub:

Dovolím si nesouhlasit, T a Ť jsou na stejné úrovni.
Základní pořadí znaků v češtině je následující: abcčdefghchijklmnopqrřsštuvwxyzž

Následující písmena se řadí jako znaky bez diakritiky: áďéěíňóťúůý

Takže ťapka bude abecedně před taťka. (p < ť)

ikona Jakub Vrána OpenID:

Je to tak, díky za opravu. Doplním zdroj: ČSN 97 6030 (http://cs.wikipedia.org/wiki/Abecedn%C3%AD_….8Ce.C5.A1tina).

Gork:

Už dlouho řeším kódování databáze a pořád se mi nedaří nastavit to dobře.... Jesli by byl někdo ochotný a mohl by se na to podívat? Kdyžtak mi napište na icq 220-463-125

Spud:

Moc do toho nevidim, ale nebylo by lepsi nastavovat "SET CHARACTER SET 'utf8'"? Ted koukam do manualu MySQL a pripada mi to stejne (zmena promennych character_set_client, character_set_results, character_set_connection).

Ale SET NAMES meni i collation_connection na defaultni hodnotu pro nastavovany character_set. Nevim jaka je treba pro utf8, ale predpokladal bych, ze to bude utf8_general_ci a jestli jsem mel na databazi nastavene collation utf8_czech_ci tak tuto zmenu asi nebudu chtit.

ikona Jakub Vrána OpenID:

Ano, typicky to je skutečně lepší - hlavně proto, že character_set_connection se nastaví na character_set_database, což je obvykle přesně to, co potřebujeme. V článku jsem to opravil.

Jen technická poznámka - hodnoty pro SET CHARACTER SET se píšou narozdíl od SET NAMES bez apostrofů.

ikona spaze:

i SET NAMES lze psat bez uvozovek/apostrofu.

lukas:

cao
prosim vas a jak je to s prechodem na z mysql3x na mysql4x
napriklad mam problem s diakritikou
vydumpoval jsem si data z mysql3.x a myslel jsem ze do db ktera jede na mysql4.x data zustanou ok
ale neni tomu tak
presun databze na ctyrkove verze se ma dit v nejakym specialnim zpusobem?
diky

ikona Jakub Vrána OpenID:

Způsob migrace je popsán na http://dev.mysql.com/doc/mysql/en/upgrade.html. Mezi 4.0 a 4.1 je velký rozdíl, z indicií usuzuji, že se jednalo o přechod na 4.1.

Důležité je, aby databáze, tabulky nebo sloupce měly správně nastavené kódování. Někdy je nejjednodušší data vyexportovat ze staré DB, nastavit správné kódování a naimportovat do nové DB.

Tomáš:

A nevíte, jak docílit toho, aby všechny staré aplikace napsané pro MySQL 4.0 a nižší fungovali se správnou diakritikou. Potřebuji, aby se i bez SET CHARACTER SET windows-1250 použilo windows-1250 jako výchozí pro spojení. Jde to nějak?

ikona Jakub Vrána OpenID:

Problém se mi nepodařilo vyřešit. Pomocí následujcích voleb v my.ini se mi povedlo přimět k jakés-takés spolupráci alespoň nástroje MySQL:

[client]
character-sets-dir=C:/Program Files/MySQL/share/charsets
default-character-set=cp1250

[mysqld]
character-sets-dir=C:/Program Files/MySQL/share/charsets
character-set-server=cp1250
collation-server=cp1250_czech_cs

Ale např. proměnná collation_connection bude nastavená na cp1250_general_ci a ne cp1250_czech_cs a přenastavit ji neumím.

PHP konfigurační soubor ale ignoruje a ke spolupráci ho přimět nedokážu. Jedinou cestou proto možná bude zkompilovat MySQL s volbou --with-collation: http://dev.mysql.com/doc/mysql/en/configure-options.html

Pavel Stěhule:

Teď jsem s kamarádem dodělaávali case sensitive collate pro češtinu, takže mohu potvrdit, že si přenastavením konfiguračních parametrů nepomůžeš. Leda šáhnout natvrdo do zdrojáků a přeložit.

Aleš:

Ahoj zajímalo by mě, jak je to s vytížením mašiny, jestli to někdo zkoumal, o kolik % zdrojů potřebuje verze 4.0 a 4.1 vic nebo min. Se 4.1 jsem mel zatim jen problemy, hlavne s exportem a phpko v error logu porad hazi chybu na chybejici charset. osobne bych radeji mel na novem serveru 4.0 nez 4.1. je nejaky padny duvod proc jit na 4.1, krome toho ze je to novejsi ?

ikona spaze:

rozdily mezi 4.0 a 4.1 jsou zasadni, napr. co se tyce podpory narodnich prostredi (razeni, ...).

Rozdil v zatizeni neznam, chybu s charsetem mam i u 4.0 (PHP4.3/Win32/Apache1.3)

Skiff:

Ahoj all,
resim naprosto totozny problem, co se tyka razeni (trideni) ulozenych zaznamu v MySQL 4.0.22 podle win-1250, uz jsem se dostal do stavu, kdy mi SELECTem a ORDER BY radi abecedne cesky, ale bez Ž a Š ty se ukazou, kde se jim to libi. Mam nastaveny 
[mysqld]
default-character-set=czech
a v php skriptu v configu:
mysql_query('SET CHARACTER SET cp1250_latin2', ~spojeni).
Mam prosbu pokud byste nekdo vedel jak toto vyresit byl bych Vam velmi zauzlovan.
PS: Neradte prosim, ze si mam sam zkompilovat MySQL,, protoze tak dobrej nejsem. Nekde sem se docetl ze prave vlastni kompilaci, kde odkomentuju v convert.cc radek
/* #define DEFINE_ALL_CHARACTER_SETS */ a zkompiluju, ale to nedokazu. Tak neco jineho. Diky

ikona Jakub Vrána OpenID:

Běhová podpora pro kódování (SET CHARACTER SET) je k dispozici až od MySQL 4.1, do té doby je možné kódování nastavit pouze společně pro všechny databáze. Pokud máš tu možnost, rozhodně doporučuji přechod.

V MySQL 4.0 se to nastavit dalo, ale přinejmenším bylo nutné mít adresář share\charsets v C:\MySQL.

Skiff:

Děkuji a šlo by nějak laicky popsat to nastavení, kde všude atp.? Na MySQL 4.1 zatím možnost není, i když v nejbližší snad jo. Ale do té doby bych to nějak potřeboval aspoň dočasně vyřešit. Předem děkuji za odpověď.

ikona Jakub Vrána OpenID:

Bohužel si to už přesně nepamatuji a MySQL 4.0 už nepoužívám. Zkuste http://diskuse.jakpsatweb.cz/index.php?act…&forum=9.

ikona spaze:

SET CHARACTER SET bylo mozne pouzit i u 4.0, ale tam to znamenalo pouze prekodovani z jednoho charsetu do druhyho. Takze kdyz data v DB jsou v ISO-8859-2 a ja chci vystup ve Win-1250, tak si to tim nastavim. Vyhodny to bylo/je zejmena v tom pripade, ze mame vystupy jak v ISO tak ve Win, ale databaze je nastavena pouze na praci v ISO. Muzeme tak dostat vystup pekne serazenej v obojim kodovani, nehlede na to, v cem operuje server. Typicky se to hodi pro shared servery.

K puvodnimu dotazu.. resenim je prenastavit server tak, aby pracoval ve Win1250.. default-character-set=CP1250, nebo tak nejak. NEkde v nejakejch variables (SHOW VARIABLES?) jsou uvedena podporovana kodovani.

ikona Jakub Vrána OpenID:

Jsem přesvědčen o tom, že MySQL 4.0 a nižší žádné překódování za běhu neprovádělo a se všemi daty se zacházelo jako s binárními. Nastavení kódování sloužilo pouze k určení toho, jak se data mají třídit.

ikona spaze:

me to tak podle souboru sql/convert.cc pripada. Navic mi to podle toho, jak jsem to pouzival, tak prislo. (Load dat v ISO-8859-2, vystup v Win1250, oboji razeno stejne) Ale mozna se jen pletu.

imploder:

Je možné nějak zařídit, aby šlo do databáze uložit data s kódováním windows-1250 a ve stejném kódování je i z databáze dostávat (pro zobrazení na stránce, která používá kódování windows-1250)? Popř. existuje nějaká funkce v PHP, která zajistí převod do utf-8 a zpět? Pro databázi si můžu vybrat jenom z různých verzí kódování utf-8.

ikona Jakub Vrána OpenID:

Pokud se jedná skutečně o MySQL 4.1, je celkem jedno, v jakém kódování jsou data uložená v databázi (pokud je kódování dostatečně obsáhlé a obsahuje české znaky, což UTF-8 je). Stačí příkazem SET CHARACTER SET nastavit, v jakém kódování se data budou posílat a v jakém je chceme dostávat a je to. Windows-1250 se podle MySQL jmenuje cp1250.

Příkazů na převod kódování je v PHP několik, nejlepší je asi iconv, ale nemělo by to být potřeba.

flam:

Mam problemy se zobrazovanim rustiny. Pouzivam databazi MySQL: 4.1.10. V db mam vytvorenou tuto tabulku (trochu jsem ji zjednodusil):
CREATE TABLE products(
  id int(10) NOT NULL auto_increment,
  name_cs varchar(100) NOT NULL default '',
  name_ru varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL default '',
  PRIMARY KEY  (id)
) TYPE=MyISAM;
Ke sprave pouzivam phpMyAdmin 2.6.2, v kterem vyctu tyto udaje:
Znaková sada v MySQL:  UTF-8 Unicode (utf8)
Znaková sada připojení k MySQL: utf8_czech_ci
Kdyz se podivam v phpMyAdmin na tabulku, tak se mi zobrazi krasna azbuka. Po zobrazeni vysledku SQL dotazu v PHP skriptu se mi ale zobrazi same otazniky:
$query = mysql_query("SELECT name_ru FROM products");
while($result = mysql_fetch_array($query)){
echo $result["name_ru"].'<br>';
}
Kodovani stranky jsem zkousel menit jak chci (utf-8, windows-1251) se stejnym vysledkem.
Nevite nekdo jak dostat data v azbuce z databaze, nebo nejaky sikovny odkaz? Predem dik

ikona Jakub Vrána OpenID:

Po připojení k databázi zavolej <?php mysql_query("SET CHARACTER SET utf8"); ?> a stránku posílej v kódování UTF-8: <?php header("Content-Type: text/html; charset=utf8"); ?>.

Radek:

Dobrý   den,  prosím  o  radu , mám podobný problém se zobrazením otazníků místo znaků ěčř. Charset stránky : <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Po otevření databaz. connection spoustim : mysql_query("SET CHARACTER SET utf8"); 

Bohuzel kdyz chi uložit do DB, výše jmenované znaky se uloží chybně. Nevíte v čem je problém?

Díky moc za radu

ikona Jakub Vrána OpenID:

Správně musí být nastavené i kódování databáze, o tom pojednává první část článku.

rik:

Pořád mam otazníky u ěčř a to už mam nastavene jak :SET CHARACTER SET tak i v my.ini tak i default-character-set a furt to nejede, tak už fakt nevim.

a:

Nejses sam s timto problemem. Mas chybne nasteveno collation_connection. Pouzij "SET NAMES utf8" i kdyz to tu bylo zatracovano.

Brian:

JOOOOOOOOO! No konečně mi někdo opravdu poradil. To set names opravdu fungovalo a už se mi nezobrazují znaky typu kosočtvereč-otazníček. Nastavil jsem to takto:

mysql_connect(...);
mysql_query("SET CHARACTER SET utf8");
mysql_query("SET NAMES utf8");
mysql_select_db(...);

Peane:

Ja mam proble pri vyberu z db mi to zobrazuje otazniky ale v db to mam ulozene normalne a vse mam nastavene spravne

crewer:

DÍKY!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Pavel:

Díky za radu.

ikona Jakub Vrána OpenID:

Pokud nefunguje SET CHARACTER SET a zabere SET NAMES, obvykle to svědčí o špatně nastaveném kódování databáze. Vyřešit by to mělo ALTER DATABASE db COLLATE ...

mark:

Ano děkuji, tohle přesně vyřešilo muj problem

ALTER DATABASE `jmenodatabaze` DEFAULT CHARACTER SET utf8 COLLATE utf8_czech_ci;

opravdu mám ale pocit že nastavení švédského kodovani jako vychoziho byl od tvurcu mysql opravdu velmi nepekny "podraz", imho naprosto zbytecna komplikace. Doufam ze v pristich verzich uz to bude utf-8

Igor Hízdo:

Měl jsem stejný problém s těmito třemi písmenky ěčř.
Jsem opravdu neskonale šťastný, že se mi to díky tomuto příkazu povedlo vyřešit. Celé mi to ale trvalo několik dní. Včera mi ještě nedocházelo, že po tom příkazu ALTER DATABASE se už nemusí žádný další CHARAKTER SET nebo SET CHARAKTER SET dělat. A právě díky tomu, že jsem ten SET CHARAKTER SET prováděl při každém spouštění docházelo k tomu, že se jinak správné kódování (to COLLATE) zase přenastavilo na defaultní hodnotu a proto chyba. A taky, že ALTER DATABASE stačí zavolat jen jednou...

Laik89789:

I já děkuju ;-)

Lukáš Kupka:

Jakube, i mi zabralo az SET NAMES po tom co nezabralo nastavené kódování DB, tabulky, i jedntolivých sloupcu na UTF-8. Vysvetlil bys mi podrobneji jakpakto?

Gabo:

Viete mi poradit ako zmenit globalne premenne z latin1_swedish_ci na utf-8 napr. ?

Pri instalacii php webshop-u sa mi totiz cela databaza vytvori v tom kodovani. A pri zmene kodovania hlasi mysql ILLEGAL COLLATION MIX.

Looky:

Mam v cele databazi nastaveno kodovani UTF8, vsechny sloupce maji collation utf8_czech_ci. Presto ma trideni radu nechtenych rysu - ignoruje rozdil "a" "á"; "i" "í"; "ú", "ů", "u"; presto ale tridi dobre "š", "č", "ř" apod. Mam nekde chybu? Nebo toto MySQL(verze MySQL 4.1.13a) neumi? Predem diky za odpoved...

ikona Jakub Vrána OpenID:

Odpovídá to pravidlům českého třídění. Podívej se třeba do telefonního seznamu nebo do rejstříku ulic, je to tam stejně.

Koli:

Uz tri dni sa snazim rozbehat kombinaciu
MySQL 4.1.14
PHP5.0.5
Apache2.0.54
Ale nech nastavujem akukolvek kombinaciu charsetov tak mi to cez prehliadac nezobrazi spravne. Je to pod WinXP. Cez Query Browser mozem zadat retazec 'ľščťžýáíéúäôňěřĺ' aj mi to spravne ukazuje. Ale ked dam cez prehliadac nacitat query tak sa mi zobrazi
'?š??žýáíéúäô????' zmenou kodovej stranky sa mi len zmeni len to ze miesto š a ž mam stvorcek. Poradte mi nejake nastavenie alebo mi rovno poslite config scripty (httpd.conf, php.ini, my.ini) na koli@koli.sk. Alebo mi vynadajte ze som hlupy. Ma niekto vobec uspesne rozbehanu kombinaciu MySQL4.1 a PHP5 s cs lokalizaciou? Ak ano tak mu poslat tie configuraky snad nepadne zatazko. Dik

<em>anonymní</em>:

Hele Koli, můžu se zeptat, taky zápasím s češtinou - když dáš SHOW COLLATION máš tam cp1250 teda přesně cp1250_czech_ci ?? Já ať dělám co dělám tak ne :-( A potom logicky když dám SET CHARACTER SET cp1250 MySQL zahlásí chybu... Dík za info

ikona spaze:

Combo MySQL 4.1.11, PHP 5.0.5, Apache 2.0.54, Win XP SP2, UTF-8 mi beha v pohode, zobrazuje jak ma. Konfiguraky snad nema cenu, neb si nepamatuju, ze by se v nich neco podstatnyho nastavovalo a ze by to vubec melo (mit) vliv.

Zkus nekde vystavit ten dump, kterej strkas do DB a skript, kterym to zas tahas ven a uvidime.

vrbcik:

Ahoj,
Mal som podobny problem. Po exporte tabuliek z hostingu a importe na nb som sice v phpMyAdmin diakritiku videl spravne, ale cez .php (na strankach) som mal namiesto niektorych znakov otazniky namiesto inych otaznik v stvorceku (server je utf-8).

Zabrala jednoducha vec:
za volanie mysql_select_db(nejakadb);
som zavolal:
mysql_query("SET CHARACTER SET latin2");
A vsetko funguje ako ma.

Michal:

Díky moc ! celej den se to snažím vyřešit a díky tobě mi to valí ;)

romann:

Dobrý den,

sháním k výuce na ekonomii MySQL pro tvorbu databází. Může mi někdo poradit, kde je česká verze i s manuálem (případně pár příkladů a pohled na tento program) nebo toto vše poslat na CD?

Děkuju

Roman Makrlík
romann.m@volny.cz
romann@atlas.cz

Koli:

Neviem coho cesku verziu zhanas. Databaza je len jedna a podporuje rozne lokalizacie. Myslim ze zatial nikto original manual MySQL neprelozil. Ja som kedysi zacinal s knizkou "MySQL za 21 dni" a mozem celkom odporucat za tu cenu. Ale staci zajst do knihkupectva a je momentalne min 5 roznych titulov len na tema MySQL tak staci nacriet do penazenky. I ked dnes uz osobne preferujem pouzivat len original anglicke manualy alebo HowTo, samozrejme az na lokalizacne problemy (vid vyssie)

Apropo tu cp1250 mi vypisuje ako skompilovanu a v samotnej databazi problem nevidim, lebo ako som uz spominal cez Query Browser ide vsetko OK na 100%. Samozrejme ze zatial mi to stale nefunguje. Ja odhadujem chybu niekde v PHP5, lebo na PHP4 taky problem nemam.

Koli:

Chcem len oznamit ze vsetko sa vyriesilo, ked som ked som hned po mysql_connect spustil query SET NAME S s kodovou strankou a este na zaciatku poslal Header znovu s kodovou strankou. Zda sa mi to trochu zbytocne, ale aspon sa nemusim starat o to ako je default nastaveny server.

petr:

Nemuzu se zbavit problemu s tridenim. Po prechodu na   Mysql 4.1 je ted databaze, tabulky i sloupce v kodovani:
latin1_swedish_ci
Texty ulozene v databazi jsou v cestine, velmi pravdepodobne v latin2 nebot generovane HTML stranky jsou v ISO-8859-2 a diakritika se zobrazuje v poradku. Jenom to razeni :(
napr. C s hackem se objevuje mezi D-E
S s hackem se objevuje az nekde po znaku '_' atd.
Nevite jak problem vyresit? I kdyby se mela cela databaze preklopit do nove, stoji to za to.
Diky.

ikona Jakub Vrána OpenID:

Je potřeba správně nastavit kódování jednotlivých sloupců:

ALTER TABLE tabulka MODIFY sloupec binary(100);
ALTER TABLE tabulka MODIFY sloupec varchar(100) COLLATE latin2_czech_ci;

První příkaz je nutný proto, že MySQL si myslí, že data jsou v kódování latin1 a při provedení pouze druhého příkazu by se je pokusila převést.

Provedením "ALTER TABLE tabulka COLLATE latin2_czech_ci" se navíc zajistí, že nově přidané sloupce budou mít dané kódování, po provedení "ALTER DATABASE databaze COLLATE latin2_czech_ci" budou mít dané kódování nově vytvořené tabulky.

Kromě toho je nutné v PHP skriptu databázi příkazem "SET CHARACTER SET latin2" oznámit, v jakém kódování s ní chceme komunikovat.

petr:

Diky za radu. Nejakou dobu jsem se neozyval, zkousel jsem ruzne reseni a kodovani.
Nakonec jsem zjistil toto:
Pri vystupu do prohlizece, kdy jsou vsechny sloupce,tabulky a db v latin1_swedish_ci, ale prohlizec koduje v ISO-8859-2, je vsechna diakritika OK, razeni blbe.
Pokud zmenim jeden sloupec (klicovy pro razeni) na typ binary, nic se navenek nezmeni.
Pokud tentyz sloupec zmenim zpatky na varchar s collate latin2_czech_cs podle naznaceneho prikazu, razeni u daneho sloupce je OK, avsak cestina je u nej blbe... taktez pro win1250_czech_cs, utf8_czech_ci a desitky jinych 'czech' co jsem zkousel :-(
Nebyla by jedna z moznosti:
- zalohovat databazi do souboru
- projet to na nahrazeni retezce latin1_swedish_ci za latin2_czech_cs
- obnovit databazi a pak pripadne vyladit nastaveni SET CHARACTER SET

???

Diky za odpoved
Petr

ikona Jakub Vrána OpenID:

Export a následný import je možný, ale zbytečný. Řekl bych, že problém bude v chybějícím provedení příkazu "SET CHARACTER SET latin2" v PHP kódu. Databáze si myslí, že s PHP komunikuje v latin1 a když vidí text v latin2, tak ho převede, takže se pak špatně zobrazí.

petr:

Uz jsem to vyresil. Napadlo me ze by to mohlo nekomu pomoci...

1. Udelat dump databaze do souboru
-> pozor at je prepinac vystupniho kodovani nastaveny na stejne kodovani jako je databaze
2. V souboru nahradit vyskyty 'latin1' za 'latin2'
-> pouzil jsem pritom linuxovy 'sed'. opatrne, at to nahradi jen pozadovane retezce! Ja vim, je to prasarna ale kdo ma neco lepsiho?
3. vytvorit databazi v kodovani latin2
4. uploadovat upraveny dump

Hezky cesky!

P.

ikona Jakub Vrána OpenID:

Podle mého názoru zbytečně riskantní a krkolomné. Postup s převodem kódování přímo v databází ja automatizován zde: http://php.vrana.cz/prevod-kodovani-mysql.php.

Singer:

Nerozumiem tvorbe tabulky s podporou UTF-8 pod mysql. Presiel som z PostgreSQL a potrebujem podobnu fukcnost aj pod mysql. Ked vytvorim tabulku:

CREATE TABLE mojatabulka (stlpec char(5)) DEFAULT CHARACTER SET utf8;

nastavil som (pravdepodobne by to malo nastavit DB na UTF8):
SET character_set_results=utf8;
SET character_set_connection=utf8;
SET NAMES utf8

ak spravim insert:

insert into mojatabulka (stlpec)values('ľščťž');

zapisu sa iba prve 2 znaky a prvy byte z tretieho. Nemala by databaza riesit aj to, aby sa dali retazce spravne zapisat? Alebo robim nieco zle? DB je 4.1.18. Dik

ikona Jakub Vrána OpenID:

"SET character_set_results=utf8; SET character_set_connection=utf8;" by mělo být zbytečné, protože to nastaví "SET NAMES utf8".

Ale popisované chování je zvláštní - ověřil bych, jestli posílané znaky jsou skutečně v kódování UTF-8 a případně provedl "SHOW FULL COLUMNS FROM mojatabulka ".

Singer:

ked vyberiem udaje z DB a dam ich zobrazit v prehliadaci, vystup je OK, teda zapisane udaje su v UTF-8.

pouzil som SHOW FULL COLUMNS FROM mojatabulka:
stlpec -> utf8_general_ci

Honza:

Ahoj, měl jsem stejný problém s UTF-8 (MySQL 4.1.12) - do databáze se mi ukládaly špatně znaky ě,č,ř,ů,ť a ň. Vyřešil to příkaz

SET COLLATION_CONNECTION='utf8_general_ci';

Nevím proč, ale pouhé nastavení kódování pomocí SET CHARACTER SET zřejmě nestačí.

Langi:

Zdtravim!
Mám prosbu, mohu nějak do MySQL do tabulky vložit obrázek??? Popř. jak?
Dík.

ikona Jakub Vrána OpenID:

Ano, obvykle se k tomu používá typ mediumblob a nějaký takovýhle kód:
<?php
$obsah
= file_get_contents($_FILES["obrazek"]["tmp_name"]);
mysql_query("INSERT INTO soubory (nazev, obsah) VALUES ('" . $_FILES["obrazek"]["name"] . "', '" . addslashes($obsah) . "')");
?>
Poslání souboru viz http://php.vrana.cz/posilani-souboru-pod-spravnym-nazvem.php.

Ale za normálních okolností bývá výhodnější ukládat soubory do normálních souborů.

Ota:

Se zobrazováním češtiny (utf8, mySQL 4.1.9) jsem také několik hodin zápasil. Přes všechna nastavování a laborování s COLLATE, SET a pod. jsem nakonec dosáhl kýženého výsledku takto jen přímým zadáním kódování do INSERTů:

Tabulku jsem založil s
COLLATE utf8_czech_ci
jednotlivá pole pak s
CHARACTER SET utf8 COLLATE utf8_czech_ci

Ve skriptu pro plnění i získávání polí pak postačí po napojení na databázi zadat mysql_query("SET CHARACTER SET utf8"); 
a upravit inserty takto:
INSERT INTO table_1 ( `col_1` ) VALUES (_utf8'přiliš žluťoučký kůň úpěl ďábelské ódy')

Asi to není zcela "čisté" řešení, ale již to tak nechám

Třídění jsem zatím netestoval.

ikona Jakub Vrána OpenID:

Řekl bych, že mohlo být špatně nastavené kódování databáze (SHOW CREATE DATABASE db). SET CHARACTER SET způsobí, že se na straně serveru data přeloží do kódování databáze. Pokud to bylo např. latin1, tak to nemohlo fungovat.

Ježek:

Ahoj, zkouším pracovat s MySQL 5.0.15, ale nemůžu rozchodit češtinu.
V MY.INI mám následující nastavení:
  [mysql]
   default-character-set=cp1250
   default-collation=cp1250_czech_cs
  [mysqld]
   default-character-set=cp1250
   default-collation=cp1250_czech_cs
Variables jsou nastaveny následovně:
  character_set_client            | cp1250
  character_set_connection        | cp1250
  character_set_database          | cp1250
  character_set_results           | cp1250
  character_set_server            | cp1250
  character_set_system            | utf8

  collation_connection            |cp1250_czech_cs
  collation_database              |cp1250_czech_cs
  collation_server                |cp1250_czech_cs

Vytvořím databázi a tabulku. Když chci do tabulky vložit větu:
  insert into k_nosic (kod, popis)
    values ('ab', 'ěščřžýáíé');

skončím chybou: MySQL connection error: #22001Data too long for column 'popis' at row 1

pole popis je varchar(50)

Používám WindowsXP a pro práci s DB freeware verzi Toad for MySQL. S obdobným výsledkem jsem zkoušel i s latin2, utf8.

Ještě dodatek - stejná chyba, když používám MySQL Command Line Client.

ikona Yuhů:

Děkuju za řešení v PHP, zmíněné v článku (to SET CHARACTER SET utf8). Mám ale problém v tom, že mám už hotovou aplikaci, která mi přesně tuhle chybovku hlásí. Tu cizí aplikaci se mi nechce prolézat, hledat tam desítky SQL připojení a ty opravovat.

Nedá se to prosím někde nastavit v konfituraci v MySQL? Když se přes PHPMyAdmin kouknu na informace o MySQL, tak tam je to zmíněno (ale jenom pro čtení).

ikona Jakub Vrána OpenID:

Zkusil bych v my.cnf nastavit collation_connection a případně i character_set_client a character_set_results.

jakub:

dzus lidi, mel jsem problem s prenosem dat z mysql 323 do 41. Pouzil vse zde napsane, jen se nechtel uchylit k trikum s bloby apod.

situace - puvodni data v "czech" kodovani - iso-8859-2 v html

nova db - latin2, latin2_czech_cs

s databazi po nakonekteni prohodim neco o SET NAMES 'latin2', v http i html mam iso-8859-2, presto zobrazuje spatne nadumpovana data

po dvou probdelych nocich mam reseni:

staci jeste pri mysqldumpu opet uvest o jake jde kodovani, cili nejak takto

mysql -p -u user --default-character-set=latin2 databaze<mujdump.sql

vse je ok ...

jakub:

zapomnel jsem dodat, jeste toto

SET NAMES sets the three session system variables character_set_client, character_set_connection, and character_set_results to the given character set. Setting character_set_connection to charset_name also sets collation_connection to the default collation for charset_name.

cili jsem jeste pro uplnost pridal dotaz do mysql, nasledujici po set names:

SET collation_connection='latin2_czech_cs'

pac jestli to dobre chapu, tak default latin2 coll. nemusi byt to Vase ...

ikona spaze:

Neni lepsi pouzit SET CHARACTER SET?

a:

to nestaci pokud se nepripojim ke konkretni databazi ale jen k serveru. Pak databazi vyberu pomoci az v prikazu mysql_db_query($dbname, $query);

TomS:

Ahoj,
uz spoustu casu se snazim prijit na to jak mam vlastne ted pod MySQl 4.1 nastavit my.cnf a jak pak upravit script v PHP. Driv jsem pouzival 3.23 a tam jsem si zprovoznil cp1250_latin2. Tim jsem ziskal pak ziskal spravne razeni.
U 4.1 jsem vsak normalne ztraceny, kde se da vsude nastavit kodovani. Pripadam si jak ve sportce :-)
Muze mi prosim nekdo napsat jak to.
V my.cnf mam toto:
[mysqld]
default-character-set=latin2
character-sets-dir=/usr/share/mysql/charsets/
language = /usr/share/mysql/czech/

S tim, ze data uz nejak prevedu, ale nevim jak to vse spravne nastavit. V jakem kodovani ukladat data aby se spravne radily. Kam kde co napsat nebo mne nekam dal nasmerovat.
Musim mit nastavene kodovani u databaze, tabulky i sloupce. Jake? Jde bez toho, abych musel upravit v PHP pripojeni k databazi.
Diky za odpoved nebo pomoc.

Gabriel:

Ahoj, mam takovyhle problem: updatnul jsem mysql na 4.1.15 z 4.1.14, php na 5.0.5 z 5.0.4 a apace na 2.0.55 z 2.0.54, po restartu slo vse naprosto v pohode, ale asi po 2 tydnech behu jsem resnul apace kvuli nejakym novym redirectum  a od te doby se mi rozsypala diakritika... v mysql mam kodovani nastaveno na utf8, collation na utf8_czech_ci a db i tabulky maji utf8_czech_ci, php.ini default_charset mam windows-1250...
Uz si fakt nevim rady, zkousel jsem snad vsechno (zmena mysql kodovani, php.ini...), menil jsem to i podle rad na tyhle strance... Dokazal by mi nekdo poradit co jeste zkusit, nebo jak jinak ten problem resit? Predem dik

burro.b:

zjisti jestli se ti neposílá standardní kódování v headeru, měl jsem stejný problém v IE s utf-8. Podle mě by změna výpisu <?php header("Accept-charset=*blablabla*;"); ?> v headeru pomohla, ale vyzkoušet jsem to na původním hostingu nemohl. Přesun jinam vše vyřešil.. jóóó, je to ještě pruda dělat vše utf-8:)

ret:

No to bych nerekl, uz pres pul roku nic jinyho nez utf-8 nesmi opustit moji dilnu. Prevadet data ze starsich databazi do mysql4.1+ je pruda. Nicmene vezte, ze vnitrne si mySQL4.1+ uklada vsehno jako utf-8, to v jakym kodovani to z nej pak vyleze zavisi na nastaveni SET NAMES 'kodova stranka' a take neni na skodu mu timto rict i v jakem kodovani jsou data, ktera rveme dovnitr, takze, pro zjednoduseni prace, neni nad to, spokojit se s faktem, ze utf-8 je prakticky vsespasne a pouzivat jej vsude kde to je mozne. Kez by se mi jeste podarilo zajistit, aby i cely linux environment jelo v utf-8  a uz mi nic ke stesti nechybi. :)

marinex:

Pouzivam mysql ver. 4.1.15 na win2000
mam nastaveno v my.ini
[mysql]
default-character-set=utf8
[mysqld]
default-character-set=utf8
Po pripojeni klientem mysql.exe
a zadani prikazu status; dostanu vypis take s temito udaji
Server characterset:    utf8
Db     characterset:    utf8
Client characterset:    utf8
Conn.  characterset:    utf8
Take pri dalsi praci s mysql neni zadny problem, tedy pokud pracuji na prikazove radce s mysql.exe
Kdyz ale spustim php script s pripojenim na mysql "SELECT ...." tak dostanu v error.log na apachi toto:
File 'c:\mysql\share\charsets\?.conf' not found (Errcode: 22)
Character set '#33' is not a compiled character set and is not specified in the 'c:\mysql\share\charsets\Index' file
Myslim si ze veskere nastaveni mam dobre, tak jsem se podival do sveta a nasel. Nechal jsem si vypsat co se deje:
<?php
//pripojeni k mysql a pak nasledujici:
$charset = mysql_client_encoding($link);
printf ("current character set is %s\n", $charset);
?>
a
vysledek:
"current character set is latin1"

Tomu vazne nerozumim na mysql serveru je nastaveno vse na utf8 vcetne Conn.  characterset:    utf8 viz vyse.

Odkazy kde jsou o tom nejake info:
http://bugs.mysql.com/bug.php?id=312
http://bugs.mysql.com/bug.php?id=5383
http://bugs.mysql.com/bug.php?id=8420

Ale po precteni nejakych info mi prijde ze PHP klient nedokaze komunikovat s utf8.

Proc o tom pisu? Zajimalo by me jestli jste narazili na stejny problem a jestli nemate nejake reseni. Diky za vase info do teto diskuze

Jirka:

Problém s phpMyAdmin po přechodu mysql 3.23 na 4.1.11

Prosím o radu, co dělat v této situaci:
měl jsem PHP aplikaci, která ukládala data v kódování win1250 do tabulek v 3.23, zobrazování opět v win1250; při přechodu na 4.1.11 jsem prachsprostě překopíroval MYD MYI a frm soubory, vše v 4.1.11 funguje, PHP aplikace data zobrazuje správně česky, ale problém je teď v phpMyAdminu 2.6.2 (zkoušel jsem starší i novější verze), kde se špatně zobrazuje např. č a ů, ale jiné znaky jsou správně (např. š).

Jestli tomu dobře rozumím, tak 3.23 žádné kódování neřešila, co si tam aplikace uložila, to tam měla. Teď si 4.1.11 myslí, že data jsou v latin1, dále si myslí, že aplikace komuikuje v latin1 (protože aplikace nevolá žádné speciální SET CHARACTER SET ani nic jiného) a tak nic nekonvertuje a pošle aplikaci to, co aplikace vypíše jako win1250 obsah. Z toho by mi vyplývalo, že phpMyAdmin je "moc" inteligentní a proto dochází ke konverzi z latin1(které ve skutečnosti latin1 není) do něčeho, o co si phpMyAdmin řekne.

Prosím jestli někdo nevíte, jak to řešit. Nejraději bych preferoval radu, jak nastavit či ošálit phpMyAdmin. Do PHP aplikace bych nerad zasahoval, z toho vyplývá, že bych také nerad kovertoval tabulky. Na downgrade na 4.0 už je také pozdě.... ach jo. Někde jsem četl o změně kódování na BINARY, ale je to risk, nevím, jestli by to pomohlo, a už vůbec nevím, jestli by nepřestala fungovat samotná apliakce.

Předem dík za radu

ikona Jakub Vrána OpenID:

Doporučuji to rovnou udělat pořádně: Tabulky převést na správné kódování (viz http://php.vrana.cz/prevod-kodovani-mysql.php) a do aplikace přidat jediný řádek se SET CHARACTER SET (pokud bys mohl změnit konfigurační soubor MySQL, tak není potřeba ani to). Pak ti bude fungovat nejen phpMyAdmin, ale třeba i české řazení.

venclj:

Renesance problémů s kódováním. Z MySQL 4.0 jsem přehazoval data na hosting. data byla uložena v utf8; dump je v tomto kódování, hostingová databáze má veškeré vlastnosti nastavené na utf-8; všchno se tak tváří, ale při na stránce je vždycky v ISO-8859-2; Všechny skripty jsou v utf-8; kódování stránky taky. Čím to ještě může být?

ikona Jakub Vrána OpenID:

Nastavuje aplikace SET CHARACTER SET utf8?

venclj:

Právě že jsem při tom pročítal tenhle článek, vyzkoušel jsem snad všechno, co je v něm napsáno, i to, co jsem našel v diskusi. Na hostingu PHPMyAdmin pracuje s utf v pohodě, jenom mě to pořád vracelo (a vrací) výsledky v ISO. Nakonec jsem rezignoval a celý výstup nechal v ISO a ten pak převedl do utf. Nicméně problém nevyřešen

Bear:

Dobrý den,

přecházím z free hostingu na placený, bohužel jsem si moc nepomohl, protože z MySQL 4.1.16 musím přejít na MySQL 4.0.13, což s sebou nese problém s naimporotováním dumpu databáze. Při importu to hlásí chybu:

#1064 - You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near

'collate latin2_czech_cs NOT NULL default '',
`heslo` varchar(

bohužel nejem právě odborník na syntaxi MySQL, nicméně připadá mi, že problém bude někde v tom že asi určitá syntaxe z dumpu je na verzi 4.0.x nepodporovaná. Co ale
změnit? (Na starém hostingu to chodilo bez problému, export a zpětný import jsem dělal mockrát).

Dík za jakoukoliv radu.

Kepi:

Doporučuji použít phpMyAdmin. Jde v něm vyexportovat data se zpětnou kompatibilitou, ty potom nahrajete na 4.0 v pohodě...

Bear:

phpMyAdmin samozřejmě používám, ale nic takového jako zpětná kompatibilita syntaxe SQL tam nastavit nejde.

Kepi:

No, docela bych se i vsadil :)

Nechce se mi dělat screenshot, nicméně záložka Export, rámeček Nastavení SQL exportu, volba "Kompatiblita SQL Exportu". Používám to celkem často, takže věřte že to tam je.

Pokud volbu nevidíte, rozhodně používáte nějakou starou verzi phpmyadminu...

Kepi:

Doufám, že to vyřeším dřív než mi někdo odpoví :) ale když už tu někdo odpoví, pomůže to dalším.

Mám na serveru MySQL 5 s nastavením výchozího kódování na utf. Všechno fungovalo bez potíží až do doby, kdy jsem upgradoval php na verzi 5.1 Od té doby mám všude kde je spoléháno na výchozí utf špatné kódování. Pomocí SET NAMES to bez problémů vyřeším, ale potřebuji, aby to prostě fungovalo i bez toho.

Pokud může někdo poradit, jestli si php neurčuje nějaké výchozí kódování nebo něco podobného, budu rád.

Díky

Milan:

Pomůže mi někdo vyřešit tento problém?
Mám MySQL 4.1.12, PHP 5.0.4, Apache 2.0.54, phpMyAdmin 2.6.4. Znaková sada  UTF-8.
Samozřejmě vše nastaveno na UTF-8.Nemám problém ani v PHP,ani v phpMyAdminu.Vše chodí tak,jak má.
Jediný problém mám v propojení databáze se scripty v Perlu.Neví někdo,jak se v tomto případě nastaví znaková sada na UTF-8?

Kuba:

Zdravim Vsechny

mam dost rozvlekly problem s tim primet muj e-shop aby zobrazoval spravne ceskou diakritiku. Zdrojak e-shopu je ve win-1250 a db je v utf-8. Nezobrazuje se mi spravne "ě, ř, ů, č"  Muze mi nekdo poradit co kde nastavit za kodovani?

dik

Flexa:

Ahoj.

Nevěděl by někdo jak vyřešit tento problém...

Komunikace mezi databází a webem mi funguje v dobře, jen bych potřeboval ve výběru jeden ze záznamů převést na ascii, abych to nemusel dělat v php. Zřejmě nedokážu správně složit dotaz...

Díky moc

jimmy:

zdravim, mohl by mi nekdo poradit s nasledujicim problemem? Musel jsem upgradovat PHP na v5 (MYSQL je 4.0.23a tusim), po tomto upgradu se v PHPMyAdminovi deje nasledujici: prihlasim se v pohode, vidim seznam databazi, mohu se podivat i na strukturu databaze, ale jakmile dam "PROJIT", abych videl radky urcite tabulky, tak se zobrazi prazdny frame. S verzi PHP4 problem nebyl. Zkousel jsem i posledniho PHPMyAdmina 2.8.1 a zadna zmena. Opet vidim vse (i prava uzivatelu) mimo radku tabulky pri prochazeni (SELECT ...). Poradite prosim nekdo? diky

Patrik:

Tak se mi konečně podařilo nastavit správně ukládání českých dat do databáze. Bohužel je v jedné tabulce použit datový typ SET, který má nastaveno porovnávání na "latin1_swedish_ci" Toto pak hlásí chybu "Illegal mix of collations". Lze porovnávání tohoto typu změnit nebo musím nechat naprogramovat danou funkci jinak? Jde o výběr id admina z databáze a nastavení práv.
Díky moc všem znalejším:-)

muf:

pri prevodu -latin1- me pomohlo toto: na novem hostingu vytvorit db tables s charsetem utf8_general_ci, nalejt data ze stareho a pred vystupem dat klasicky set, v mem pripade mysql_query("SET CHARACTER SET cp1250");

noSetNames:

A pomohlo by toto?

[mysqld]
init-connect = 'SET NAMES cp1250'

olle3:

ahoj prosim vas nemáte někdo příkaz na nastavení kodovani pripojeni k databazi ? diky

Jirka:

Mám jeden drobný problém se zobrazováním českých znaků v phpMyAdmin.
Používám MySQL 4.1.21 a phpMyAdmin 2.9.0.2.
Databáze má nastaveno kódování utf8_general_ci (zkoušel jsem i utf8_czech_ci nebo utf8_unicode_ci).
V phpMyAdmin jsem zkoušel také všechny tři.

A nyní k problému.
Používám web aplikaci pro diskusní fórum phpBB v 2.0.22 v kódování UTF-8. Jakmile v aplikaci zapíšu nějaký příspěvek obsahující diakritiku (např. ěščřžýáíé), tak se v phpBB zobrazuje vše správně, ale v phpMyAdmin vidím jen nějaký paskvil znaků.

Není to sice až tak nutné, ale pokud bych chtěl text upravit přes phpMyAdmin, tak nemůžu, protože jakmile zapíšu znaky s diakritikou, tak nově zapsané znaky se v phpBB nezobrazí správně.
Zjistil jsem, že se zobrazí správně když v prohlížeči nastavím win1250. Je to divné.

Určitě to bude jen nějaká hloupost, ale nemůžu na to přijít.

Poraďte prosím.

Díky

ikona Jakub Vrána OpenID:

Záleží také na kódování sloupců, ve kterých jsou data uložena. Pokud je nastaveno správně, tak asi phpBB nenastavuje kódování správně.

Peter001:

Zdravim;
1)
vobec nechapem, preco je tu tento problem s kodovanim. Ja som instaloval MySQL take ako som ho stiahol z mysql.com (3.23.xx aj 5.0.xx) a nic som s kodovanim nemenil.
Mam stlpce varchar a ukladam tam HTML stranky (presne tak, ako ich ziskam zo socketu). Ci je stranka v UTF-8 alebo windows-1250 (v akom kodovani je ulozena stranka mam zaznamenane v dalsom stlpci a pri zobrazeni podla toho nastavim http charset header; tot vsjo), stale mi to zobrazuje spravne; ceske aj slovenske znaky.
Tak preco nastavovat to kodovanie a riesit tolko problemov ? Vo varchar-e sa zaznamena retazec presne tak, ako ho tam poslem; to iste pri jeho nacitani. Nerozumiem, naco nastavovat teda jeho kodovanie (snad len okrem jeho triedenia) ?

2)
Da sa spravit to, ze i ked mam ulozene retazce (napr. meno) s diakritikou, tak mi ho najde aj ked zamenim znaky za znaky bez diakritiky (napr. mam v databaze "Skála" a chcem ho najst aj ako "Skala")?

Dakujem za odpoved.

ikona Jakub Vrána OpenID:

Důvody pro používání kódování jsou tyto:

1. Správné třídění a porovnávání.
2. Při uložení řetězce v UTF-8 do sloupce s jednobajtovým kódováním se tam řetězec nemusí vejít, protože má více bajtů, než kolik má sloupec vyhrazeno. Při správně nastaveném kódování se bere počet znaků.

Není pravda, že se do varcharu uloží přesně to, co se tam pošle. To platí jen v případě, že jsou všechna kódování nastavena stejně.

Způsob porovnávání utf8_czech_ci skutečně ztotožňuje znaky s diakritikou a bez diakritiky.

neoen:

Zdravím,

jde nějak udělat, aby byl jeden SELECT z MySQL zobrazen pomocí SET NAMES utf8 (kódování utf8), zatímco všechny ostatní SELECTY (které si sahají do jiných tabulek) ve skriptu byly v jiném (defaultním) kódování?
Díky...

Vita:

Nevite nekdo jak toho sameho docilit na MS SQL? Na MySQL mi jede vse OK. Ted ale porebuji sprovoznit aplikaci na IIS+PHP5+MSSQL a nedari se mi hnout s diakritikou. Na stránce v kodovani UTF8 se mi nezobrazuji hacky :-(.

Adams:

Ahoj lidi,
poradí někdo? Při pokusu o
INSERT INTO SOLPTP (PTPNAZEV, PTPCENA_) VALUES ('Měsíční',350.00), ('Čtvrtletní',1150.00), ('Roční',3200.00);

dostávám ERROR 1406 (22001): Data too long for column 'PTPNAZEV' at row 1. Je to českými znaky č,ě apod.

Když tam tykové znaky nejsou, insert projde.

Tabulka se vytváří takto:
CREATE TABLE SOLPTP (
    PTPPK___ MEDIUMINT NOT NULL AUTO_INCREMENT,
    PTPNAZEV VARCHAR(32)  DEFAULT ''     NOT NULL,
    PTPCENA_ DECIMAL(7,2) DEFAULT '0.00' NOT NULL,
    PRIMARY KEY (PTPPK___)
);

A celá databáze jednoduše CREATE DATABASE SOLAR;
ale experimentoval jsem i s nejrůznějšími kombinacemi znakových sad, např. DEFAULT CHARACTER SET cp1250 COLLATE cp1250_czech_cs atp. U některých to neřve, ale znaky jsou pak zkreslené.

Díky, Adams

Opty:

Ad problemy s cestinou:

http://molhanec.net/mysql_cestina_minifaq.html

Doporucuju SET NAMES. ;-)

Máco:

Teď jsem řešil, taky problem kodování češtiny pro správné zobrazování v prohlížeči. SQL jsem nastavil, tak jak je uvedeno nahoře v návodu, ale při
<meta http-equiv="Content-Type" content="text/html; charset=utf8">
<?php
mysql_connect
();
mysql_query("SET CHARACTER SET utf8");
?> my to špatně vypisovalo ř.
místo toho jsem použil následující:
<meta http-equiv="Content-Type" content="text/html; charset=1250">
<?php
mysql_connect
();
mysql_db_query("imo-star98_cz","SET CHARACTER SET cp1250");
?>
a vše konečně funguje tak jak má...:), tak snad to někomu, třebas pomůže.....:))

ikona Jakub Vrána OpenID:

SET CHARACTER SET používá porovnávání databáze, proto je nutné ho provést až po výběru databáze. Do příkladu jsem tento příkaz doplnil, děkuji za pošťouchnutí.

libor:

boze ani nevies ako si mi pomohol:))) googlim uz hodiny a nic nepomahalo a vobec neviem co je to mysql_db_query("imo-star98_cz","SET CHARACTER SET cp1250");
ael toto jedine mi pomohlo!!!!

DIKI

Shtroodle:

Dobrý den,
po několika hodinách zoufalství jsem se rozhodl, že sem zkusím napsat - tak doufám, že si mého dotazu někdo všimne.
Mám problém s ukládánim dat do databáze. K zadáni záznamů používám flashový formulář který při potvrzeni záznamu posílá proměnné souboru "insert.php", který je pak ukládá do databáze. Kámen úrazu zřejmě spočíva v tom, že data v databázi se ukládaji jako obrovská hromada nesmyslů (místo znaků s diakritikou tam vidím všemožné podivné kombinace písmena "A" a různých symbolů). Flash posíla data v kodováni UTF-8, v souboru "insert.php" jsem všechno nastavil podle zdejších instrukcí, a databáze samotná má nastavené kódováni jako "utf8_bin". Může mi někdo prosím poradit co dělam špatně?
V souboru "insert.php" mám tohle:

<?php header("Content-Type: text/html; charset=UTF-8");

$id = $_GET["id"];
$day = $_GET["day"];
$month = $_GET["month"];
$year = $_GET["year"];
$message = $_GET["message"];

$username="jmeno";
$password="heslo";
$database="databaze";

mysql_connect("mysql3.freehostia.com",$username,$password);
mysql_query("SET NAMES 'utf8'") or die('Could not set names');
@
mysql_select_db($database) or die("Unable to select database");

$query = "INSERT INTO news VALUES ('$id','$day','$month','$year','$message')";

mysql_query($query);
echo
"Values Inserted\n";
mysql_close();

print
"vars = " . $message; //. ", " $month . ", " $year . ", " $message . ". ";

?>

Napadlo mě ještě zvlášť nastavit kódováni pro každou z těch proměnných získaných z flashe, ale nejsem si jistý jak na to (případně jestli to má vůbec nejaký smysl).
Předem děkuji za jakoukoliv odpověď.

helt:

Zdravim,

jako skoro kazdy kdo sem pise i mam nejaky zadrhel, ktery brzdi. Existuje prostredi na Mandriva Linux 2007:

LANG=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_NAME=cs_CZ.UTF-8

bezi na nem mysql kdy z commandu zadam \s vypise se:

Server characterset:    utf8
Db     characterset:    utf8
Client characterset:    utf8
Conn.  characterset:    utf8

nastaveni serveru
[my.cnf]

[client]
default-character-set = utf8

[mysqld]
default-character-set = utf8
character-set-server = utf8
collation-server = utf8_czech_ci

http://dev.mysql.com/doc/refman/5.0/en/mysql-set-character-set.html

v php scritpu CLASS DB>>
<?php
$this
->connection = @mysql_connect($this->host, $this->user, $this->pass);
        $this->connected = mysql_select_db($this->dbname);

mysql_query("SET character_set_connection=latin2_czech_cs;");
    mysql_query("SET COLLATION_CONNECTION latin2_czech_cs");
        mysql_query("SET character_set_results=latin2_czech_cs;");

    mysql_db_query("umgtest1","SET CHARACTER SET latin2");
    mysql_db_query("umgtest1","SET CHARACTER SET latin2");
?>

kdyz si pak dam vypsat:

session_start();
$db = new db();
$charset = mysql_client_encoding();
printf ("current character set is %s\n", $charset);

vypise mi latin1.

ikona Jakub Vrána OpenID:

Tipnul bych si, že je špatně nastavené kódování u databáze. Vyzkoušej SHOW CREATE DATABASE umgtest1.

helt:

jeste pro uplnost:

CREATE DATABASE `mujweb` CHARACTER SET latin2 COLLATE latin2_czech_cs;

helt:

ten skript jsem opravil:

mysql_query("SET character_set_connection='latin2_czech_cs'";
mysql_query("SET COLLATION_CONNECTION= 'latin2_czech_cs'";
mysql_db_query("mujweb","SET CHARACTER SET = 'latin2'");
mysql_query("SET character_set_results='latin2_czech_cs'");

JirkaRybka:

Řešil jsem taky problém s češtinou (na desktopu pod Linuxem Mandriva 2007 mám čerstvě udělanou testovací lokální instalaci Apache+php+MySQL 4.1, kam jsem potřeboval pro testování okopírovat živý web). Jakožto začátečník preferuji hotové RPM, a tudíž jsem nesehnal totožnou verzi jako má živý server (4.0 - aspoň jsem hledal co nejbližší), a čeština zastávkovala.

Změnil jsem si default na utf-8 v my.cnf, vytvořil databázi explicitně v utf-8, php-aplikace má už v sobě sama 'SET NAMES utf8', a do databáze jsem importoval dump udělaný z on-line serveru (MySQL 4.0, tedy bez informace o kódování, ale data už tam jsou dávno také v utf-8), přičemž můj Linux na němž to celé dělám jede samozřejmě taky plně na utf-8. Člověk by čekal že nebude problém, když je kódování všude jen utf-8, ale omyl-pořád to bylo rozbité a nemohl jsem na to přijít.

A nakonec řešení které mě stálo hodiny trápení: Přidat aspoň provizorně 'SET NAMES utf8' také do php-aplikace pomocí které dump importuji! Konkrétně používám německý "mysqldumper 1.21 b6", který na rozdíl od PhpMyAdminu dokáže exportovat i velkou databázi na webhostingu, kde by jinak překážel časový limit php, a tato aplikace zjevně 'SET NAMES' sama nemá. Data v tabulkách pak na první pohled vypadala jako utf-8, na druhý pohled ale byla zakódovaná dvakrát: Každý byte z původního utf ještě znovu kódovaný do utf (tedy 4 byty na písmeno)! To pak samozřejmě žádným nastavením nešlo rozkódovat.

Tak možná že nejsem sám, kdo toto přehlédl a tápal, možná to někomu pomůže.

ikona Havran:

Dakujem za radu! Pomohla mi 2x (150Mb SQL subor je dost problem cez phpMyAdmina importovat a SET NAMES UTF8 pomohlo aby diakritika bola ok). Este dodam kam ho treba dopisat - v adresari kde mate mysqldumper nainstalovany si najdite subor restore.php a v nom riadky

<?php
MSD_mysql_connect
($restore['dump_encoding']);
mysql_select_db($databases['db_actual']) or die($lang['db_select_error'].$databases['db_actual'].$lang['db_select_error2']);
?>

a za ne dopiste

<?php
mysql_query
('SET NAMES UTF8',$config['dbconnection']);
?>

Este raz diky.

Bob:

Zdravim všecky kodery. uz si tes nevim rady :D PHP skript mam kodovany v UTF-8 ,dokonce jsem soubor v tomto formatu i ulozil,coz eliminovalo chybu s neznamym symbolem. Zdalo se to v klidu,vytvoril sem databazi ,nastavil KODOVANI NA
UTF-8_CS a porovnavani na to same . Ulozil jsem do databaze par tabulek ,v nich par zaznamu. kdyz vypisuju vsechny radky je vse ok,ale pokud zacnu vybirat radky 'prikaazem LIKE' kde je uloženo ščřžýáíé ,proste některe ceske znaky tak mi databaze vrati zpet prazdny vysledek. Pokud v zaznamech nejsou hacky ,databaze vrati presne to co jsem chtel. proc proboha nejde pri spravne konfiguraci tridit podle ceskych znaku.
viz kod

$vysledek=mysql_query("SELECT * FROM `tabulka` WHERE `klic` LIKE 'řezací nástroje'  ");
echo "V tabulce je ".mysql_num_rows($vysledek)." zaznamu" ;
while ($zaznam = MySQL_Fetch_Array($vysledek))
{
   echo $vysledek['data'];
}

,pokud tedy mam v tabulce tabulka nejake klice s klasickymi pimsenky a vyberu je ,vypisou se vsechny jejich data. neni zadny problem,jakmile pouziju nejaky česky znak,nedela to u vsech :D je najednou zaznam neviditelny a ve vysledku i kdy je zaznam v databazi neni vubec nic .D Dik za cokoliv co mi pomuze .

ikona Jakub Vrána OpenID:

Na začátku skriptu pravděpodobně chybí <?php mysql_query("SET CHARACTER SET utf8"); ?>.

Andrew:

Ahoj Jakube, převáděl jsem rozsáhlou aplikaci do utf a velmi mi pomohli všechny Tvoje příspěvky na toto téma, takže za ně moc dík (ještě pár lahůdek bych doplnil, ovšem jinak to bylo dosti všeobsažné). Narazil jsem ale na problém, který mi přijde celkem neobvyklý, tak s tím jdu na veřejnost. :-)
Databázi mám v utf, aplikace v utf, všechny hlavičky posílám správně, nastavuji dobře CHARACTER SET a vše je skvělé. Jen ještě doplním, že mysql server má defaulntě latin2.
Čas od času se mi ale stane, že ukládaná data se zcela rozsypou. Zkuusil jsem tedy vypisovat proměnné prostředí za běhu a zjistil jsem, že přestože správně zavolám CHARACTER SET utf8, proměnná character_set_connection občas obsahuje latin2.
Děje se to zcela náhodně, takže se to těžko testovalo. Jedinné co mě napadlo, jestli to nesouvisí s persistentním připojením, které používám, neboť na serveru běží i jiné aplikace v latin2 a tedy jestli PHP nějak s těmito připojeními nešachuje. Setkal jste se s tím někdy někdo?

ikona Jakub Vrána OpenID:

Asi je to zbytečné zmiňovat, ale SET CHARACTER SET je potřeba zavolat až po vybrání databáze, která navíc musí mít správně nastavenou znakovou sadu. Nic jiného mě nenapadá.

Andrew:

Dík moc za rychlou reakci. Nenapadlo mě to, ale opravdu jsem nastavoval znakovou sadu hned po spojení a ne až po zvolení databáze. Hned to opravím a otestuji. Jestli je to tím (jako že asi ano, protože connection je pak latin2, což mám jako defaultní pro celém mysql), tak se omlouvám za hloupou chybu - měl jsem nejdřív ověřit všechny připomínky v diskusi.
Nicméně narazil jsem v diskusi na http://cz.php.net/mysql_pconnect na zmínku o tomto problému právě v souvislosti s persistentním připojením, takže jsem také nebyl daleko od pravdy. Typuji to ale u sebe opravdu na výše zmíněnou blbost a persistentní spojení způsobovalo onu nahodilost.
Btw: Co je to správná znaková sada db? To jako že musí být schopna pojmout dané znaky? Pokud ano, tak myslím, že utf8 by mělo stačit (i na ruštinu a španělštinu, kterou používám) :-)

Lucky62:

Mám server 4.0.26-log (zistené z mysql_get_server_info). Defaultne je nastavený na latin1.

SHOW VARIABLES LIKE 'CHARACTER%' ukáže toto:
character_set      latin1
character_sets     latin1 big5 cp1251 cp1257 croat czech danish dec8 dos estonia euc_kr gb2312 gbk german1 greek hebrew hp8 hungarian koi8_ru koi8_ukr latin1_de latin2 latin5 sjis swe7 tis620 ujis usa7 win1250 win1251ukr win1251

V niektorých tabuľkách aktualizujem dáta programom spúšťaným na win stroji, ktorý sa pripojí k mysql (používa pri tom MySQL ODBC driver) a generuje príkazy INSERT. Príkazy sú zasielané v iso-8859-2.

Dáta z týchto tabuliek sa ale kupodivu zobrazia správne pri nastavenej kódovej stránke html dokumentu na windows-1250.

Pritom neposielam serveru príkaz pre nastavenie kódovania SET CHARACTER SET xxx ani pri plnení tabuliek (príkazy insert), ani pri ich čítaní (príkazy select).

Kde nastáva konverzia? Viem nejako zistiť, v akom kódovaní sú dáta skutočne uložené v databáze?

A druhý problém - neviem nastaviť slovenské triedenie.
Príkaz SET CHARACTER SET cp1250_latin2 nazabral.

Inak neviem nikde nájsť vysvetlenie syntaxe tohoto príkazu pre server vyššie uvedenej verzie.
"cp1250" je kódová stránka a "latin2" je triedenie?
Ako zistím, aké kódové stránky a triedenia sa dajú na serveri nastaviť?

ikona Jakub Vrána OpenID:

Doporučuji přechod na MySQL verze alespoň 4.1, kde je vše jasnější. Co si tak matně pamatuji, tak ve starších verzích sloužil příkaz SET CHARACTER SET k transparentnímu převodu kódování, ale bylo potřeba mít nainstalované nějaké převodní tabulky. "cp1250" i "latin2" jsou kódování a určují z čeho na co se má převádět.

Lucky62:

Prechod na vyššiu verziu nie je možný - je to server providera .

Petr "Kyslik" Kysela:

Čau chlapi. Taky jsem se chytil do pasti znakových sad a dalo mi dost času než jsem to vyřešil. Četl jsem diskuze, zkoušel jsem co šlo a ono to nešlo... Tady na vráně je dost příkladů podle kterých jsem zkoušel znovu, vystřídal jsem tři editory a nakonec jsem v tom měl takový guláš, že jsem nevěděl kde mám jaké kódování nastavené. A najednou to běhalo ěščřžýáíéďťň se objevilo korektně :D     A jaké je to záhadné nastavení? Na samotném webu: windows-1250, v MySQL: utf8_czech_ci a při přidávání nových řádků do databáze je to také windows-1250...  Když jsem měl všede UTF-8, tak tam strašný znaky, opačně zase samá AAA v databázi. Tohle byla snad jediná funkční varianta...

Pokud ovšem máte nějakou radu, sem s ní.
Ciao.

Jožo:

V my.cnf sa dá zmeniť default severa aj všetkých klientov na UTF-8 takto:

[mysqld]
character-set-server=utf8
collation-server=utf8_slovak_ci
skip-character-set-client-handshake

Pri tejto konfigurácii už netreba zadávať COLLATE pri vytváraní databázy alebo tabuľky a takisto netreba príkaz SET CHARACTER SET utf8 pri každom pripojení klienta.

Michal:

Dobrý den,
Máme Toad verzi 9.1 a problem je v tom že když  je v selectu použit český znak v tomto případě třeba Ú, tak to nechce uložit do xls. Při ukladani to vyhodí chybu
An invalid character was found in text content.
               .
               Line:_97
               <LITERAL type="text" value="&apos;B

problem je jen u českych znaku, jinak vše funguje, fonty jsem zkotroloval.

děkuji

Piskoř:

Ahojda, pokud by se s tim jeste nekdo trapil jako ja, tak funkcni reseni jsem nalezl na:

http://www.detepak.cz/clanek-znakova-sada-utf8.html

Scremsi:

Ja som uz pouzil vsetko mozno aj tak sa to nezmenilo ukazuje sa tam kodovanie UTF8 ale aj tak nemozu byt v db specialne znaky a diakritika :(

Marty:

Nevěděl by někdo, jak vyřešit problém: Potřebuji porovnávat case-insensitive dva sloupce z různých tabulek a přitom nemůžu použít funkci lower(), protože se přestane používat index na sloupcích a dotaz je hrozně pomalý. Zbývá tedy asi najít vhodnou collation, nicméně nechci, aby např. á = a, jak je to v utf8_czech_ci. Díky předem za nápady!

Zdeny:

Dobrý den, mám malý problém s databází, na localhostu mi vše běhá v pořádku, po nahrani na hostingový server se ovšem při uložení jakékoli informace se do databáze uloží pouze čislo identifikace a ostatní informace(jmeno, adresa, telefon) se uloží s nulovou hodnotou. Setkal kste se někdo s něčím podobným?
Použil jsem zdrojové soubory z této stránky: http://interval.cz/clanky/databaze-kontaktu-v-php-5/

fanky:

díky!
nevím, proč jeden server čte stejnými skripty databázi se stejným porovnáním jinak, ale SET CHARACTER SET solved the case.

Pavel:

Kódování UTF-8

Měl jsem velký problém s kódováním UTF-8, nezobrazovaly se mi znaky s háčky.
Tabulka v MySql nastavena na UTF8 general, Apache nastavený na default UTF-8, hlavičky v prohlížeči byly UTF-8, kódování ve skriptu nastaveno na UTF-8,ale znaky se mi zobrazovaly špatně. Koukal jsem na databázi v MySQL Workbench, znaky byly, to samé v prostředí HeidiSQL. Nechápal jsem, proč prohlížeče takto blbnou. A víte co pomohlo? Přidal jsem do skriptu po spojení s databází tento řádek: mysql_query("SET NAMES 'utf8'");
Hotovo, vyřešeno, nechápu, znaky se zobrazují správně! :D

Moc by mě zajímalo proč toto musím přidávat když mám vše dobře nastavené :D

dejv89:

Do háje, člověče, díky moc!

Jan Vítek:

Nádhera, měl jsem úplně stejný problém - vše správně nastaveno a přesto se mi do DB ukládaly "divné" znaky místo háčků a čárek. Díky moc za SET NAMES - pomohlo - KONEČNĚ :D

Igor:

Možná někoho bude zajímat tento článek:
http://kb.mediatemple.net/questions/138/Default+…+collation#gs

Zaujalo mě toto:

"You can change the character set and collation of your databases and tables through phpMyAdmin"

O volbě Operation jsem doposud nevěděl.

AgGreSsivE:

Hezký den mám problém. Potom co jsem změnil hosting a přehrál zálohu, tak se mi na stránce <a href="http://www.xool.cz/pocasi" title="Fonty nezobrazí diakritiku">XOOL</a> nechce správně zobrazit velikost písmen s diakritikou (pouze v nadpisech a u widgetů). Prosím moc o pomoc :) Třeba i SZ na email AnubisCZE@gmail.com

Michal:

Jak je napsáno níže, směřujte tyto dotazy na http://diskuse.jakpsatweb.cz/?action=vtopic&forum=9.

AgGreSsivE:

Díky za super odkaz na který jsem zapomněl. Google díky SEO už nevyhledává, tak  správně jak dříve. doufám že mi v diskuzi na jakpsatweb.cz poradí.

Marek:

Ahoj,
řeším obdobný problém ale s tím rozdílem, že v databázi mám uložený data právě s těma otazníkama a různýma znakama - např Horák je v DB uložen jako Horák a proto se mi to řadí všechno špatně. V mysql mám vše nastaveno na UTF8 czech i na sloupcích i na tabulce i v samotné db, na webu používám php a je psaný v UTF8 a html v hlavičce udávám taky utf8 a na stránce se mi zobrazí správně Horák. Problém je když chci data seřadit, tak mi to řadí Štěpán před Alena např... nevíte jak překonvertovat všechny data v databázi, aby se mi přepsali do češtiny a i v tabulce v databázi bylo potom uloženo Horák místo Horák ? dál už si s tím poradím. Děkuji

Diskuse je zrušena z důvodu spamu.

avatar © 2005-2024 Jakub Vrána. Publikované texty můžete přetiskovat pouze se svolením autora. Ukázky kódu smíte používat s uvedením autora a URL tohoto webu bez dalších omezení Creative Commons. Můžeme si tykat. Skripty předpokládají nastavení: magic_quotes_gpc=Off, magic_quotes_runtime=Off, error_reporting=E_ALL & ~E_NOTICE a očekávají předchozí zavolání mysql_set_charset. Skripty by měly být funkční v PHP >= 4.3 a PHP >= 5.0.