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
8.6.2005 09:54:25

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.
8.6.2005 10:25:20

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
29.11.2006 08:55:33

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 Á.
29.11.2006 11:11:23

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 < ť)
4.2.2011 15:20:03

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).
5.2.2011 21:56:10

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
(reakce na) 25.11.2007 15:30:23

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.
8.6.2005 12:32:01

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ů.
8.6.2005 12:45:48

ikona spaze:

i SET NAMES lze psat bez uvozovek/apostrofu.
8.6.2005 14:20:05

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
8.6.2005 15:31:34

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.
8.6.2005 15:41:12

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?
12.6.2005 13:22:55

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
13.6.2005 17:06:43

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.
9.1.2006 12:16:07

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 ?
21.6.2005 23:03:17

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)
27.6.2005 14:29:52

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
19.7.2005 07:40:50

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.
19.7.2005 10:41:14

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ěď.
19.7.2005 12:02:28

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.
19.7.2005 12:09:02

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.
(reakce na) 31.7.2005 18:31:14

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.
1.8.2005 11:05:11

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.
2.8.2005 19:30:14

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.
24.7.2005 18:06:46

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.
24.7.2005 22:01:04

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
30.7.2005 20:39:28

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"); ?>.
1.8.2005 11:00:23

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
12.8.2005 20:57:35

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.
12.8.2005 23:27:20

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.
24.8.2005 00:28:04

a:

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

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(...);
11.5.2006 19:56:33

Peane:

Ja mam proble pri vyberu z db mi to zobrazuje otazniky ale v db to mam ulozene normalne a vse mam nastavene spravne
29.10.2006 18:16:33

crewer:

DÍKY!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
(reakce na) 3.11.2010 16:14:50

Pavel:

Díky za radu.
(reakce na) 17.10.2011 12:07:50

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 ...
(reakce na) 22.5.2006 16:08:35

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
18.2.2007 12:09:59

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...
4.9.2011 20:04:18

Laik89789:

I já děkuju ;-)
(reakce na) 10.11.2011 18:34:20

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?
(reakce na) 28.9.2011 20:24:29

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.
3.8.2005 09:01:54

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...
20.9.2005 20:47:32

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ě.
21.9.2005 10:28:36

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
21.9.2005 18:17:19

<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
26.9.2005 19:25:30

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.
(reakce na) 30.9.2005 11:07:05

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.
(reakce na) 27.11.2005 20:05:46

Michal:

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

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
26.9.2005 21:54:10

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.
27.9.2005 00:05:24

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.
3.11.2005 20:55:32

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.
10.10.2005 17:28:19

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.
10.10.2005 17:57:21

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
16.10.2005 19:39:39

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í.
20.10.2005 16:43:58

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.
10.11.2005 19:56:20

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.
11.11.2005 09:40:10

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
12.10.2005 19:16:20

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 ".
12.10.2005 19:29:34

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
13.10.2005 10:22:47

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čí.
24.10.2005 16:28:32

Langi:

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

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ů.
20.10.2005 16:32:36

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.
26.10.2005 11:59:57

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.
26.10.2005 12:21:47

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.
28.10.2005 23:17:59

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í).
31.10.2005 23:52:57

ikona Jakub Vrána OpenID:

Zkusil bych v my.cnf nastavit collation_connection a případně i character_set_client a character_set_results.
1.11.2005 10:18:45

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 ...
1.11.2005 01:40:36

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 ...
1.11.2005 01:43:11

ikona spaze:

Neni lepsi pouzit SET CHARACTER SET?
15.11.2005 20:29:29

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);
17.1.2006 00:38:27

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.
9.11.2005 12:05:14

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
12.11.2005 00:26:55

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:)
24.11.2005 16:33:49

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. :)
26.1.2006 17:32:29

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

12.12.2005 22:51:18

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
1.2.2006 02:11:29

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í.
1.2.2006 11:35:13

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?
19.2.2006 18:38:25

ikona Jakub Vrána OpenID:

Nastavuje aplikace SET CHARACTER SET utf8?
19.2.2006 18:42:48

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
20.2.2006 22:14:24

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.
24.2.2006 19:24:33

Kepi:

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

Bear:

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

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...
5.3.2006 17:23:14

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
24.2.2006 22:08:30

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?
12.3.2006 12:10:42

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
21.4.2006 00:50:30

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
11.5.2006 16:18:29

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
15.6.2006 22:29:59

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:-)
20.7.2006 04:12:56

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");
6.11.2006 18:11:04

noSetNames:

A pomohlo by toto?

[mysqld]
init-connect = 'SET NAMES cp1250'
23.11.2006 16:59:36

olle3:

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

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
2.1.2007 21:14:27

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ě.
3.1.2007 10:26:57

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.
17.1.2007 13:08:45

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.
17.1.2007 13:19:34

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...
20.1.2007 01:14:53

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 :-(.
23.1.2007 15:11:43

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
27.1.2007 11:25:47

Opty:

Ad problemy s cestinou:

http://molhanec.net/mysql_cestina_minifaq.html

Doporucuju SET NAMES. ;-)
27.1.2007 15:13:56

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.....:))
9.2.2007 11:35:11

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í.
9.2.2007 12:53:41

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
(reakce na) 3.4.2007 03:05:56

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ěď.
16.3.2007 10:42:41

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.

16.5.2007 16:45:57

ikona Jakub Vrána OpenID:

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

helt:

jeste pro uplnost:

CREATE DATABASE `mujweb` CHARACTER SET latin2 COLLATE latin2_czech_cs;
16.5.2007 17:10:34

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'");
16.5.2007 17:13:12

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.
30.6.2007 05:27:04

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.
6.12.2007 23:24:35

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 .
10.8.2007 02:29:49

ikona Jakub Vrána OpenID:

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

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?
11.10.2007 20:25:37

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á.
11.10.2007 20:35:45

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) :-)
11.10.2007 23:19:15

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ť?
19.10.2007 01:57:19

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.
19.10.2007 13:59:56

Lucky62:

Prechod na vyššiu verziu nie je možný - je to server providera .
21.10.2007 17:23:35

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.
1.1.2008 23:09:53

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.
1.3.2008 10:29:41

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
26.2.2009 05:58:18

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
24.4.2009 05:25:13

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 :(
16.5.2009 04:40:07

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!
10.8.2009 16:15:26

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/
31.12.2009 16:41:41

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.
31.3.2011 01:32:27

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
31.3.2011 18:15:29

dejv89:

Do háje, člověče, díky moc!
2.10.2011 19:53:28

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
(reakce na) 5.1.2012 10:49:22

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.
4.10.2011 09:28:51

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
1.12.2012 22:05:43

Michal:

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

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í.
2.12.2012 05:41:56

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
19.4.2015 14:49:19

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.