Podle mě musí existovat spojení mezi slovy "konverze" a "kontroverze". Máloco je totiž ve spojení s MySQL tak časté, jako dotazy ohledně češtiny a znakových sad vůbec. Rozeberme to.
3.2.2006 06:00 | Petr Zajíc | přečteno 28404×
Dozrál čas věnovat se dotazům, které se v té či oné formě pravidleně
objevují v mojí e-mailové schránce a které se v souvislosti s MySQL tak
či onak dotýkají znakových sad. Naše požehnaná mateřština disponuje
celou řadou hlásek s háčky a čárkami, což programátorovi a správci
databáze může pěkně zatopit. Postupně si ukážeme, že porozumět tomu,
jak se chová MySQL v takových situacích není zase až tak složité, pokud
člověk vezme v úvahu všechny faktory. Leč postupně, nejprve trocha té
nezbytné teorie.
Řetězce v databázi mohou být uloženy v mnoha znakových sadách. MySQL
tento pohled na věc velmi dobře podporuje. Znaková sada zde může být
specifikována pro celý server, pro jednu databázi, pro jednu tabulku
nebo dokonce pro jediný sloupec. Nicméně je třeba pochopit
celý mechanismus a správně ho uplatnit, aby to všechno fungovalo k naší
spokojenosti. Kdy se
vlastně v souvislosti s MySQL a řetězci musíme zajímat o znakové sady?
V několika hlavních situacích:
Lehce si to celé rozeberme, abychom pochopili, jak to všechno
souvisí. Platí totiž zásada, že buď:
Pozn.: Pro mě je "správný" ten první postup. Ke konverzím se uchyluji jen když je to nezbytné, třeba když musím spolupracovat s více oddělenými systémy s jiným kódováním.
Nezřídka je nutné importovat data do MySQL z externích zdrojů, jak
jsme o tom psali minule. Například pokud se jedná o import textových
souborů - jsou uloženy ve správné znakové sadě? Pokud vaše distribuce
používá UTF-8, pak budou textová data nejspíš v tomto kódování. Pokud
máte něco jiného (jako je soubor pocházející z Windows), bude třeba
na to myslet již před importem.
Pozn.: Situace, kdy se naimportují data
v neodpovídající znakové sadě je zejména u začátečníků poměrně častá.
Obyčejně je mnohem účinnější provést import znovu, než se snažit o
opravu existujících dat uvitř databáze.
Třebaže se to nezdá, je i tady zapotřebí mít se na pozoru. Především je MySQL hodně flexibilní, takže v jedné databázi, i dokonce v jediné tabulkce můžete mít data v několika znakových sadách. Takže, příkaz INSERT nebo UPDATE může s nabodeníčky krásně zamíchat, pokud si na to nedáte pozor. Další často opomíjenou skutečností je fakt, že v určitém kódování funguje rovněž klient, kterého používáte (jako je řádkový klient nebo PHPMyAdmin). Pokyny, které databáze dostane tedy musejí přijít se správnou diakritikou, aby to celé mohlo smysluplně pracovat. Hezky je to vidět na příkazech SELECT:
select * from pracovnik
where prijmeni = 'Žežulka' and obec = 'Středoplky'
To může být sice napsáno správně, a v databázi mohou odpovídající
záznamy existovat, přesto však někdy nedostaneme to, co potřebujeme.
Důvodem může být nešťastná konverze, kterou klient provede předtím, než
databáze pokyn obdrží. Může vzniknout jen těžko dohledatelná chyba nebo
mohou být nalezeny záznamy, které jsme nechtěli.
Vlastně to hezky souvisí s oběma předchozími problémy: Nějaký
konzument dat (desktopová aplikace, webová stránka nebo cokoli jiného)
požaduje znaková data a databáze mu je pošle. Zobrazí se na výstupu to,
co jsme potřebovali? To bude opět záviset na více faktorech. Především
je nutné, aby klient dokázal o data správně požádat, a potom také to,
aby je správně předložil uživateli.
V případě webových aplikací bude nejspíš výstupem nějaká HTML
stránka, která ovšem rovněž používá kódování. Takže, může vzniknout
několik problémů, které spolu souvisejí. Postupně si v tomto seriálu
ukážeme, jak se celý ten zašmodrchanec dá rozplést.
Abych předešel případným dotazům, řeknu to rovnou: řazení znakových
dat sice souvisí se znakovými sadami, ale není
to totéž. V databázi můžeme například mít znaková data v UTF-8 a
požadujeme jejich české řazení, stejně tak ale pro UTF-8 data můžeme
chtít řazení anglické nebo německé. Tomuto tématu se budeme věnovat
později, teď jen zásada: Nastavení znakové sady pro databázi není totéž
co nastavení způsobu řazení dat.
Jak vidíte, je toho dost a jistě nám tato látka vystačí na více dílů seriálu. Obecně lze říci, že MySQL podporuje více znakových sad, přičemž záleží na nastavení při kompilaci, které budou k dispozici. Seznam dostupných znakových sad můžete zobrazit příkazem
SHOW CHARACTER SET;
a seznam dostupných řazení pak pomocí příkazu
SHOW COLLATION;
Pozn.: Nelekněte se. Moje výchozí
instalace MySQL "pětky" obsahuje 36 znakových sad a 124 vestavěných
způsobů řazení dat, takže je toho opravdu dost. V praxi však budete
používat většinou jen zlomek toho, co je ve skutečnosti k dispozici.
My se příště podíváme na praktický příklad, jak se se znakovými
sadami vypořádat v situacích, které jsem nastínil. Dopředu prozradím,
že budu doporučovat používání UTF-8 podobně, jako to děláme tady na
serveru při psaní stránek. Rovněž naznačím, co Vás může potkat za
problémy a jak se s nimi vypořádat; a pokusím se zodpovědět nejčastější
dotazy, které mi v té souvislosti chodí.
A ještě něco: Příště udělám trochu ústupek a použiju příklady psané v PHP, přestože jsem si předsevzal, že se v tomto seriálu budu snažit věnovat pouze databázi bez vazby na konkrétní programovací jazyky. Důvod je prostý - většina lidí takto MySQL používá a problémy se mohou prolínat, takže zahrnu do vysvětlování i PHP.