Čárka, háček a WWW

Nejstarším nástrojem na výrobu dokumentů v naší rodině je psací stroj Underwood Standard z konce 20 let, tedy z doby asi třicet let po rozšíření průmyslové výroby psacích strojů. Má, samozřejmě, české typy. V té době bylo téměř urážkou národního cítění prodávat stroj, na němž by nebylo možné psát české texty.

Nyní, téměř sedmdesát let poté, uplynulo třicet let od rozšíření počítačů. V některých oblastech však stále ještě není samozřejmostí zpracování českých textů. Přitom na dnešních úhledných stránkách WWW "cestina" působí jako pěst na oko.

Autoři WWW stránek řeší situaci nejrůznějšími způsoby. Pokusíme se rozebrat příčiny nynějšího stavu a některé způsoby nápravy. Řešení, používané na serveru sdružení OMICRON, které dosáhlo určité obliby, popíšeme podrobněji.

Problém národního provozu WWW lze chápat buď jako problém lokalizace, tedy otázku dokumentu v dané národní znakové sadě, nebo jako problém internacionalizace, tedy otázku dokumentu obsahujícího texty ve více znakových sadách. A protože anglické termíny localization a internationalization jsou pro uspěchané Američany příliš dlouhé, setkáváme se zkratkami l10n a i18n (podle počtu znaků ve slově). Je zřejmé, že domácí uživatele zajímá nejvíce lokalizace, i když náš problém lze řešit využítím schopností internacionalizovaných produktů.

HTML dokument

Doba, kdy se internetové protokoly týkaly jen nevelkého společenství univerzitních uživatelů, je pryč. Dnešní služby musí být bezchybně provázány se standardy mimo Internet. Tak i jazyk HTML je aplikací SGML (Standard Generalized Markup Language). SGML je průmyslový standard pro vytváření dokumentů, které obsahují formálně definované značky (markups), umožňující strojové zpracování textu. Značky lze dosti přesně přirovnat k ESC-sekvencím ovládajícím zobrazení na tiskárně nebo terminálu.

Terminologie SGML vychází z pojmu dokument, který v případě textového dokumentu se skládá ze znaků. Znaky se vybírají ze znakové sady, kterou je třeba chápat jako repertoár (množinu) použitelných znaků. Normy dávají znakům jedinečná jména, např. velké Č se v normě ISO 8859-2 jmenuje CAPITAL LETTER C WITH CARON. Od znakové sady coby množiny znaků je třeba odlišovat kódování znakové sady, což je funkce, která přiřadí celému číslu z nějakého intervalu (nejčastěji 0 -- 255) znak. Pod pojmem "Latin 1" nebo "Kamenických", máme zpravidla na mysli znakovou sadu spolu s příslušným kódováním.

Každá aplikace SGML, tedy i HTML, má formální definici, tzv. DTD (Document Type Definition). DTD popisuje mj. i přípustnou syntaxi dokumentu. Musí tedy definovat i množinu přípustných znaků, a to pro všechny dokumnety. Standard HTML 2.0 [1], který lze považovat za výchozí bod všech modifikací a rozšíření, říká jasně: "Skutečná znaková sada reprezentace HTML dokumentu může být ISO 8859-1 nebo její 7bitová podmnožina, což je ISO 646."

CAPITAL LETTER C WITH CARON nepatří do znakové sady definované ISO 8859-1, "Č" tedy nemůže být součástí žádného HTML dokumentu. Totéž platí o řecké abecedě, azbuce, abecedách japonských atd. Proto je snah o překonání zmíněného omezení mnoho. Podle postoje k uvedenému citátu je můžeme rozdělit na "oficiální", které se jej snaží zněnit, a "partyzánské", které jej ignorují a využívají (či spíše zneužívají) vlastmostí konkrétních implementací a přenosového prostředí.

HTTP jako přenosové prostředí HTML dokumentů

Norma SGML ani jednotlivé DTD nestanovují, jak jsou znaky reprezentovány v elektronických médiích. To je záležitost přenosového prostředí. Jazyk HTML lze použít zcela nezávisle na WWW, třeba pro hypertextovou poštu. Je nutno odlišovat vlastní HTML dokument od přenosového prostředí (transportu). Přenosové prostředí je zpravidla realizováno navrstvením dílčích protokolů. WWW přenáší HTML dokumenty protokolem HTTP, který definuje přenášený dokument jako zvláštní případ dokumentu multimediální pošty (MIME) a který pracuje nad síťovým protokolem TCP/IP. Přenos je 8bitový.

Záhlaví MIME dokumentu obsahuje údaj o typu dokumnetu, v případě HTML tedy text/html. Typ dokumentu může být ještě upřesněn parametry jako je encoding (překódování původního osmibitového textu, např. uu-kódování) a charset (abeceda). Parametr "charset" se pro HTML dokumenty nepoužívá. Žádný dokument nemůže obsahovat jiné znaky než z repertoáru ISO 8859-1, není tedy třeba udávat abecedu znovu. Navíc vzikají terminologické neshody s SGML. Parametr "charset" se totiž běžně interpretuje jako "znaková sada", což není správné. Údaj "charset=iso-2022-jp" například znamená, že v MIME dokumentu bude používáno 8 znakových sad pro japonštinu, mezi kterými se bude přepínat podle normy ISO 2022 -- a to není "znaková sada", jak jsme ji zavedli výše a jak ji definuje SGML.

Zápis znaků v HTML dokumentu

Některé znaky, například "<" a ">", mají význam z hlediska syntaxe HTML a nemohou se tudíž přímo vyskytovat v textu. Jiné znaky (zejména znaky s diakritikou) nemusí být dostupné na stroji, kde text vytváříme. Jindy chceme omezit znaky v dokumentu na podmnožinu ISO 646, neboť dokument budeme dopravovat 7bitovým transportním prostředím. SGML (resp. odvozeně HTML) nabízí dvě metody:

1. Číselné reference
   Zápis ve tvaru &#nnn; kde nnn je dekadické číslo označuje znak, který by v kódování ISO 8859-1 měl hodnotu nnn.
2. Speciální entity
   Zápis &xxx; kde xxx je jméno znaku, má význam onoho znaku. Znak "přeškrtnuté o" se zapisuje "&oslash;", znak "<" se píše "&lt;". Seznam speciálních entit pokrývá ISO 8859-1.

"Oficiální" aktivity

Ještě před rokem situace vypadala nadějně. Internet Engineering Task Force (IETF) připravoval novou verze HTML 3.0 [3], někdy označovanou jako HTML+. Slibovala dvě změny významé z hlediska češtiny: byl rozšířen repertoár speciálních znaků na všechny evropské abecedy a každý odstavec měl mít nový atribut CHARSET, udávající znakovou sadu. Tak by např. do řeckého textu bylo možné vložit program v latince.

Současný návrh již tyto možnosti nemá a opakuje omezení na znakovou sadu ISO 8859-1 (zejména pro terminologické potíže rozebrané výše).

Souběžně s definicí HTML 3.0 vznikl dokument [4], obsahující pracovní verzi standardu HTML 2.1, zaměřeného na internacionalizaci. Hlavní myšlenka je jednoduchá: definovat jako znakovou sadu UCS-2 podle ISO 10646. Tato norma, co do kódování a repertoáru znaků shodná s Unicode, zahrnuje až 256 znakových sad a je souhrnem všech znakových sad, až dosud zavedených ISO. Např. všechny znakové sady ISO-8859-x jsou jejími podmnožinami, patří do ní také každý znak z oněch japonských osmi znakových sad.

V tomto kontextu je již možno stávajícím parametrem MIME "charset" oznámit klientu kódování dokumentu. Standard HTML 2.1 jde ještě dále a dovoluje klientům spolu s požadavkem na dokument oznámit serveru, jaké kódování může zpracovávat.

Je zřejmé, že tento standard zvládne lokalizaci bez problémů. Pro dokumenty o více znakových sadách lze použít ISO 10646 UCS-2 nebo znakové sady přepínat. Kód UCS-2 je ovšem šestnáctibitový a je těžké odhadnout, o kolik by vzrostlo zatížení sítě (závisí to na poměru textu a ostatních dat jako je grafika a zvuk).

Existuje normalizovaný způsob, jak přepínat mezi znakovými sadami. Norma ISO 2022 rozděluje kódový prostor 8bitových kódů na dolní a horní polovinu. V každé polovině je prvých 32 pozic vyhrazeno pro řídící znaky (oblasti C0 a C1) a 96 pozic pro zobrazitelné znaky, mezeru a znak DEL(oblasti GL a GR). Do oblastí GL a GR lze namapovat dvě ze čtyřech sad G0, G1, G2 a G3. O sadě G0 se předpokládá, že je shodná s ISO 646 a nemůže být mapována do horní oblasti. Je-li G0 v dolní polovině, jsou vlastně k dispozici tři znakové sady: G0+G1, G0+G2, G0+G3, mezi kterými můžeme přepínat definovanými ESC sekvencemi. Tím ještě není řečeno, co je vlastně obsahem G0 až G3. Jsou definovány další ESC sekvence, které říkají například "G1 budiž horní polovina znakové sady ISO 8859-2".

ISO 2022 umožňuje tedy 8bitové reprezentace dokumentu o více znakových sadách. Zatímco existuje hodnota parametru "charset" MIME dokumentu pro zmíněný mix japonských znakových sad, neexistuje nic, co by znamenalo "ISO 8859-2, ISO 8859-7, ISO 8859-4 přepínané podle ISO 2022" (tj. dokument s češtinou, řečtinou a ruštinou). V principu však zavedení takového typu nic nebrání.

Popsané metody, bohužel, vyžadují rekonstrukci klienta i serveru. V nejjednodušším případě klient musí vysílat, jaké "umí" znakové sady a reagovat na údaj o znakové sadě, který přichází ze serveru. Vyskytly se pokusy nahradit tyto údaje, dopravované přenosovým prostředím, údaji přímo v dokumentu, avšak nejsou dosud standardizovány.

Zásah do klienta i serveru je v našich podmínkách neúnosný. Zatímco klienty pro X windows jsou k dispozici ve zdrojovém tvaru a díky tomu často slouží pro experimenty s novými prvky HTTP a HTML, pro platformu nejrozšířenější, PC a MS Windows, není ani jediný ze známějších klientů dostupný ve zdrojovém tvaru. Je třeba se poohlédnout po metodách, které vystačí se stávajícími servery a klienty. A to je právě doména metod "partyzánských", založených na implementaci klienta a možnostech rozšíření serveru bez zásahu do jeho kódu.

Zpracování informace v klientu

Požadavkům standardu HTML 2.0 lze vyhovět například klientem podle obr. 1.

Běžné znaky se neupravují, číselné reference jsou převedeny do binárního tvaru a speciální entity se interpretují podle tabulky. Text je pak předložen zobrazovacímu systému, založenému na tabulce grafických podob jednotlivých znaků. Mezi textem a zobrazovačem by měl být ještě převod z ISO 8859-1 do znakové sady zobrazovače. V naprosté většině případů však zobrazovač sám pracuje přímo s žádanou znakovou sadou. To platí jak pro X windows (fonty ISO 8859-1), tak i pro MS Windows (kódová stránka CP1252). Máme tedy přímou, osmibitovou cestu mezi výstupem serveru a zobrazovačem klienta.

"Partyzánská" řešení

Společným základem většiny neoficiálních řešení je výměna tabulky grafických podob znaků v klientu. Jediným prostředím, kde to provést nelze, jsou znakové klienty pracující na terminálech s pevnými znakovými sadami, jichž je ale velmi málo. Je třeba počítat s tím, že k dispozici bude tabulka (X font, MS Windows font, VGA font) vždy jen pro omezený počet kódování znakové sady. Pro unixové systémy to bude nejspíše ISO 8859-2, pro MS-DOS nejspíše CP859 (bří Kameničtí), pro Windows CP1250 (Windows EE).

Stojíme tedy před dvěma zásadními problémy: jak zjistit správnou znakovou sadu a jak v ní získat dokument. Kromě toho by dobré řešení mělo umožnit vedení jak absolutních, tak relativních odkazů mezi dokumenty. Dokumenty nemusí být statické, mohou to být výsledky běhu programů spouštěných ze serveru, např. přes CGI (Common Gateway Interface) nebo jiné podobné rozhraní. Servery navíc rozpoznávají, co je statický dokument a co je spustitelný program podle komplikovaných pravidel zapsaných v konfiguračních souborech. Tento mechanismus by měl být zachován.

Nejprve se podívejme na dvě nejpoužívanější metody výběru znakové sady. Pak probereme způsoby, jak implementovat překódování dokumentu.

Navigace uživatelem

Nejpoužívanější metodou je nechat uživatele si vybrat z dvou možných variant: z nabídky jmen kódů či z ukázky textu. První metoda vyžaduje znalost názvů znakových sad; málokdo ví, co je to CP850 a název PC Latin 2 také málokomu něco řekne. Druhá metoda s sebou nese jisté, i když malé riziko. Norma ISO 2022 dělí, jak je uvedeno výše, prostor 8bitového kódu na oblasti C0, GL, C1, GR. Oblasti C0 a C1 obsahují řídící znaky. Terminál nebo terminálový emulátor, který je vystavěn podle této normy (populární VT100 a vyšší), interpretuje tedy kódy z oblasti C1 jako řídící. Například znak s dekadickým kódem 155 je CSI (Command String Introducer) ekvivalent posloupnosti znaků ESC [, tedy počátku mnoha ESC-sekvencí. Kódování některých znakových sad (za všechny jmenujme kód bří Kamenických a Windows EE) normě ISO 2022 nevyhovuje a používá kódů z oblasti C1. Co se stane, "strefí-li se" nabídnutý text do nějaké ESC sekvence nebo jiného řídícího znaku, je nasnadě. Přesto se obě metody v praxi osvědčují.

Znalost typu klienta

Součástí WWW dotazu je i údaj o programovém vybavení klienta a jeho verzi, předávaný CGI programům. Z tohoto údaje se dá mnohdy vydedukovat (alespoň přibližně), jakou znakovou sadu používá. Například, detekujeme-li Netscape Navigator 1.1N pro Windows (který o sobě mimochodem tvrdí, že je "Mozilla"), mohli bychom usoudit, že vhodné kódování znakové sady je CP1250. Znamená to ovšem udržovat databázi všech typů klientů, což s růstem popularity WWW přestává být možné.

Způsoby, jak zajistit uživateli správné kódování dokumentů, jsou také dva, i když existuje řada variant.

Oddělené sady dokumentů

Nejjednodušším řešením obou zmíněných problémů jsou oddělené podstromy pro jednotlivá kódování. Takové řešení je robustní, fungují jak absolutní, tak i relativní odkazy mezi dokumenty. Data ovšem na serveru zabírají více místa a hůře se udržují. Podstatnou nevýhodou je, že na dokument uvnitř sady neexistuje jednotný odkaz -- je jich tolik různých, kolik kódů server nabízí. Pro jednoduché servery, které nenabízejí více než ASCII a CP1250 a které nemají ambice stát se často citovaným informačním zdrojem toto řešení může postačovat.

Dynamický překlad

Nevýhody vícenásobného uložení odstraňuje dynamický překlad dokumentu během dopravy ke klientu. Existuje několik variant této metody, které se liší složitostí, způsobem implementace a mírou splnění shora uvedených požadavků. Dynamičnost metody zároveň otvírá cestu různým způsobům, jak zjistit vhodné kódování.

Síťový filtr

Představme si program, který přijímá TCP spojení např. na standardním síťovém HTTP portu 80. Přijme požadavek a sám se spojí se skutečným WWW serverem (obr. 2.)

Pak přenáší data oběma směry a patřičně je modifikuje. Je to jedna z nejelegantnějších verzí dynamického překladu. Zachovává všechna pravidla pro spouštění programů ze serveru, absolutní i relativní odkazy. Programově může být realizován stále běžícím procesem, a proto se při startu může i dosti složitě konfigurovat. Věc má, bohužel, jeden velmi postatný háček. Pro WWW server je adresa, odkud bylo navázáno spojení, důležitým údajem, který řídí přístup k dokumentům a který je přes CGI poskytován i spouštěným programům. Tento údaj by byl ztracen; spojení by vždy přicházela z předřazeného filtru.

CGI program

URL dokumentů v národních abecedách mohou být vedena na program, který dokument vyhledá a překóduje. Vstupní informací pro konverzní program je tedy jednak identifikace dokumentu, jednak údaj o kódování (pocházející například z předchozích výběrových kroků). Vzniká problém, jak tyto informace "poskládat" do URL. Máme opět několik možností.

URL pro první z nich je znázorněno na obr. 3

(s podobným uspořádáním experimentují na VŠE Liberec. "cgi-bin" označuje (symbolicky) místo, kde se nacházejí spustitelné programy. Další člen cesty server interpretuje jako jméno programu. Spustí tedy program, který se jmenuje stejně jako znaková sada. Zároveň převede zbytek URL na jméno souboru v souborovém systému serveru. Spuštěný program text překóduje a poskytne uživateli. Pokud se v textu vyskytne relativní odkaz na jiný dokument, vše dopadne dobře. Absolutní odkaz však nejsme s to zkonstruovat, závisí na znakové sadě, kterou v okamžiku tvorby dokumentu neznáme. Je však známa při zpracování dokumentu a lze ji tedy při překódování doplnit. Nejsnáze se to provede tak, že do URL vloží náhražka, třeba znaky __KOD__, a ty se pak vymění za správný název znakové sady. Z takto upravené kotvy klient již vyrobí funkční odkaz. Poznamenejme, že odkazy na soubory, jejichž obsah nesmí být překódován, například vnořená grafika, musí být absolutní.

Stále však nejsme schopni vést na dokument odkaz zvnějšku, bez znalosti kódování. Jsme tedy v podobné situaci, jako s předem vygenerovanými verzemi dokumentů. Co se týče dokumentů, které jsou výsledkem práce jiných CGI programů, situace se dokonce zhoršila. Náš program by musel napodobit algoritmus serveru pro rozpoznávání spustitelných souborů a musel by sám realizovat rozhraní CGI. Situaci lze zlepšit konstrukcí programu (ten bude vystupovat jako "univerzální kódování" a vrátí dokument s nabídkou), do něhož byly vygenerovány odkazy na jednotlivé znakové sady. Pokud bychom však chtěli dovolit uživatelům doplňovat nové znakové sady, bezpečnostní hlediska implementaci této varianty značně zkomplikují.

Další možností je uspořádání URL z obr. 4.

Nemáme nyní tolik programů, kolik je znakových sad, ale jeden, který interpretuje prvý člen zbytku URL jako název kódové sady. Jsme k tomu plně oprávněni; definice URL [5] říká, že cestu v URL interpretuje jedině server. Pokud tento člen není jménem znakové sady, program usoudí, že znaková sada není známa a předloží nabídku. Ať už je NABÍDKA založena na jakékoli metodě, dokument s nabídkou musí být rovněž transformován. Do odkazů na jednotlivé verze je nutno doplnit jméno žádaného dokumentu. Jméno znakové sady se předává v odkazech a proto není nabídka uživateli předkládána zbytečně. Závada této metody je, že jméno dokumentu v souborovém systému, nabídnuté programu serverem, nesouhlasí. Program si překlad musí udělat sám a napodobit co nejlépe algoritmus konkrétního serveru. Mechanismus relativních i absolutních odkazů zůstává stejný jako u předešlé metody.

Situaci lze zjednodušit použitím dotazových řetězců (obr. 5).

Toto uspořádání je dílem Jana Košťála z ČVUT FEL, autora původní verze programu WWWdia a používá se na serveru sdružení OMICRON. Není-li v URL žádný dotaz, předloží se uživateli nabídka s dynamicky generovanými odkazy tak, jak bylo popsáno. V opačném případě je dokument překódovám, přičemž do kotev je doplňován správný název znakové sady. Je to nutné provádět jak u relativních, tak u absolutních odkazů. Poznamenejme, že realizace s textovou náhradou surogátu (zde je to __CHARSET__) je nejpohodlnější, ale nikoliv jediná možná. V původní verzi náhradu prováděl textový makroprocesor m4. Novější verze surogát zachovaly z důvodů zpětné slučitelnosti, i když analýza HTML a detekce kotev by nebyly nadměrně složité. Fungují tedy relativní i absolutní odkazy, lze zapsat fungující odkaz bez určení znakové sady a program vyžaduje volbu znakové sady uživatelem jen v nutných případech. Potíže se spouštěním CGI programů pochopitelně zůstávají, takže tato možnost ve stávající verzi WWWdia implementována naní.

Zatímco jádro funkce WWWdia s funkcí popsanou výše je realizováno jediným programem, podpůrné a obslužné programy jsou mnohonásobně rozsáhlejší. Tzv. kódová samoobsluha, nástroj dovolující uživateli vytvořit vlastní kódování a zanechat je na serveru, původně vznikl jednak z maximalismu a jednak jako poněkud nevrlá reakce na žádosti o nové znakové sady. Její provoz však přinesl dobré nápady (např. využít ISO 8859-1 pro část diakritiky) a stal se fascinujícím výletem do počítačové folkloristiky. V době psaní tohoto článku je na serveru OMICRONu kromě původní CP1250 ještě _šest_ dalších verzí této znakové sady. Přitom programy samoobsluhy nedovolí zařadit znakovou sadu, která se shoduje s něčím, co na serveru již je. Většinou jde o náhrady různých znaků znakem "háček". Nemám představu, co je příčinou tohoto jevu, ale znakové sady zatím na serveru ponechávám. Poslední verze WWWdia má doplněny nástroje pro zobrazení, srovnání a šíření znakových sad. Programy jsou k dispozici na URL:

ftp://service.felk.cvut.cz/pub/export/software/WWWdia-K2.1.tar.gz

Nikdy jsem si nepomyslel, že budu patřit k internetové guerille a tropit, co IETF nekáže. Ohlas na popsané práce však svědčí o tom, že dnešní internetová komunita potřebuje stejně dobrou prezentaci mateřského jazyka jako grafiky. Z tohoto pohledu se názor, pokládající diakritiku na WWW za zbytečnou, jeví jako pošetilý. Naopak soudím, že v dnešní situaci je třeba dát přednost zjevným potřebám uživatelů před dodržováním norem za každou cenu.

Literarura

[1] Berners-Lee, T., Connoly, J.: Hypertext Markup Language Specification 2.0. Pracovní text. Hypertext Makrkup Language Working Group, 1994.

[2] Berners-Lee, T., Fielding, R. T., Nielsen, H. F.: Hypertext Transfer Protocol -- HTTP/1.0. Pracovní text. MIT, UC Irvine, CERN, 1995

[3] Ragett, D.: HyperText Markup Language Specification Version 3.0, Internet draft, 1995

[4] Information processing -- ISO 7-bit and 8-bit coded character sets -- Code extension techniques. International Standard 2022, 1986.

[5] Berners-Lee, T., Masinter, L., McCahill, M. (eds): Uniform Resource Locators, RFC1738

Jan Schmidt

pracuje na katedře počítačů FEL ČVUT.
Vyvíjí síťové technologie pro sdružení OMICRON.
e-mail: schmidt@cs.felk.cvut.cz