Hlavní navigace

Umíte napsat URL?

Martin Kopta 30. 11. 2000

Donedávna jsem byl přesvědčen, že mé názory na to, jak má vypadat URL, jsou možná až příliš poznamenané pedagogickým důrazem na názornost. Nikde jsem se proto se svým názorem neproducíroval. Až donedávna, přesněji do té doby, než jsem si přečetl jeden článek na ruské obdobě serveru Grafika online.

Vzhledem k tomu, že pokud vím, web design se u nás zatím soustavně nevyučuje, zůstávají jedinými odpovědnými za svou odbornost sami web designeři a autoři různých příruček pro webmastery. Ne každý měl asi v knihkupectví takové štěstí, že natrefil na Satrapův Web Design (Satrapa, Pavel: Web Design. Neokortex, Praha, 1997, ISBN 80–902230–1-X), kde autor za URL ztratil slovo. S dotazem k adresářové stavbě webserveru a cestám v URL se na mě v poslední době obrací stále více koderů, zvláště pokud mají připravit rozsáhlý informační system, u kterého se v budoucnu předpokládá růst. Musím říci, že kromě knihy Pavla Satrapy pro mě v tomto směru byla velmi důležitá škola, kterou mi poskytli líní, lhostejní a nespolupracující administrátoři, které jsem za těch pár let potkal.

Dokud nebudeme mít k dispozici funkční system URN, bude URL jedinou cestou, jak získávat informace z Internetu. O URN se hovoří jako o vyspělejší formě odkazování hlavně z toho důvodu, že umístění zdroje se mění, kdežto názvy nikoli. Pokud v případě měst dochází častěji ke změně názvu (srovnej město Zlín) než k změně umístění (srovnej město Most), pak v případě zdrojů na Internetu je tomu právě naopak. Určitě už se vám někdy stalo, že jste po čase zavítali na určitý FTP server a soubor, jenž jste hodlali získat, tu již nebyl (mohl být třeba přesunut do adresáře /pub/app/old).

Jeden z nejdůležitějších nároků na URL je její stálost. Správce internetových sídel by měl při návrhu struktury postupovat velmi rozvážně. Měl by například brát v úvahu budoucí vývoj, kdy je možné, že stávající drobná prezentace se rozroste v informační system olbřímích rozměrů. Webmaster by měl počítat s tím, že dokumenty budou zastarávat, měnit se, přibývat. URL by se zásadně neměla měnit, jenom protože se změnil vzhled sídla nebo server. Trochu problém je při přesunu souborů z jedné domény na druhou. Například když své sídlo z poskytovatel­.cz/sidlo přesunete na sidlo.cz. Právě nespolupracující administrátoři mě donutili, abych se poohlédnul po nějakém řešení a světe, div se, ono existuje a je dokonce velmi snadné (a každému webhosterovi známé). V předvolbách webserveru se dá nastavit přesměrování, a to dokonce velmi chytré přesměrování založené na regulárních výrazech (viz Apache.org, mod_rewrite). Pokud už dojde k takovému přesunu, je žádoucí, aby na to byl uživatel upozorněn například tím, že se mu na několik sekund zobrazí stránka s informací o změně, a následně je přesměrován. K tomuto řešení potřebujete chybovou stránku a možnost zjistit volanou URL a její přestavění na novou URL podobně jako v předchozím případě.

Při redesignu jednoho statistického serveru mě zadavatel upozorňoval na to, že je celý postaven na technologii ASP a tabulkách XLS. Při bližším pohledu však vyšlo najevo, že server poskytuje obyčejné HTML a tabulky tu jsou jen ke stažení – přípony občas matou. Server jsme přepsali v PHP, ale původní přípony jsme zachovali. Při pohledu na URL serveru developer.net­scape.com bych také nedal moc za to, že stránky s příponami HTM jsou ve skutečnosti vygenerované. Mnozí webmasteři ovšem o možnosti provést lokální změnu v nastavení obsluhy přípon netuší a administrátoři jim v tom nepomohou. Vrtá mi hlavou proč. Proč nemá koder-profesionál ambici vyzvědět něco o fungování webserveru? Proč se administrátoři serverů nenamáhají s klientem spolupracovat? Výsledek společného úsilí by přeci byl ku prospěchu všech (studio si nechá své úsilí zaplatit, webhoster může fakturovat práci administrátora).

Pro kvalifikaci webmastera je nepostradatelná znalost různých operačních systemů. Například ze Apple MacOS jsem zvyklý, že názvy nemohou být moc dlouhé, z Windows vím, že nezáleží na velikosti písmen a v unixu mě nepřekvapuje absence automatického rozpoznání datového formátu souboru. Jako webmaster tedy budu navrhovat strukturu website tak, aby nekolidovala s žádným z možných webserverů, na kterých možná někdy poběží. Přesto už jsem se nejednou v URL setkal nejen s ignorací problému OS, ale dokonce s nerespektováním RFC 1738 (zvláště co se dovolených znaků týče).

Dalším požadavkem na URL je možnost snadného zapamatování nebo alespoň reprodukce. Ruští kolegové dokonce v této souvislosti protestují proti kombinování ruštiny a angličtiny (jak v cestě jako takové, tak i v každém názvu jednotlivě). V případě ruských kolegů se k tomuto doporučení také přikláním: pro mě je už tak dost matoucí transkripce ruštiny do latinky. Pro potřeby českých serverů a českých uživatelů snad postačí, když řeknu, že URL by se měla pokud možno skládat ze slov, že by neměla obsahovat neobvyklé znaky a neprůhledné shluky znaků. Reprodukovatelnost URL vzala zasvé zvláště v poslední době, kdy je každý druhý server napsaný v nějakém serverovém skriptu. Je sice výborné, že dokážete každý typ obsahu vyvolat pomocí jediného skriptu s patřičnými proměnnými, ale věřte, že pro člověka, který si chce adresu opsat, je statická prezentace mnohdy zajímavější. Zajímavé řešení tohoto problému mně ukázal Jakub Chromý u projektu miesto.sk, kde obsahu dosahujete pouze pomocí řady adresářů, soubory jsou pak inicializační. Tímto řešením se vyhnete problému s přechodem na jiný server s jinými příponami nebo technologiemi – URL tu totiž nic nevypovídá o způsobu sestavování obsahu dokumentu, ale o jeho začlenění do obsahové stuktury. Domnívám se, že kdyby podobný postup zvolili ti, kdož nechávají čtenáře ke všem stránkám serveru přistupovat pomocí souboru /go.asp, čtenáři by to náležitě ocenili (třeba snížením náporu na fulltextový vyhledavač). Navíc myslím, že by neměl být problém říci webserveru, že cesta oddělovaná lomítky nesměřuje k adresářům, ale že mezi lomítky se nacházejí promenna_hodnota (~ s///&/g; ~ s/_/=/g;).

A posledním, ne však zanedbatelným nárokem na URL podle mého gusta je její schopnost vypovídat o obsahové struktuře sídla – tato vlastnost se v odborné literatuře pojmenovává jako navigovatelnost (navigability). Znamená to, že pokud odmažeme jakýkoli počet celků (názvů souborů a adresářů) od konce, vždy se dostaneme na stránku umístěnou v obsahové hierarchii výše. Pro správce internetového sídla to pak znamná imperativ v každé složce ustanovit inicializační dokument.

Není to mnoho, co po tvůrcích URL požaduji: stálost, srozumitelnost a navigovatelnost. Mohl bych také chtít, aby URL nebylo delší než 1024 znaků (aby nepůsobilo problémy s browsery), než 255 znaků (aby se dalo zanést do VarChar v databázi), než 160 znaků (aby se mohlo odeslat přes SMS) nebo než 76 (aby se nelámalo při posílání v e-mailu). Mohl bych chtít, aby názvy souborů a adresářů nebyly zbytečně dlouhé (trable_s_nej­nezprostredko­vavatelnejsimi_ zazitky_z_dovo­lene_na_jezere_ti­tikaka.html) a podobně. Ale opravdu mi postačí jen ty tři vlastnosti.

Pokud se nebojíte azbuky, doporučuji vaší pozornosti článek : design.ru.

Našli jste v článku chybu?

5. 12. 2000 23:22

Martina Kopty (neregistrovaný)
??? Musím si po sobě ten článek ještě jednou přečíst. Já vážně netuším, co to tu rozebíráte :(

Nešlo mi momentálně o ruské kódování v URL, ale o transliteraci. To je proces, kdy znak po zznaku převádíte text z jednoho znakového systému do druhého. Každému znaku v původním textu odpovíddá jeden znak v novém. Nebo možná o transkripci, kdy se znaky převádějí podle toho, jak znějí. Ruské S nezní jako %C1, ale jako S. Člověk napíše článek o zřeteli na human code, a vy na něj vyrukujete s %C1.

4. 12. 2000 19:05

J.Kastl (neregistrovaný)
1. Triviálně je řešeno přesměrování-nepřesměrování na http://kizi2.vse.cz/kizi/IKSy/ Je v něm ale ještě schováno "inteligentní" přesměrování s volbou kódu češtiny. - Kdo umí rychle klikat, přesměruje se sám třeba lépe. ( Blíže viz kapitola 8 tamtéž ) 2. URL doporučuji raději studovat z RFC 2396. Podle něj by problém ruštiny - patrně se myslí ruské S a české C - neměl nastat. Ruské S musí být v URL vždy jako %C1 .
Lupa.cz: Na koho se v Křišťálové Lupě nedostalo?

Na koho se v Křišťálové Lupě nedostalo?

Podnikatel.cz: Pozor, pojišťovny mění čísla účtů

Pozor, pojišťovny mění čísla účtů

Podnikatel.cz: Přehledná titulka, průvodci, responzivita

Přehledná titulka, průvodci, responzivita

Vitalia.cz: Naučí vás péct kváskový chléb bez lepku i s lepkem

Naučí vás péct kváskový chléb bez lepku i s lepkem

Vitalia.cz: Chtějí si léčit kvasinky. Lék je jen v Německu

Chtějí si léčit kvasinky. Lék je jen v Německu

Podnikatel.cz: Berňák kvůli EET prodlužuje otevírací dobu

Berňák kvůli EET prodlužuje otevírací dobu

Podnikatel.cz: Na poslední chvíli šokuje vyjímkami v EET

Na poslední chvíli šokuje vyjímkami v EET

120na80.cz: Na ucho teplý, nebo studený obklad?

Na ucho teplý, nebo studený obklad?

Root.cz: Telegram spustil anonymní blog Telegraph

Telegram spustil anonymní blog Telegraph

Podnikatel.cz: Dárky v podnikání. Jak je uplatnit v daních?

Dárky v podnikání. Jak je uplatnit v daních?

Lupa.cz: UX přestává pro firmy být magie

UX přestává pro firmy být magie

120na80.cz: Rovnátka, která nejsou vidět

Rovnátka, která nejsou vidět

Lupa.cz: Google měl výpadek, nejel Gmail ani YouTube

Google měl výpadek, nejel Gmail ani YouTube

Měšec.cz: Zdravotní a sociální pojištění 2017: Připlatíte

Zdravotní a sociální pojištění 2017: Připlatíte

Podnikatel.cz: Na 3. prosince se chystá protest proti EET

Na 3. prosince se chystá protest proti EET

Lupa.cz: Babiš: E-shopů se EET možná nebude týkat

Babiš: E-shopů se EET možná nebude týkat

Vitalia.cz: Mondelez stahuje rizikovou čokoládu Milka

Mondelez stahuje rizikovou čokoládu Milka

Podnikatel.cz: Zavře krám u #EET Malá pokladna a Teeta?

Zavře krám u #EET Malá pokladna a Teeta?

DigiZone.cz: Digi CZ výrazně zlevnila balíček HBO

Digi CZ výrazně zlevnila balíček HBO

Měšec.cz: Kdy vám stát dá na stěhování 50 000 Kč?

Kdy vám stát dá na stěhování 50 000 Kč?