ARCHIV

MySQL (57) - Ach, ta čeština

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 | Články autora | 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.

MySQL, znakové sady a potíže s nimi

Ř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:

1. Při importu dat do databáze nebo při ukládání znakových dat sesbíraných pomocí nějaké klientské aplikace
2. Při interní manipulaci s řetězci uvnitř MySQL
3. Při zobrazení dat "vně" databáze, prostě když je chceme vydolovat a použít

Lehce si to celé rozeberme, abychom pochopili, jak to všechno souvisí. Platí totiž zásada, že buď:

• je dobré při manipulaci se znakovými sadami vybrat si jednu a té se držet, nebo
• používat několik znakových sad a na správném místě provést konverzi mezi nimi pomocí nástrojů, které poskytuje MySQL nebo podkladový operační systém

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.

Import nebo vstup dat

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.

Manipulace s daty

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:

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.

Výstup dat

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.

Řazení dat

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.

Lehký úvod do problematiky

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

a seznam dostupných řazení pak pomocí příkazu

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.

Verze pro tisk