MySQL – čeština a slovenština

MySQL byla vytvořena v roce 1995 jako jednoúčelová databáze pro snadné ukládání a především čtení textových dat v internetových aplikacích. S tím souvisela také absence nástrojů pro práci s jazyky, které ostatně v té době postrádala (a často dodnes postrádá) většina databází. Současná situace je ovšem diametrálně odlišná – MySQL obsahuje, s výjimkou speciálních lingvistických systémů, pravděpodobně nejkvalitnější podporu pro práci s jazyky, což ovšem může nezkušenému programátorovi často způsobit řadu problémů.

Používaná terminologie

Z teoretického hlediska je práce s jazykem a jeho strojovým vyjádřením velice komplikovaná záležitost. Natolik komplikovaná, že ji zde nebudeme vůbec rozebírat – seznámím vás pouze s termíny, o kterých se domnívám, že bez nich nelze plně pochopit práci se znakovými sadami a způsoby řazení textových dat v MySQL. Nevyhnu se přitom ale doslova brutálnímu zjednodušení…

Jazyk

Jazyk je nástroj, kterým vnímáme a vyjadřujeme okolní svět i sami sebe. Je to prostředek myšlení – „stejný“ člověk by myslel v různých jazycích různě. Jazyků (přirozených, umělých, strojových, živých i mrtvých) je velké množství. Pro nás je důležité, že téměř každý používaný jazyk má své označení slovní a kódové. To lze najít v normě ISO 639 spravované Kongresovou knihovnou USA. Čeština používá czech a slovenština („slovenčina“) slovak.

Písmo

Písmo je nástroj, kterým zaznamenáváme své myšlenky. Podobně jako jazyků, existuje i písem celá řada, i když jich zdaleka není tolik. Jedno písmo obvykle sdílí vícero různých jazyků, přitom s ním ale každý nakládá trochu jinak. Čeština i slovenština převzaly písmo nazývané latinka.

Znak

Znak je nejmenší jednotkou písma. Jednotlivé znaky vyjadřují různé jazykové jevy. Žádný jazyk obvykle nepoužívá všechny znaky, které jsou v daném písmu k dispozici. Svébytným znakem je písmeno „A“ nebo „a“ či „á“, ale i čárka „,“ nebo dokonce mezera “ „.

Diakritika

Diakritika je nástroj, který rozšiřuje vyjadřovací schopnosti určitého písma. Jelikož je písem méně než jazyků (a moderní jazyky toho také zaznamenávají více než starověké), časem bylo zapotřebí nějakým způsobem „rozmnožit“ skupinu znaků používaných písem tak, aby vyhovovaly odlišným požadavkům jednotlivých jazyků. Diakritikou rozumíme značky pod, nad, vedle nebo přes jednotlivé znaky písma – to jsou všechny ty čárky, háčky, kroužky a podobně. (Kromě češtiny používá diakritiku i celá řada jiných jazyků, není to tedy ďábelský vynález mistra Jana Husa.) Bez diakritiky by řada jazyků musela používat vlastní písma nebo by jejich vyjadřovací schopnosti byly omezeny až k nepoužitelnosti.

Kódování

encoding

Kódování je způsob, jak jednoduše zaznamenat znak způsobem srozumitelným počítači. Vlastně jde o „překlad“ znaků do čísel. Vždy je přitom dáno konvencí, které písmeno bude zastoupeno kterým číslem. Podle jedné konvence tedy může znak „A“ být zastoupen číslem „0“ a podle jiné číslem „163“. (To abychom to neměli tak jednoduché). Bez znalosti použitého kódování obvykle nelze „přeložit“ sled číslic zpět na odpovídající znaky. Tabulka se soupisem znaků písma a jejich dohodnutého číselného vyjádření bývá nazývána kódová stránka.

Znaková sada

character set

Různé jazyky používají různé podmnožiny znaků každého písma. Obvykle lze několik málo znaků použít pro celou skupinu jazyků. Toho využili programátoři v éře počítačového primitivismu k úsporám výpočetního výkonu (a k navýšení chaosu). Znaková sada je tedy skupina znaků a jejich číselných kódů. Čím víc znaků znaková sada obsahuje, tím je práce s ní komplikovanější, ale tím univerzálnější také tato sada je. Čeština a slovenština například používají sady ISO 8859-2 (též označovaná jako ISO Latin 2, určena pro jazyky střední a východní Evropy používající „latinské“ písmo), Windows 1250 (totéž, ovšem s jinými čísly pro stejné znaky) nebo univerzalistickou UTF-8. Znakové sady jsou obvykle dány průmyslovým či legislativním standardem – údaje o znakových sadách udržuje organizace IANA.

Řazení

collation

Pro jednoduchost se jednotlivé znaky písma obvykle zapisují v určitém ustáleném pořadí (kolace). Lidově řečeno se „řadí podle abecedy“. (I když existují i jiné způsoby, třeba slovníkový.) V každém jazyce je přitom pořadí používaných znaků odlišné – dokonce jeden a týž jazyk, používající stejné písmo a stejnou sadu znaků, může používat různé metody řazení těchto znaků v závislosti na mnoha parametrech. Z našeho hlediska se obvykle hledí především na to, o jaký jazyk jde a v jakém státě se používá („abecedy“ stejných jazyků bývají v různých státech různé). Bohužel, ne každé řazení lze vyjádřit jednoduchým, reálně použitelným algoritmem – mezi taková patří i řazení pro češtinu, přestože nová norma ČSN 97 6030 z roku 1994 ho podstatně zjednodušila.

Velikost písmen

Obvykle vnímáme znaky „A“ a „a“ jako jedno „písmeno“, ačkoli jsou to dvě odlišné entity (velké a malé). Problém nastává tehdy, když chceme něco „seřadit podle abecedy“, pak obvykle musíme určit, jestli se bude vše řadit bez ohledu na velikost (case insensitive, zkratka ci) nebo budeme velikost písmen brát v úvahu (case sensitive, zkratka cs).

MySQL a jazyky

Většina databází s textovými daty pracovala a dosud pracuje bez ohledu na použitý jazyk a znakovou sadu. Obvykle to znamená, že „jak se do lesa volá, tak se z lesa ozývá“, tedy co si do databáze uložíte, to z ní následně můžete vybírat. Pokud do takové databáze uložíte telefonní seznam českých jmen v kódování Windows 1250, dostanete zpátky zase jen tato česká jména v tomto kódování. Jakékoli řazení nebo změnu kódování je nutno provádět pomocí nějakého externího nástroje, většinou skriptovacího jazyka. Takový přístup je samozřejmě krajně neefektivní a nespolehlivý.

MySQL se začala vážně zabývat různými znakovými sadami a metodami řazení („abecedami“) ve vývojářské větvi čtvrté generace. Přitom se podpora různě měnila, takže různé setinkové verze se od sebe mohou velmi podstatně lišit – za spolehlivou lze považovat podporu ve verzích 4.1.7 a vyšších. Nejvhodnější je samozřejmě používat vždy současnou stabilní produkční verzi (aktuálně MySQL 5.0.x nebo vyšší). Vývoj starších verzí již byl ukončen a neměly by být dále používány, pokud k tomu neexistuje závažný důvod.

Jaké jazykové informace MySQL sleduje?

MySQL 5.0.x a vyšší uchovává spolu s textovými daty dvě informace – jaká byla použita znaková sada (character set) a způsob řazení (collation), které je dáno kombinací „jazyka“ a citlivosti na velikost písmen (case sensitivity).

V současnosti MySQL podporuje více než dvě stovky (alespoň moje instalace) různých znakových sad a způsobů řazení, viz Character Sets and Collations That MySQL Supports. Přehled pro konkrétní vámi používanou verzi získáte pomocí SQL příkazů SHOW CHARACTER SET a SHOW COLLATION.

Co se týče češtiny, můžete se nejčastěji setkat se třemi znakovými sadami označovanými latin2 (ISO Latin 2), cp1250 (Windows 1250) a utf8 (UTF-8). Slovenština je (v MySQL) z uvedených přímo podporována pouze ve znakové sadě UTF-8. Existují i jiné znakové sady, v praxi však nebývají příliš použitelné. (Do budoucna je slibnou znakovou sadou UCS-2.)

Důležitou informací také je, že znakové sady a způsoby řazení nelze libovolně míchat – jejich kombinace musí být v databázi předem naprogramována a musí si navzájem odpovídat (tedy se znakovou sadou UTF-8 lze použít pouze řazení pro tuto sadu a nikoli například pro ISO Latin 2). Pro češtinu tak máme k dispozici například v kódování Windows 1250 řazení cp1250_czech_cs, v kódování ISO 8859-2 řazení latin2_czech_cs a v kódování UTF-8 řazení utf8_czech_ci. Pro slovenštinu pak v kódování UTF-8 řazení utf8_slovak_ci.

Kromě toho lze použít obecná řazení pro konkrétní znakovou sadu bez specifikace jazyka – cp1250_bin, latin2_bin a utf8_bin (tato řazení berou v potaz velikost písmen) nebo cp1250_general_ci, latin2_general_ci a utf8_general_ci (tato řazení neberou v potaz velikost písmen). Speciálním případem pak je utf8_unicode_ci. Vše lze logicky použít jak pro češtinu, tak i pro slovenštinu.

Podle mého osobního názoru je v našich podmínkách z dostupných nejvýhodnější znaková sada UTF-8 a kolace utf8_general_ci (pokud počítáte s ukládáním textů v různých jazycích), nebo kolace utf8_czech_ci (výhradně pro českojazyčné texty) či utf8_slovak_ci (výhradně pro slovenské texty).

Kde jazykové informace MySQL sleduje?

Jednoduše řečeno všude. Charakteristickou znakovou sadu a způsob řazení má každý objekt a operace, a to nezávisle na sobě navzájem. Vlastní nastavení může mít server, každá databáze, každá tabulka i každý sloupec.

Chcete-li například zjistit, jakou znakovou sadu a řazení používá konkrétní tabulka, použijte následující příkaz:

SELECT column_name, collation_name FROM information_schema.columns WHERE table_schema=’jmeno_databaze‘ AND table_name=’jmeno_tabulky‘;

Při jednotlivých operacích s textovými daty (vkládání, čtení, řazení, vyhledávání a podobně) se obvykle používá výchozí znaková sada a řazení. Pokud byste se snažili pracovat s texty s různými kolacemi, měla by databáze automaticky použít výchozí obecné metody – při řazení českých (utf8_czech_ci) a slovenských (utf8_slovak_ci) jmen do jednoho seznamu by to tedy byla například utf8_general_ci.

Nastavení znakové sady a řazení

Pokud chcete mít úplnou kontrolu nad způsobem, kterým s vašimi daty bude MySQL zacházet, musíte určit znakovou sadu a způsob řazení vždy, když vytváříte nějakou datovou strukturu nebo provádíte nějakou operaci s daty.

Pokud není určeno jinak, server MySQL 5.0.x používá ve výchozí konfiguraci znakovou sadu ISO Latin 1 a řazení latin1_swedish_ci (protože domovskou zemí MySQL je Švédsko). Někdy se můžete setkat i s binárními distribucemi, ve kterých je použito UTF-8 a řazení utf8_general_ci. Osobně považuji za vhodnější provozovat server právě pod UTF-8.

Možná vás napadá otázka, proč byste měli určovat znakovou sadu a způsob řazení textových dat v databázi. Důvody jsou v podstatě dva. Za prvé, použitá znaková sada určuje datovou náročnost ukládaných textů – písmena s diakritikou zabírají například v UTF-8 mnohem více místa než v ISO Latin 2 (to je také zdroj častých problémů). A za druhé, jazykové operace typu řazení, třídění, porovnávání a konverze textových dat mezi různými znakovými sadami jsou v databázi prováděny efektivněji a rychleji než v externích nástrojích, zvláště pak ve skriptovacích jazycích typu PHP a dalších, které se používají pro webové aplikace.

Tvorba datových struktur

Při tvorbě databáze se obvykle používá příkaz CREATE DATABASE (při změnách pak příkaz ALTER DATABASE). Chceme-li určit znakovou sadu a kolaci databáze, použijeme například následující:

CREATE DATABASE jmeno_databaze
    CHARACTER SET utf8
    COLLATE utf8_general_ci;

Při tvorbě jednotlivých tabulek můžeme také určit znakovou sadu a způsob řazení každé z nich (toto nastavení „dědí“ jednotlivé sloupce, neurčíme-li jinak):

CREATE TABLE jmeno_tabulky
(
    jmeno_sloupce CHAR(10)
) DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

Každý sloupec může mít vlastní znakovou sadu a způsob řazení nezávisle na výchozí znakové sadě a řazení tabulky:

CREATE TABLE jmeno_tabulky
(
    sloupec_1 CHAR(10)
    sloupec_2 CHAR(10) CHARACTER SET utf8 COLLATE utf8_czech_ci
    sloupec_3 CHAR(10) CHARACTER SET utf8 COLLATE utf8_slovak_ci
) DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

Tabulka, která výše uvedeným příkazem vznikne, bude jako výchozí používat znakovou sadu UTF-8 a příslušné obecné řazení, sloupec „sloupec_1“ toto nastavení „zdědí“ (bude stejné), sloupec „sloupec_2“ bude používat stejnou znakovou sadu a české řazení, sloupec „sloupec_3“ bude používat stejnou znakovou sadu a slovenské řazení.

Práce s textovými daty

Při každé operaci můžete pro každý textový údaj (string literal) určit znakovou sadu a způsob řazení, které se mají použít. Přitom (až na výjimky) nezáleží na tom, jak jsou tato data uložena v databázi.

Pokud bychom třeba měli tabulku z předchozího příkladu a v této tabulce bychom měli různá jména, klidně bychom mohli použít následující příkaz:

SELECT * FROM jmeno_tabulky WHERE sloupec_3 = _latin1’Müller‘ ORDER BY sloupec_1 COLLATE latin1_german1_ci;

Komunikace se serverem

Řada programátorů opomíjí komunikaci se serverem, respektive mezi uživatelským rozhraním, aplikací a databázovým serverem, a spoléhá se, že to bude „nějak“ fungovat. A ono to skutečně většinou nějak funguje, protože server jednoduše použije různá výchozí nastavení a potřebné informace si „domyslí“. Pokud máte stránky v UTF-8, skript používá kompatibilní funkce a databáze je také v UTF-8, většinou si ničeho zlého nevšimnete. Pokud ale v trojčlence změníte jeden prvek, třeba budete mít web ve Windows 1250, nastanou problémy.

Představte si situaci, kde nad společnou databází pracuje několik klientských aplikací nad různými operačními systémy (třeba Windows a Linux) a ta se pak zobrazují klientovi na nějakém Mekovi. Buď musíte zajistit, aby všichni používali stejná nastavení pracovního prostředí (což vždy nelze), nebo musíte databázi upozornit, jak se věci mají.

MySQL 5.0.x umožňuje definovat znakovou sadu pro tři klíčové operace. Proměnná character_set_client informuje server o tom, jakou znakovou sadu používá klient, tedy v jakém kódování přicházejí textová data. Proměnná character_set_connection informuje server o tom, v jaké znakové sadě požadujete, aby server data zpracovával. A konečně proměnná character_set_results informuje server o tom, v jaké znakové sadě požadujete, aby server posílal zpracovaná data na výstup.

Pokud tedy například nastane situace, kdy váš klient bude umět pracovat pouze s daty ve Windows 1250, vaše databáze bude umět některé operace (třeba uživatelské procedury) korektně provádět pouze s UTF-8 a váš kontrolní výstup používá ISO Latin 2, můžete následující sadou příkazů instruovat MySQL o svých požadavcích:

SET character_set_client = cp1250;
SET character_set_connection = utf8;
SET character_set_results = latin2;

Výslovně upozorňuji, že výše uvedené nemá nic společného s tím, jakou znakovou sadu či kolaci používá vaše databáze, její tabulky nebo jednotlivé sloupce. Server vše překóduje za běhu podle svých potřeb a nastavení.

Spásné SET NAMES

Většinou není zapotřebí konfigurovat vše tak podrobně, jak jsem to zde popsal. Postačí prostě serveru dát vědět, jakou znakovou sadu chcete používat při komunikaci s ním. K tomu slouží kouzelný příkaz SET NAMES, který automaticky vše nastaví na jednu znakovou sadu.

Pokud například pracujete s mezinárodní databází používající UTF-8 a pro své klientské rozhraní potřebujete, aby se s daty pracovalo ve Windows 1250, můžete použít následující příkaz a vše se rázem samo vyřeší:

SET NAMES cp1250;

Můžete také serveru zadat nejen jakou má očekávat a použít znakovou sadu, ale také jaké řazení chcete, aby použil při zpracování textových dat a jejich předávání na výstup. Například takto:

SET NAMES utf8 COLLATE utf8_unicode_ci;

Kromě SET NAMES existuje také příkaz SET CHARACTER SET, který by měl fungovat podobně – nastavit vše na znakovou sadu a kolaci používanou databází. V praxi se ale ukázalo, že to není příliš spolehlivé (navíc ve starší verzi MySQL tento příkaz dělal něco jiného), proto ho nedoporučuji používat.

Konverze mezi znakovými sadami

Jak už jsem několikrát zmínil, databáze provádí veškeré potřebné konverze textových dat mezi znakovými sadami automaticky podle potřeby. To ovšem platí za předpokladu, že bylo vše od počátku správně konfigurováno. Server, databáze, tabulky, sloupce, připojení, to vše musí mít správně definovánu znakovou sadu a kolaci a textová data, s nimiž se pracuje, musí této definici odpovídat.

Co si ale počít například se starší verzí databáze? Co když mám v tabulce, pohrobkovi po starší verzi MySQL, pro kterou je definována znaková sada ISO Latin 1 a řazení latin1_swedish_ci, český text ve Windows 1250? V takovém případě nelze automatických konverzí využít, protože by neproběhly správně, můžete ale použít jeden speciální trik a provést převod „ručně“.

Podmínkou pro použitelný výsledek následujícího postupu je, že v jednom sloupci tabulky se smí nacházet textová data pouze v jedné znakové sadě (v rámci jedné tabulky může být těchto sad více). Pak je možno sloupce datového typu CHAR, TEXT a odvozených převést na BINARY, BLOB a odpovídající (čímž se dosáhne binární kompatibility) a následně znovu převést na typ CHAR či TEXT již se správně definovanou znakovou sadou.

Řekněme, že jste používali MySQL 4.0.x a nyní přecházíte na MySQL 5.0.x. V databázi máte tabulku s jedním sloupcem, do kterého jste ukládali česká příjmení. Když databázi přenesete do nového serveru, jsou jména zdeformována, některé znaky jsou pozměněny. Proč? Protože jste do tabulky ukládali texty ve znakové sadě Windows 1250, ale server si myslí, že jde o ISO Latin 1, navíc švédsky. Použijte tedy následující:

ALTER TABLE jmeno_tabulky MODIFY jmeno_sloupce binary(10);
ALTER TABLE jmeno_tabulky MODIFY jmeno_sloupce varchar(10) COLLATE cp1250_czech_cs;

Než se začnete pokoušet o podobné operace, radil bych vám, abyste si kompletní databázi pečlivě zazálohovali. Konverze se nemusí podařit, můžete snadno opominout nějakou operaci, překvapení číhá na každém kroku. A data pozůstavší po nezdařené konverzi už nejspíš nikdo zrestaurovat nedokáže. V některých případech může být lepší data z databáze exportovat do textových souborů, ty ve vhodném editoru zkonvertovat a znovu importovat do nových, správně definovaných tabulek.

Nejčastější problémy

MySQL 5.0.x a vyšší obsahují opravdu velmi komplexní nástroje pro práci s textovými daty. Za úsporu práce a flexibilitu, kterou programátorovi poskytují, je ovšem nutno zaplatit. MySQL už dávno není databáze, o které její uživatel nemusí nic vědět – musí se s ní nejprve naučit pracovat, nebo alespoň dodržovat doporučené postupy, jinak se nevyhne řadě problémů.

Práci s textovými daty se nikdo nevyhne, na rozdíl třeba od transakcí, triggerů nebo uživatelských procedur, a tak se stále dokola objevuje určitá skupina problémů, jejichž řešení je dobré znát.

Data se nevejdou?

Představte si, že máte tabulku, do které chcete vložit nějaký text, a databáze vám vrátí něco jako MySQL connection error: Data too long for column 'jmeno_sloupce'. Proč, co s tím?

Tato chyba je velmi záludná, protože problém nespočívá v tom, že by se vámi vkládaná data skutečně nevešla do příslušného sloupce. Ve skutečnosti je problém v tom, že se pokoušíte vložit znak, jehož binární kód není obsažen ve znakové sadě, kterou používá onen sloupec.

Jak může k něčemu takovému dojít, když jsem všude tvrdil, že databáze si vše překóduje za běhu sama? Většinou jde o chybu programátora. Ten například v PHP skriptu použije následující hypotetický sled příkazů:

mysql_query(„SET NAMES ‚utf8′“);
…
mysql_query(„INSERT INTO tabulka VALUES (‚Příšerně žluťoučký kůň úpěl ďábelské ódy‘)“);

Teď už stačí, aby programátor „omylem“ uložil skript v odlišném kódování, například Windows 1250, a neštěstí je hotovo. Příkaz SET NAMES přesvědčí databázi, že má očekávat data v UTF-8, ale potom dostane řetězec, který je ve skutečnosti ve Windows 1250. Server se ho poslušně pokusí zpracovat, ale to se mu nepodaří, protože binární kód některých znaků s diakritikou používaný ve Windows 1250 ve znakové sadě UTF-8 neexistuje, pročež dojde ke kolapsu a oné chybové hlášce.

Ke stejné chybě dojde také tehdy, když se budete pokoušet uložit do tabulky nějaký znak, který neobsahuje znaková sada, kterou tabulka používá – typický je tento problém při pokusu o uložení textu s diakritikou do tabulky předpokládající pouze adiakritické znaky, například ASCII. Při pokusu o automatickou konverzi pak logicky dojde k chybě.

Data se skutečně nevejdou?

Ano, i k tomu může dojít. Představte si, že máte v databázi sloupec typu VARCHAR o kapacitě pěti znaků, který používá znakovou sadu Windows 1250. Následně můžete mít třeba řetězec „ěščřž“ ve znakové sadě UTF-8, který budete chtít do sloupce uložit. Operace se za určitých podmínek (například podobných předchozímu příkladu) nemusí zdařit, protože bitový zápis znaků s diakritikou je v UTF-8 „delší“ než ve Windows 1250 – databáze pak buď ohlásí chybu nebo data ořízne a uloží jen jejich část. Za normálního stavu věcí by ale k podobným problémům docházet nemělo.

Webová stránka zobrazuje špatně diakritiku?

Pokud čerpáte textová data z databáze, zpracováváte je ve skriptech a následně generujete webové stránky, vstupuje do hry řada dalších faktorů, které je nutno správně nastavit. Předpokládejme například, že máte databázi v UTF-8 a stránky mají být ve Windows 1250. Pak je nutno:

1. zajistit, aby skript při komunikaci s databázovým serverem vyžadoval výsledky ve znakové sadě Windows 1250
2. zajistit, aby skript odeslal vygenerovanou stránku s odpovídající http hlavičkou
3. zajistit, aby stránka deklarovala správnou znakovou sadu

Malý příklad, ve kterém vidíte správné nastavení prvního a posledního bodu, které působí problém nejčastěji:

<html>
<head>
<meta http-equiv=’Content-Type‘ content=’text/html; charset=windows-1250′ />
</head>
<body>
<?php
    mysql_connect(„localhost“, „mysql_user“, „mysql_password“) or die(„Could not connect: “ . mysql_error());
    mysql_select_db(„mydb“);
    mysql_query(„SET NAMES ‚cp1250′“)
    $result = mysql_query(„SELECT id, name FROM mytable“);
    while ($row = mysql_fetch_array($result, MYSQL_BOTH)) {
        printf („ID: %s Name: %s“, $row[0], $row[„name“]);
    }
    mysql_free_result($result);
?>
</body>
</html>

Povšimněte si především třetího řádku, kde sdělujeme klientovi, v jakém kódování vlastně je naše stránka, a řádku, kde v PHP skriptu pomocí SET NAMES nastavujeme odpovídající znakovou sadu. Tato dvě místa si musí vždy navzájem odpovídat!

Stále se diakritika zobrazuje špatně?

Přesvědčete se, že SET NAMES opravdu předchází všechny ostatní příkazy pro databázi – všimněte si, že v předchozím příkladu je jako první (bezprostředně po připojení k serveru a ihned po výběru databáze) použit příkaz mysql_query("SET NAMES 'cp1250'") a teprve poté jakékoli jiné mysql_query()!

Odkazy a zdroje

• Character Set Support – relevantní kapitola z manuálu MySQL 5.x
• MySQL & mSQL – něco málo o původu a vzniku MySQL
• MySQL 4.1 – kódování – Jakub Vrána (PHP triky, 8. 6. 2005)
• Orthographic diacritics and multilingual computing – zajímavé informace o diakritice a počítačích – John Wells (University College London, 27. 3. 2006)
• Převod kódování MySQL – Jakub Vrána (PHP triky, 7. 11. 2005)
• Unicode Collation Algorithm – řadící algoritmus pro Unicode
• Znakové sady v praxi (Interval.cz)

Starší komentáře ke článku

Pokud máte zájem o starší komentáře k tomuto článku, naleznete je zde.