LINUXSOFT.cz Přeskoč levou lištu
Uživatel: Heslo:  
   CZUKPL

> MySQL (58) - čeština v praxi

Příliš žluťoučcí koně - prostě hrátky s nabodeníčky stokrát jinak a pokaždé s MySQL.

10.2.2006 06:00 | Petr Zajíc | Články autora | přečteno 33422×

Komerční sdělení: Pořádáme Kurzy MySQL

Teorie bylo minule až dost, takže vzhůru na praktické uplatnění vědomostí o MySQL a znakových sadách.

Definice sloupce tabulky

Především je třeba vědět, že při definici tabulky lze v MySQL určit znakovou sadu a řazení pro každý sloupec zvlášť. V jediné tabulce tedy můžete mít sloupce s různým kódováním znaků. Příkaz, který to zajistí lze napsat nějak takto:

CREATE TABLE cestina (
win VARCHAR(50) CHARACTER SET cp1250 COLLATE cp1250_czech_cs,
latin VARCHAR(50) CHARACTER SET latin2 COLLATE latin2_czech_cs,
utf VARCHAR(50) CHARACTER SET utf8 COLLATE utf8_czech_ci
) TYPE = MYISAM ;

Samozřejmě, že v reálné aplikaci to většinou nebudete potřebovat. Tam často postačí definovat znakovou sadu pro celou tabulku, a tato znaková sada je pak použita pro všechny sloupce obsahující řetězce.

CREATE TABLE cestina_cela (
text1 VARCHAR( 50 ) NOT NULL ,
text2 VARCHAR( 50 ) NOT NULL ,
text3 VARCHAR( 50 ) NOT NULL
) TYPE = MYISAM CHARACTER SET utf8 COLLATE utf8_czech_ci;

Leč zpátky k prvnímu příkladu. Pokud se nyní do tabulky cestina pokusíte zapsat data následujícím příkazem:

insert into cestina (win, latin, utf) values ('Příliš žluťoučký kůň pěl ďábelské ódy','Příliš žluťoučký kůň pěl ďábelské ódy','Příliš žluťoučký kůň pěl ďábelské ódy');

Skončíte na 99% chybovým hlášením "Data too long for column 'win' at row 1", nebo něčím hodně podobným. Než se to pokusím vysvětlit, je třeba uvést, že:

  • V příkladech předpokládám použití řádkového klienta mysql. Pokud byste použili například PhpMyAdmin tak nejspíš k žádné chybě nedojde, protože aplikace se pokusí kódování nějak vyřešit (a nejspíš uspěje). To nám momentálně VADÍ, protože to ztěžuje pochopení našeho problému. Při použití řádkového klienta máme naopak jistotu, že do databáze dorazí přesně to, co jsme napsali.
  • Chybová hláška je v tomto případě naprosto zavádějící. Ve skutečnosti je problém v tom, že klient a server vzájemně "nepochopili" svoje znakové sady.

Client character set

Jakou znakovou sadu tedy vlastně používá řádkový klient mysql, když "mluví" s databází? A vůbec - nějakou znakovou sadu přece musí používat jakýkoli klient, řádkovým počínaje a třeba PHP skriptem konče, takže jak to je? Odpověď je jednoduchá - server PŘEDPOKLÁDÁ, že klient bude posílat data v určité znakové sadě! Ta je dána systémovou proměnnou character_set_client a je předkonfigurována při instalaci.

Pozn.: Což je pro neznalé hotové neštěstí, neb až do verze 4.1 byla výchozí latin1 - něco, co našincům moc vyhovovat nebude. Naštěstí se zdá, že většina instalací "pětek" má přednastavenou utf8.

To, jakou znakovou sadu Váš server od klienta očekává si můžete  ověřit následujícím dotazem:

SHOW VARIABLES LIKE 'character_set_client';

To byly špatné zprávy, teď něco dobrých. Bez ohledu na to, jaká je výchozí znaková sada si můžete poručit, že pro Vaše připojení budete používat specifickou sadu. To provedete pomocí veledůležitého příkazu SET NAMES. Jestliže tedy budu chtít ve zdraví provést příkaz INSERT INTO, jak je uveden výše, mohu na to jít nějak takhle:

set names cp1250;
insert into cestina (win) values ('Příliš žluťoučký kůň pěl ďábelské ódy');
set names latin2;
insert into cestina (latin) values ('Příliš žluťoučký kůň pěl ďábelské ódy');
set names utf8;
insert into cestina (utf) values ('Příliš žluťoučký kůň pěl ďábelské ódy');

Důležité: Mají-li se data do databáze dostat ve správné znakové sadě, musí tedy platit ZÁROVEŇ tato dvě pravidla:

  1. Sloupec, který má data pojmout musí být definován ve správné znakové sadě
  2. Klient musí posílat příkazy na server ve znakové sadě, na níž se dohodli (což je výchozí znaková sada nebo znaková sada určená pomocí SET NAMES).

Pokud si příklady zkoušíte a zapsali jste cvičná data do tabulky, můžete je teď zkusit pomocí řádkového klienta zobrazit:

a ejhle! Pokaždé se správně zobrazí jen ten sloupec, pro nějž je odpovídajícím způsobem nastavena znaková sada. Čímž se vlastně dostáváme k dalšímu tématu - a tím je spolupráce s PHP.

MySQL, znakové sady a PHP

Tady není moc co dodat. Je třeba si uvědomit, že z hlediska databáze je PHP klient jako každý jiný, a že je tudíž namístě specifikovat v našich ctěných skriptech rovněž odpovídající příkaz SET NAMES, nějak takhle:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<
html>
<
head>
  <
meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <
title>Test znakových sad</title>
</
head>
<
body>  
<?
mysql_connect("localhost","root");
mysql_select_db("test");
mysql_query("SET NAMES 'cp1250';"); //nebo 'latin2' nebo 'utf8'
$vysledek=mysql_query("select * from cestina;");
while (
$zaznam=MySQL_Fetch_Array($vysledek)):
  echo
$zaznam["win"]."<BR>\n";
  echo
$zaznam["latin"]."<BR>\n";
  echo
$zaznam["utf"]."<BR>\n";
endwhile;
?>
</BODY>
</HTML>

Samozřejmě, že něco takového se musí udělat ještě předtím, než databáze vrátí data, jinak je to zbytečné. Pokud si to chcete vyzkoušet, zjistíte, že pokaždé jsou správně zobrazena jen data v odpovídající znakové sadě, a že ostatní je "rozsypaný čaj".

A co importy?

Jestliže importujeme data do MySQL z textových souborů, je třeba navíc dbát na to, aby i vstupní soubor s daty byl ve správné znakové sadě. Jinak platí to, co jsme uvedli výše. Tedy:

  1. Importovaný soubor musí být ve správné znakové sadě (UTF-8, například)
  2. Klient mysql musí obdržet příkaz SET NAMES XXX
  3. Data se musí ukládat do sloupce se správně nadefinovanou znakovou sadou.

Není to složité, když si uvědomíte, jak spolu jednotlivé věci souvisejí. Nepříjemné je, že musí být splněno více podmínek - a když nejsou, nevyjde to.

Verze pro tisk

pridej.cz

 

DISKUZE

prevod phprs a phpbb 10.2.2006 17:25 Petr Bartel
L Re: prevod phprs a phpbb 10.2.2006 17:58 Petr Zajíc
  L Re: prevod phprs a phpbb 10.2.2006 18:08 Petr Bartel
    |- Re: prevod phprs a phpbb 10.2.2006 19:13 Michal Molhanec
    | L Re: prevod phprs a phpbb 10.2.2006 20:16 Petr Bartel
    L Re: prevod phprs a phpbb 11.2.2006 08:52 Petr Zajíc
      L Re: prevod phprs a phpbb 12.2.2006 18:35 Petr Bartel
        |- Re: prevod phprs a phpbb 12.2.2006 20:20 Petr Zajíc
        L Re: prevod phprs a phpbb 13.2.2006 09:55 o.k.
Ako sa sprava PHP? 20.6.2006 13:51 Srigi
L Re: Ako sa sprava PHP? 25.6.2006 07:24 Petr Zajíc
import z csv pomoci php 19.1.2007 16:45 Martin Havel
  L Re: import z csv pomoci php 20.1.2007 11:50 Petr Zajíc
    L Re: import z csv pomoci php 22.1.2007 12:48 Martin Havel
      L Re: import z csv pomoci php 22.1.2007 13:00 Petr Zajíc
        L Re: import z csv pomoci php 22.1.2007 14:32 Martin Havel
          L Re: import z csv pomoci php 22.1.2007 17:14 Petr Zajíc
            L Re: import z csv pomoci php 23.1.2007 09:00 Martin Havel
              L Re: import z csv pomoci php 23.1.2007 11:21 Petr Zajíc
                L Re: import z csv pomoci php 24.1.2007 10:15 Martin Havel
                  L Re: import z csv pomoci php 24.1.2007 10:39 Martin Havel
                    L Re: import z csv pomoci php 24.1.2007 13:08 Petr Zajíc
                      L Re: import z csv pomoci php 24.1.2007 16:04 Martin Havel
                        L Re: import z csv pomoci php 24.1.2007 17:48 Petr Zajíc
                          L Re: import z csv pomoci php 24.1.2007 18:22 Martin Havel
                            L Re: import z csv pomoci php 25.1.2007 07:24 Petr Zajíc




Příspívat do diskuze mohou pouze registrovaní uživatelé.
> Vyhledávání software
> Vyhledávání článků

8.5.2016 17:19 /Redakce Linuxsoft.cz
PR: Dne 26.5.2016 proběhne v Praze konference Cloud computing v praxi. Tématy bude např. nejnovější trendy v oblasti cloudu a cloudových řešení, cloudové služby, infrastruktura cloudu, efektivní využití cloudu, možné nástrahy cloudů a jak se jim vyhnout
Přidat komentář

21.4.2016 8:01 /František Kučera
Spolek OpenAlt zve na 127. distribuovaný sraz příznivců svobodného softwaru a otevřených technologií (hardware, 3D tisk, SDR, DIY, makers…), který se bude konat ve čtvrtek 28. dubna od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5).
Přidat komentář

2.3.2016 22:41 /Ondřej Čečák
Letošní ročník konference InstallFest již tento víkend!
Přidat komentář

14.2.2016 16:39 /Redakce Linuxsoft.cz
O víkendu 5. a 6. března 2016 proběhne na pražském Strahově 8. ročník tradiční konference InstallFest. Celkem za dva dny uvidíte ​30 přednášek​ a ​6 workshopů.
Přidat komentář

5.2.2016 17:38 /Petr Ježek
Utilitka z XFce "xfce4-power-manager" nejen umožňuje nastavení lhůty pro uspání či hybernaci, ale i zapínání a vypínání prezentačního módu pro nerušené sledování videí. Stačí ji nastavit v každém vybavenějším panelu a v jakémkoli nontiled WM/DE.
Přidat komentář

10.1.2016 11:32 /Pavel `Goldenfish' Kysilka
LinuxMarket změnil provozovatele. Nově jej provozuje Marek Pszczolka. Více info a detaily #1 a #2.
Přidat komentář

29.12.2015 11:38 /Ondřej Čečák
Ještě posledních pár dní můžete přidávat příspěvky nebo nápady na Install Fest 2016, který se bude konat 5. a 6. března 2016.
Přidat komentář

8.12.2015 11:36 /Petr Ježek
Logické se stává realitou. LibreOffice a Thunderbird se mají dle článku na Redditu stát protiváhou MS řešení (MS Office a Outlook).
Přidat komentář

   Více ...   Přidat zprávičku

> Poslední diskuze

10.6.2016 21:10 / pavel riha
FreeBSD 10.3 a virtualizace

8.6.2016 21:56 / Milan Gallas
Nevalidní prefix m

7.5.2016 14:58 / Teodor Komárek
Soubory

20.4.2016 0:07 / Jakub Cleing
Sázkový panel PHP FUSION

9.4.2016 9:43 / jiwopene@gmail.com
Re: problém s dpkg a nemožností instalovat

Více ...

ISSN 1801-3805 | Provozovatel: Pavel Kysilka, IČ: 72868490 (2003-2016) | mail at linuxsoft dot cz | Design: www.megadesign.cz | Textová verze