Jak fungují háčky a čárky v doménách?

CZ.NIC se rozhodl prozatím neimplementovat diakritiku v doménách druhé úrovně, pod národní doménou .cz. V jiných státech však obdobná možnost existuje a používá se. Jak ale vše funguje a jak se vůbec pracuje s doménami, které obsahují jiné než čistě ASCII znaky? Jaká je podpora v browserech? Co již pokývají standardy a co se ještě musí dořešit?

V pondělí jsem zde na Lupě psal o tom, jak se CZ.NIC rozhodl prozatím nezavádět háčky a čárky do českých domén druhé úrovně (pod TLD (Top Level Domain) .cz). V závěru jsem se také zmínil, že k samotnému fungování diakritiky v doménách se vrátím v samostatném článku. Zde tedy je. Ještě než budete pokračovat v jeho čtení, rád bych upozornil na to, že stejná problematika již byla na Lupě probírána i dříve (například v článku pana Satrapy s příznačným názvem „IDN aneb žluťoučký.kůň.cz“ v únoru loňského roku). Aby nešlo o pouhé opakování, pokusím se tento článek koncipovat názorněji a více pro prakticky.

Co je IDN?

Způsobů, jak do doménových jmen zabudovat nejen českou diakritiku, ale i podporu jiných národních znaků a celých „cizokrajných“ abeced, může existovat celá řada. Možná nejtěžší je dohodnout se na jednom z nich, a to dostatečně přesně vymezit a popsat. Naštěstí toto už se podařilo a výsledkem je koncept s názvem IDN (Internationalized Domain Names). Důležité je, že již od března předloňského roku má podobu platného internetového standardu (RFC 3490, 3491, 3492 a 3454). Takže když se někdo rozhodne podporu diakritiky (národních abeced) implementovat, ví, jak to má udělat. Samozřejmě to ještě neznamená, že IDN vůbec musí implementovat – viz právě záporné rozhodnutí CZ.NIC.

Na druhou stranu si rovnou řekněme, že celý koncept IDN se týká pouze symbolických doménových jmen (tedy např. onoho „žluťoučký.kůň­.cz“). Nepokrývá tedy úplně vše, co by v souvislosti s národními abecedami (a českou diakritikou) mělo být vyřešeno a standardizováno, abychom mohli bezproblémově používat třeba českou diakritiku v celých internetových adresách. V tzv. URI (Uniform Resource Indicator), které např. identifikují jednotlivé WWW stránky, se totiž vedle doménového jména (a tzv. schématu, které říká, zda jde o WWW stránky či jiný typ objektu) vyskytuje mj. i přístupová cesta.

1494

Standardy IDN však pokrývají pouze část těchto URI (pouze samotná doménová jména) a neříkají, jak korektně a jednotně zabudovat diakritiku a obecně národní abecedy do přístupových cest (včetně jmen a přípon souborů). Tedy jak psát adresy typu http://žluťou­čký.kůň.cz/stáj/po­destýlka/seno­.html. I na tom se samozřejmě pracuje a výsledkem bude další koncept, označovaný jako IRI (Internationalized Resource Indicators). Bude rozšířením (nadmnožinou) současných URI a IDN bude jednou z jeho částí. Příslušný standard je ale zatím teprve v návrhu.

Základní princip IDN

Vraťme se tedy k samotnému principu IDN, resp. k samotným doménovým jménům. Klíčem k pochopení základních myšlenek IDN je uvědomit si, že doménová jména jsou v rámci Internetu překládána na číselné IP adresy. Tento překlad zajišťuje systém DNS, který si lze představit jako rozsáhlou distribuovanou databázi, obsahující informace typu

stroj se jménem „žluťoučký“ v doméně „kůň.cz“ (tj. „žluťoučký.kůň.cz“) má IP adresu 123.321.111.222.

Lidé, kteří vymýšleli IDN, mohli navrhnout změnu fungování celé této obrovské distribuované databáze, resp. všech tzv. name serverů, které ji tvoří, tak, aby uměly pracovat s českou diakritikou i s národními abecedami. Ovšem aktualizace takého množství individuálních prvků obrovského systému by byla nepředstavitelným oříškem.

Autoři IDN naštěstí zvolili schůdnější cestu. Rozhodli se ponechat fungování systému DNS tak, jak je, a tedy s omezením jen na jména domén tvořená z čistých ASCII znaků (přesnější pravidla a omezení viz např. zde): Samotnou podporu národních abeced se pak rozhodli koncipovat jako nadstavbu nad tímto systémem.

1495

Konkrétní představu ilustruje následující obrázek: „národní tvar“ doménového jména, který může obsahovat nejrůznější ne-ASCII znaky, je přeložen do takového tvaru, který již obsahuje jen samé ASCII znaky. Proto se také označuje jako ACE (ASCII Compatible Encoding). Tento „ACE-tvar“ doménového jména již je stávající systém DNS schopen zpracovat, tj. překládat doménová jména v tomto tvaru na číselné IP adresy.

Vzhledem k tomu, že celé IDN je řešeno jako nadstavba nad stávajícím DNS, je překlad do ACE tvaru řešen plně v klientském programu, se kterým pracuje uživatel. Tedy například v jeho browseru. Do DNS pak vstupuje (k překladu) již přímo ACE tvar doménového jména.

Jak vypadá ACE tvar?

Princip překladu do ACE tvaru ukazuje následující obrázek. Příslušný způsob kódování je označován jako „punycode“ a lze si je pro jednoduchost představit takto:

1496
  • přeložený (ACE) tvar vzniká připojením pevně daného prefixu („xn–“), jenž signalizuje, že jde o IDN jméno,
  • všechny čistě ASCII znaky z původního tvaru se ponechají beze změny,
  • jiné než ASCII znaky se zakódují pomocí čistě ASCII znaků.

Kromě právě naznačeného překladu („punycode“) je součástí IDN ještě jedna úprava „národního tvaru“ (tzv. nameprep). Existuje kvůli tomu, že „národní tvar“ může mít více různých podob, a nemusí být úplně triviální je mezi sebou převádět, resp. najít jeden kanonický tvar, který je pak převáděn do ACE tvaru. U jmen s českou diakritikou to ještě jde, takže se „nameprep“ redukuje prakticky jen na převod na převod z velkých písmen na malá (třeba jméno „NĚMec“ převede na „němec“). V jiných jazycích, třeba čínštině či japonštině, ale může být „nameprep“ pořádným oříškem.

Co obnáší registrace „nové“ domény?

Když už víme, že celý IDN je nadstavbou nad stávajícím systémem DNS a že překlad z národního tvaru do čistého ASCII tvaru (ACE tvaru, skrze nameprep i punycode) má na starosti klientský program, co pak vlastně obnáší získání (zaregistrování) nějaké domény s národními znaky?

Nejjednodušší odpověď by mohla znít tak, že je nutné si zaregistrovat doménu přímo v ACE tvaru. Takže třeba zájemce o doménu „böhm.de“ by si fakticky zaregistroval doménu „xn–bhm-sna.de“. Zájemce o doménu „böhm.ch“ zase doménu „xn–bhm-sna.ch“, zájemce o doménu „němec.cz“ doménu „xn–nmec-gwa.cz“ atd.

Ovšem tam, kde správce národní domény IDN nepodporuje, by registrace domény v punycode neměla být možná. Klasická doménová jména by totiž neměla obsahovat dvě pomlčky těsně za sebou – a třeba CZ.NIC, stejně jako většina ostatních správců národních domén, toto má (resp. do zavedení IDN měla) explicitně zakázáno ve svých pravidlech pro tvorbu doménových jmen. Díky tomu by se nemělo stát, aby jakékoli „nové“ jméno domény (podle IDN) kolidovalo s nějakou již existující (ne-IDN) doménou. Stejně tak by se tímto opatřením (zavedením prefixu „xn–“ mělo zabránit tomu, aby ještě před zavedením IDN někdo obsadil budoucí IDN domény.

Na druhou stranu, jakmile je IDN v nějaké národní doméně zavedeno, je registrace domén (druhé úrovně) v ACE tvaru možná a podporovaná. Na následujícím obrázku vidíte příklad takovéto registrace domény böhm.ch ve Švýcarsku. Tamní NIC v příslušném výpisu uvádí jak „národní“ tvar domény, tak i její ACE tvar.

1497

K tomu všemu je dobré dodat, že právě popsaná úvaha platí obecně, ale zde je vztažena hlavně na správce národní domény (domény nejvyšší úrovně, neboli TLD). Je na tomto správci, jak se rozhodne a zda podporu IDN zavede či nikoli.

Pokud jde o doménová jména nižších úrovní, tam již vše závisí na tom, kdo je jejich správcem. V ČR jsou uživatelům přidělovány domény druhé úrovně, a to znamená, že o doménách třetí a další úrovně si rozhodují tito uživatelé sami. Takže je pak v jejich moci zavést na úrovni těchto domén podporu diakritiky i dalších národních abeced. Příklad vidíte na následujícím obrázku.

1498

Podpora v klientech

Již tedy víme, že IDN bylo záměrně zvoleno jak nadstavba nad stávajícím systémem DNS, tak aby tento systém nebylo nutné měnit ani nijak aktualizovat. Díky tomu také nemůže docházet k situacím, že by doménová jmena s národními znaky fungovala jen někde, a jinde ne (podle toho, kde je uživatel připojen k Internetu a jaký DNS server používá).

Místo toho je zde ale jiný problém: jestliže překlad z „národního“ do ACE tvaru zajišťují klientské programy, pak to musí umět, resp. musí IDN podporovat. A to některé umí a jiné naopak nikoli. V praxi samozřejmě záleží i na verzích, IDN může být podporováno až od určité konkrétní verze výše. A pokud nepodporuje, stále zde může existovat možnost svůj browser či jinou aplikaci vhodně rozšířit tak, aby IDN podporovala. U browserů konkrétně skrze tzv. pluginy. Jaká je tedy realita?

S prohlížečem Firefox ani s browserem Netscape verze 7.1 jsem neměl problémy, podpora IDN fungovala, jak měla. Naopak s Internet Explorerem od Microsoftu jsem neuspěl, a to ani přesto, že třeba tento seznam naznačuje, že by IDN měl podporovat nativně. Když jsem se pídil po důvodech, na webu Microsoftu jsem skutečně našel, že MS dosud IDN nepodporuje ani v IE 6.0, a o případné podpoře pouze uvažuje („Internet Explorer does not currently support IDNs, but we are investigating the integration of IDN support in Internet Explorer and in other Microsoft products.“, Last Review : December 3, 2004). Možná tedy čekají na standardizaci IRI a teprve pak budou vše implementovat. No, alespoň že pro Microsoft browsery existují pluginy od externích subjektů:

Podpora IDN s ovšem netýká jen browserů, ale obecně všech klientů, kteří pracují s doménovými jmény.

Několik příkladů

To, že některé browsery nepodporují IDN a jiné naopak ano, můžeme využít k několika ilustrativním obrázkům, k dokreslení praktického použití.

Následující obrázek ukazuje použití browseru Mozilla Firefox, který IDN podporuje, a byla mu zadána adresa http://www.böhm­.de. Výsledkem je zobrazení stránky na této adrese, tj. zde vše funguje tak jak má.

1499

Další obrázek ukazuje stejný browser, kterému ale byla zadána adresa přímo s doménovým jménem v ACE tvaru. Výsledek je stejný, zobrazena je identická stránka.

EBF16

1500

Následující obrázek je velmi ilustrativní, protože názorně demonstruje, jak uvnitř browseru podporujícího IDN dochází k překladu do ACE tvaru. Zadána byla adresa http://www.ně­mec.cz, a i při korektním převodu do ACE tvaru to skončilo neúspěchem, protože „přeložená“ doména (xn–nmec-gwa.cz) neexistuje. A vzhledem k rozhodnutí CZ.NIC ani existovat nebude (zatím). Hláška, kterou vidíte v okně browseru, je od utilitky zachytávající průběh komunikace browseru se serverem.

1501

Zkusme nyní Internet Explorer verze 6.0, bez plug-inu zavádějícího podporu IDN. Zkusme nejprve zadat stejnou adresu jako v předchozím případě, tj. již přímo v ACE tvaru. Pak vše dopadne tak jak má a cílová stránka se korektně zobrazí. Je to díky tomu, že Internet Explorer nemusel nic překládat (ani by to neuměl), místo něj si překlad zajistil sám uživatel. Právě toto by asi byla situace mnoha uživatelů, jejichž browser by buď nepodporoval IDN vůbec, nebo by oni nedokázali sami zadat příslušné doménové jméno v jeho „národním tvaru“. Místo toho by museli zadávat přímo ACE tvar (pokud by se k němu nějak dostali).

1502
Pokud bychom stejnému Internet Exploreru (stále bez podpory IDN) zadali nějakou adresu přímo v jejím výchozím („národním“) tvaru, pak si s ní neporadí. Utilita pro zachytávání HTTP hlaviček ukazuje, že browser sice diakritiku v doménovém jméně přeložil, ale úplně jinak (nikoli skrze punycode, který vůbec nezná a nepodporuje).
1503

Anketa

Podporuje vámi používaný browser IDN, ať již přímo či přes plugin?

63 názorů Vstoupit do diskuse
poslední názor přidán 3. 1. 2010 14:32

Školení Správa Stránek na Facebooku

  •  
    Jak pokročile spravovat Stránku, Události, Skupiny.
  • Jak tvořit i netvořit příspěvky.
  • Jak nepřijít o účet, nenaletět a neztratit všechno.

Detailní informace o školení Správa stránek na Facebooku »