Starší komentáře ke článku: MySQL - čeština a slovenština
Zpět na článek | Úvodní stránka Interval.cz
Datum vložení: 19.9.2007 15:26:52
překlep v článku: SET NAMES = cp1205; má být cp1250
Datum vložení: 19.9.2007 15:54:06
Děkuji za upozornění ;-)
Datum vložení: 19.9.2007 15:32:46
V poslední ukázce je potřeba upozornit na to, že když kódování uvedené v meta tagu nesouhlasí s kódováním uvedeným v HTTP hlavičce serveru, má přednost HTTP hlavička (to se může stát, je-li, v případě serveru Apache, nastavena direktiva AddDefaultCharset na kódování jiné, než používá daná stránka). Řešením je uvést do skriptu následující řádek: Header("Content-type: text/html; charset=windows-1250"); A protože hlavičky musí být odeslány ještě před prvním výstupem skriptu, je potřeba tento řádek umístit ještě před počáteční značku (html) dokumentu, jinak dostanete chybovou hlášku "Cannot modify header information - headers already sent by..."
Datum vložení: 19.9.2007 15:53:40
Ano, to je pravda. Ono dokonce jedno RFC vyžaduje, aby hlavičku s kódováním server odesílal vždy, čímž vzniká konflikt... Co se týče problémů "headers already sent", lze se jim snadno vyhnout, použije-li se output buffering, viz http://interval.cz/clanky/usetrete-az-80-datoveho-prenosu/ ;-)
Datum vložení: 19.9.2007 15:35:33
Podle mě nemáte správně definice kódování a znakové sady. Kódování je převedení posloupnosti bytů na číslo znaku a naopak. Znaková sada je pak množina dvojic čísla a znaku. Pro zmatení pojmů většina norem popisuje současně jak kódování, tak znakovou sadu. Názorným příkladem je znaková sada unicode, která používá různá kódování jako UTF-8, UTF-16 anebo UCS2 (nepokrývá celý rozsah unicode). Opačným příkladem je stejné jednobytové kódování pro různé znakové sady (ISO-8859-1, ISO-8859-2…).
Datum vložení: 19.9.2007 15:49:49
Ano, tak to skutečně je, ty pojmy se často zaměňují a používají jako synonyma. Však jsem v úvodu napsal, že budu zjednodušovat - použil jsem terminologii, kterou používá i manuál MySQL, aby to měli méně zkušení čtenáři jednodušší. Podrobněji se o věci lze dočíst v seriálu http://interval.cz/clanky/znakove-sady-v-praxi-zakladni-teorie/, který v článku odkazuji.
Datum vložení: 19.9.2007 16:15:32
Pokud mluvíte o kódování, je třeba hovořit o posloupnostech bitů. Třeba v UTF-8 je "číslo znaku" úplně něco jiného než (obvykle) 8 nebo 16-ti bitová poslounost. Z tohoto hlediska je také naprosto nevhodný příklad v článku. V ISO Latin 1 především vůbec není š, nejprve je třeba zjistit, jak tam vůbec mohlo být. Nejspíše v ISO Latin2, který využívá stejné bitové řetězce jako ISO Latin1 (jen se jinak interpretují). Windows-1250 naproti tomu zrovna pro š,ž,ť využívá takové bitové kombinace, které v předchozích tabulkách nejsou textovými znaky. Vzniká tedy otázka, zda uvedený příklad v článku o převodu má reálný základ.
Datum vložení: 19.9.2007 16:37:57
Přiznávám bez mučení, že vaší poznámce tak docela nerozumím. Pokud se pokusím uložit do databáze nějaký znak, který neexistuje ve znakové sadě, kterou používá, dojde k chybě "data too long" nebo podobné a operace se neprovede.
Datum vložení: 19.9.2007 17:31:24
To mi právě není jasné na Vašem příkladu, jak "ve starší verzi může být pod ISO Latin1 ve Windows-1250" (bez problémů) uloženo například písmeno š ?
Datum vložení: 19.9.2007 18:07:36
Je to trochu logický kotrmelec, ale jde to. Doporučil bych vám znovu článek pročíst, vše tam podrobně popisuji - jde o pozůstatek z dob, kdy MySQL pracovala s textovými daty stejně jako s binárními. a tudíž bylo možné do jakéhokoli sloupce vložit prakticky cokoli.
Datum vložení: 19.9.2007 17:37:43
Hezký a srozumitelný článek. Našel jsem dva překlepy - podpora kódování je v MySQL už od verze 4.1 a SET NAMES se píše bez rovnítka.
Datum vložení: 19.9.2007 18:15:08
Dík za upozornění, skutečně jsem na dvou místech napsal za SET NAMES rovnítko a nevšiml jsem si toho ;-) Co se týče podpory v MySQL, mohl bys mi prosím, uvést, kde přesně mám ten překlep? Nikde to nevidím. V článku uvádím, že podpora je v MySQL už "ve vývojářské větvi čtvrté generace", což je, myslím, správný údaj, alespoň pokud je mi známo.
Datum vložení: 19.9.2007 21:31:48
Větev 4.1 byla produkční a podpora znakových sad v ní fungovala přinejmenším od produkční verze 4.1.7 bez problémů.
Datum vložení: 19.9.2007 22:21:39
Co se týče bezproblémovosti, mám bohužel jiné zkušenosti. Myslím ale, že je to celkem nepodstatné, protože životní cyklus MySQL 4 a starších už byl vývojáři ukončen ;-)
Datum vložení: 20.9.2007 12:15:04
Snad si ten clanek precte minimum lidi, jinak by to nejspise znamenalo cestu na pracak - firmy jsou ochotny platit pres 10,-/MB prevedenych dat... :)
Datum vložení: 20.9.2007 14:59:51
Takovym firmam ovsem neplatite za tu praci, ale za to, ze na sebe berou vase rizika a ruci vam za vysledek. Takze o vydelek neprijdou.
Datum vložení: 24.9.2007 15:54:15
Jsem lama a teď jsem aspoň trochu kódování pochopil a už nemusím zkoušet pokus-omyl. Díky
Datum vložení: 11.10.2007 14:20:55
Hezký článek ale ať dělám co dělám stejně mi to blbě řadí. Tabulka vypadá takto: CREATE TABLE tma020 ( cemp010 char(10) character set utf8 collate utf8_czech_ci default NULL, cemp020 char(25) character set utf8 collate utf8_czech_ci default NULL, cemp030 char(20) character set utf8 collate utf8_czech_ci default NULL, cemp050 char(4) character set utf8 collate utf8_czech_ci default NULL, login char(6) character set utf8 collate utf8_czech_ci default NULL ) ENGINE=MyISAM DEFAULT CHARSET=latin1 ROW_FORMAT=DYNAMIC; Do ní importuji data z textového souboru který je v cp1250. Před importem zadám set names cp1250 a import proběhne bez chyb. České znaky se zobrazují správně jen to blbě řadí, např. č to háže až za d, ř před p atd.
Datum vložení: 13.10.2007 8:46:17
Je mi líto - z tak malého množství informací nemohu nic vyčíst. Hodilo by se znát alespoň verzi serveru a dotaz, kterým data vybíráte, když už nic jiného...
Datum vložení: 15.10.2007 11:07:13
Nedalo by se blíže objasnit v čem je nespolehlivé používání SET CHARACTER SET oproti SET NAMES?
Datum vložení: 15.10.2007 11:36:07
SET CHARACTER SET je nespolehlivé v případě, kdy je špatně nastavené kódování u databáze. V opačném případě je naopak lepší, protože v případě použití SET CHARACTER SET nemusíte vědět nic o tom, jak jsou data v databázi skutečně uložena.
Datum vložení: 23.10.2007 16:03:42
Dobry den, na jednom svem projektu mam problem s kodovanim. Skripty PHP jsou ulozeny v UTF-8, HTML hlavicka je v UTF-8, databaze je v UTF-8 (utf-8_general_ci). Pokud do DB vkladam data pres PHP, v PHP se vse zobrazuje spravne (jak se z lesa vola, tak se z nej ozyva). Pokud se vsak kouknu primo do DB, vidim spatnou diaritiku. SET NAMES 'utf8' nepomohlo. Nevite, v cem by mohl byt problem?
Datum vložení: 6.11.2007 18:47:02
Chyba môže byť len u teba, preto sem musíš napísať ako si si to zapísal ... inak môžem len hádať (presne tvoj prípad mne ide v poho)
Datum vložení: 31.1.2008 21:10:40
Vím, že asi příspěvek zapadne, ale chci upozornit nováčky na tuto jednu skutečnost na kterou autor článku nepřímo upozornil. V [b]my.cnf[/b] ve dvou sekcích je uvedena jak defaultní znaková sada tak i typ třídění. Není-li však uvedena, platí to co autor uvedl, Latin/swedish... Kde je pointa? No a toto defaultní kódování z my.cnf se přenáší do všech proměnných definovaných uvnitř trigerů, funkcí a procedur pomoci [b]DECLARE[/b]. Takže pak během různých operací (přižazení SET, sql příkazy SELECT INTO, FETCH INTO) může SQL server protestovat, že používáte různé [b]collation[/b]. Jak z toho ven? Jsou dvě řešení: To první je nejjednodušší, vše mít v jedné sadě a jednom třídění (tabulky, sloupce, nastavení serveru). To druhé obtížnější, mít na paměti, že v DECLARE za typem je nutno uvést i collation even. i znakovou sadu (totéž platí u funkcí a její návratové hodnoty nebo dokoce u parametrů funkcí a procedur), totožné s tím, s kterým budeme pracovat v rámci následujících sql příkazů. Chci upozornit, že v ukázkách hned tak nenajdete tuto možnost. Jarda
Datum vložení: 5.2.2008 7:41:50
Tak jsem se také dal na MySql. Pročetl jsem snad vše o češtině a včera jsem tvrdě narazil. Obvykle používám kódování utf8/czech. Zapomenul jsem však u jednoho údaje švédštinu (Toad ji celkem tvrdě nasazuje všude kam to jde) a importoval data v programu v Delphi (používám zakoupené komponenty pro komunikaci s MySql). Služba MySql mi natvrdo zamrzala a velmi dlouho jsem nevěděl proč. Když jsem ji spustil a stačilo jen se podívat na uložená data (i sousední tabulku) tak zo zmrzlo. Pomohl až z konzole příkaz Truncate nejen na tabulku se zapomenutou švédštinou, ale i na sousední tabulku (a to nevím proč). Zatvrdne to nejprve při uložení neočekávané diakritiky, a bez výmazu dat pak i na obyčejném Selectu. Používám verzi 5.0.
Datum vložení: 23.9.2008 16:25:58
Zdravim mam problem s jednou knežnicou v Php a MySql na stranke my nechce zobrať kod.Švagor my povedal že tam treba presunut do Php nejaku knižnicu ale nevie jej nazov ak niekto viete mohli by ste my napisať?Ďakujem
Datum vložení: 26.2.2009 13:57:33
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="'B problem je jen u českych znaku, jinak vše funguje, fonty jsem zkotroloval. děkuji