Gopher Menu
Radeji prepnete "Caps Lock" ( na VELKE )
System NOTIS
Anonymne pristupny LYNX
Dá se vlastně říci, že téměř vše je v Internetu založeno na spolupráci programů přes virtuální přenosový kanál. Program na počátečním počítači, který obvykle aktivuje uživatel, spolupracuje s nějakým (připraveným) programem na cílovém počítači. Často se v této souvislosti hovoří o architektuře "klient - server" jako typické pro síť Internet. To je možná výstižné z hlediska prvního pohledu na takovouto spolupráci. Pro "druhý" pohled je však někdy nevhodné vždy rozlišovat, který program jako klient začíná a který program jako server odpovídá. Server se vztahuje k "service", jako služba, zabezpečení, což asi nejlépe vystihuje účel využívání připraveného programového vybavení na cílovém počítači. Klient, tedy programové vybavení použité na (počátečním) počítači uživatelem, se snaží zprostředkovat přenášené údaje ve tvaru pro uživatele dobře ( či alespoň lépe ) srozumitelném. Cílem je zpravidla snížit takto nároky na přenos mezi počátečním a cílovým počítačem - oproti situaci, kdy se vše přenáší z cílového na počáteční počítač přesně již v takové formě, v jaké je zpřístupňováno uživateli.
Samotné slovo "server" se obzvláště v Čechách používá často i jako synonymum pro počítač jiný než osobní. Asi zde hrála určitou roli skutečnost, že řada uživatelů si jako něco jiného než PC byla schopna představit snad ještě (Novellovské) LAN-ové servery. Počítač zapojený do komunikační sítě se v zahraniční terminologii obvykle nazývá node ("uzel") nebo host ("hostitel"). A slovo server je používáno v souvislosti se zabezpečením nějakých programových služeb. Možná by se dalo i říci, že server je chápán jako to, co je v Internetu definováno dvojicí { počítač port } .
Problém interpretace "klient-server" je ale především v tom, že klient se
muže chovat i jako typický server, nemusí být aktivován uživatelem, může
spolupracovat s více servery anebo i se serverem, který je sám klientem.
Například pro FTP - jednu ze základních funkcí Internetu - je z cílového
(hostitelského) počítače vytvářen pro přenos souborů druhý přenosový kanál
( na port 20 ), na což musí FTP-program aktivovaný na počítači uživatele
správně odpovědět.
Jiným příkladem je známý program TELNET používaný v prostředí MS-DOSu. Tento
program je obvykle schopen pracovat také jako FTP-démon neboli server.
Toho uživatelé často využívají, když jsou zalogováni na nějaký vzdálený
(hostitelský) počítač a potřebují si odtud přenést soubor k sobě do MS-DOSu.
Pak lze ze vzdáleného počítače aktivovat FTP na IP-adresu svého osobního
počítače. Obvykle je takováto činnost již připravena na "klávese" Alt-T .
Proti zneužití zcela cizím uživatelem Internetu je tato funkce TELNETu
- v lepším případě - chráněna heslem měněným při jeho každém použití. Heslo
se uvede po zadání Alt-W ( viz například Help k TN3270:
Alt-H ). Při troše šikovnosti lze takto při aktivovaném TELNETu přenášet
z vedlejšího (druhého) osobního počítače třeba i data, která jsou uložena na C:
disku.
Proto je asi lepší hovořit raději při charakteristice Internetu o spolupráci programů na počátečním a cílovém počítači. Dvě typické funkce jsou však v Internetu vytvořeny tak, že téměř ilustrativně naplňují představu o spolupráci označovanou jako "klient-server", jsou to Gopher a WWW .
Toto příkladně je konkrétní odkaz na jedno menu Gopheru:
gopher://alfa.vse.cz/11/kizi/iksy/BEZ/ZAJIMAVE_PRIKLADY [11]Menu [1] - [9] klientem zpřístupňované uživateli vypadá nějak takto:
Gopher Menu
0Radeji prepnete "Caps Lock" ( na VELKE )T
0/kizi/iksy/BEZ/ZAJIMAVE_PRIKLADY/velke.bezTalfa.vse.czT 70
TSystem NOTIST T 132.236.240.20T23
TSystem LOCIST T 140.147.254.3T 23
1Anonymne pristupny LYNXT
1/kizi/iksy/BEZ/ZAJIMAVE_PRIKLADY/UFLT alfa.vse.czT 70
1Diskusni skupiny LISTSERVuT
1/kizi/iksy/ZAJIMAVE_PRIKLADY/LISTSERVerT alfa.vse.czT 70
1Knihovni sluzby v siti CESNET nebo SANETT
1/kizi/iksy/BEZ/ZAJIMAVE_PRIKLADY/LIB_CST alfa.vse.czT 70
0INTEROP Pocket GlossaryT
ftp:pub.vse.cz@/pub/docs/rfc/rfc1208.txtT gopher.zcu.czT 70
1Co chybi v Internetu - UFTT
1/kizi/iksy/ZAJIMAVE_PRIKLADY/UFTT alfa.vse.czT 70
1.. Ruzne ..T 1/kizi/iksy/BEZ/ZAJIMAVE_PRIKLADY/RUZNET alfa.vse.czT 70
.
Vysvětlivky:Před textem každého řádku menu je zpravidla umístěn ( v závislosti na použitém klientu ) jistý symbol vztahující se k typu této další možnosti.
Pro 1. a také pro 7. řádek ( typ 0 ) je to grafický symbol souboru či textově F: (FILE) . Přechod na další menu ( typ 1 ) symbolizuje ikona adresáře respektive D: (DIR) jako directory a někdy i jen / . Grafický symbol ve 2. a 3. řádku vyjadřuje přechod do telnetové seance ( typ 8 anebo T ), což se textově vyjadřuje jako T: (TEL) anebo (3270) .
Rozdíl mezi těmito dvěma variantami seance, které jsou definovány v Gopheru, tedy mezi TELNETem a TN3270 , je ve screenovém (celoobrazovkovém) přenosu typickém pro počítače IBM, které používají terminály typu 3270. Pokud je k dispozici TN3270, je přenos obvykle efektivnější i propojitelnost je často snazší, neboť uživatelé tuto možnost zpravidla využívají jen málo. To je případ i systému LOCIS - LIBRARY OF CONGRESS INFORMATION SYSTEM , k němuž přístup zajišťuje komunikační monitor CICS od IBM.Zároveň je vidět, že přenesený textový soubor, který se interpretuje jako menu, má na počátku každého řádku uváděn ( jako první znak ) typ , za nímž následuje příslušný text uváděný v menu. Pomocí tabulátoru ( řídící znak '09' ) jsou potom oddělovány další položky v řádku. Ty začínají připraveným požadavkem, jenž by klient odeslal na server. Jeho adresa a port jsou vždy uvedeny jako další položky. Tabulátor je symbolizován v uváděném příkladu znakem T , mezery následující za ním byly přidány kvůli lepší orientaci v údajích jednotlivých položek a v přenášeném souboru (menu) se ve skutečnosti neobjevují.
Všechny řádky jsou v přenášeném souboru ukončeny ( navzájem odděleny ) dvojicí znaků CR LF - Carriage Return ( '0D' ) a Line Feed ( '0A' ). Celý soubor menu je vždy zakončen ještě řádkem obsahujícím pouze . (tečku).
Takovéto krátkodobé vytváření přenosového kanálu je u Gopheru odlišné od
jiných (starších) funkcí Internetu, jako TELNET nebo též SMTP, kde je přenosový
kanál trvale vytvořen, a zpravidla z programu, kterým byl vytvořen, je také
posléze rušen ( příkazy: logout , quit ).
Takovou spolupráci klienta se serverem, jaká je typická pro Gopher, nazýváme
( viz již dříve ) nespojovanou programovou spoluprací anebo též
účelovou. Odlišně Gopheru je spolupráce třeba programů přenášejících
v Internetu dopisy podle protokolu SMTP spoluprací spojovanou
respektive trvalou.
Snad je ještě potřebné zdůraznit, že na spojovaný či nespojovaný
( v angličtině "non-persistence") způsob programové spolupráce
přitom pohlížíme z hlediska nejvyšší vrstvy v Internetu, vrstvy
internetovských funkcí. Z hlediska nižší vrstvy, transportní či TCP,
jde vždy o potvrzovaný způsob přenosu. Ten se v některých pramenech
( možná nevýstižně ) označuje slovy spojovaný přenos,
většinou proto, že až do rozmachu Gopheru byla nespojovaná (=účelová)
spolupráce obvykle realizována přenosem nepotvrzovaným
( protokolem UDP ).
Úvodní menu z Gopher-serveru klient získá tak, že jako požadavek odešle pouze prázdný řádek, lépe řečeno dvojici znaků CR LF , jíž má být každý požadavek ukončen. Ještě si všimněme, že každý jiný (další) požadavek pro získání menu začíná 1 . To serveru usnadňuje orientaci v jednotlivých souborech, neboť požadavek tohoto typu má na konci vždy uvedeno jméno adresáře. A z něj pak server bere jistý speciálně pojmenovaný soubor - řekněme .menu anebo .cache . Pokud požadavek začíná 0 , je na konci uváděno přímo jméno souboru ( nikoliv adresáře ). Rozdílných typů požadavků existuje ovšem ještě více.
Gopher má své RFC1436 [12], kde jsou předchozí věci podrobně popisovány. Typem odesílaného požadavku se pochopitelně také řídí klient, aby pak získaný soubor správným způsobem interpretoval. Uveďme alespoň nejčastější možnosti:
Type=0 textový soubor
Type=1 Menu
Type=7 přenos řetězce znaků od uživatele
Type=8 přechod na TELNET
Type=9 binární soubor
Type=T přechod na TN3270
Každý textový soubor a rovněž Menu je při přenosu zakončen řádkem obsahujícím
pouze tečku. Gopher-klient díky tomu pozná, zda soubor obdržel celý. Tímto
jednoduchým způsobem je dána klientu možnost, aby mohl ( podle toho, jak
dokonale byl naprogramován ) reagovat na chybnou situaci, kdy přenosový kanál
je již zrušen, ale soubor nebyl celý přenesen. - Pochopitelně se musí nějak
řešit situace, že v přenášeném textovém souboru se někde ocitla na řádku
pouze samotná tečka ( bez mezer ). V takovémto případě Gopher-server tečku
obvykle sám zdvojuje.
Zároveň se čtenář může přesvědčit, zda WWW-klient, pomocí něhož má
zpřístupněn tento text, při spolupráci s Gopher-serverem onu tečku na konci
textového souboru uživateli nezobrazuje. Mnozí klienti tak většinou činí.
Binární soubor není ukončován řádkem obsahujícím tečku, jinak je ovšem přenášen zcela shodně. To může při nevhodných přenosových poměrech pro větší soubory působit určité potíže. Pro klienta uzavření přenosového kanálu znamená konec přenášeného souboru. Velký soubor může Gopher-server předávat komponentě TCP po částech a při problémech se spojením se může přenosový kanál zrušit i vypršením určitého časového intervalu. Klient tak správně obdrží jen úvodní části celého souboru. Proto je zvykem při přenosu takovéhoto (důležitého) souboru uvádět pro uživatele v předchozím menu i velikost binárního souboru, kterou by si pak uživatel měl vždy překontrolovat.
Jednou z mála možností, kdy v Gopheru může uživatel dělat něco jiného než kliknout na řádek menu, je typ 7 . V tomto případě lze zadat krátký text, který klient odešle serveru a ten jej obvykle nějak dál zpracovává. Výsledkem může být například variantně vytvářené menu dalších odkazů, které server pak vrací klientu. Dokonce existovaly i instalace, kde bylo takto možno zadat z Gopheru rešeršní dotaz do (připojeného) informačního systému. Programová nadstavba na Gopher-serveru zajistila provedení dotazu v informačním systému a výsledek vrátila klientu jako textový soubor.
Přechod do režimu TELNET nebo TN3270 řešívá klient aktivací těchto funkcí (programů), což musí být v prostředí, kde klient pracuje, připraveno nezávisle na instalaci Gopher-klienta. Možnost přechodu do TELNETové seance, která byla zahrnuta do typů v Gopheru, ukazuje, že tvůrci Gopheru se snažili do něj integrovat i přístup k ostatním informačním zdrojům Internetu. To se daleko výrazněji projevilo posléze ve WWW.
Celkově je vidět, že koncepce Gopheru ( a stejně i WWW ) je orientována
souborově. Proto bylo nutné připustit i přechod do TELNETu, aby se bylo možno
bez složitých programových nadstaveb vyrovnat s přístupem do systémů
orientovaných například rekordově, jako jsou klasické informační systémy.
Zcela analogicky Gopheru je také souborově orientováno pojetí anonymního
přístupu k informacím přes FTP. Proto mohou existovat programové nadstavby
( ke Gopher-serveru ), pomocí nichž je možno v Gopheru uvádět odkaz i na soubor
anonymně přístupný přes FTP. Právě takováto situace je uvedena v 7. řádku
menu zmiňovaného výše. Gopher-klient zašle požadavek serveru na Západočeské
univerzitě, tam se přenese soubor rfc1208.txt z FTP-anonymous
na VŠE, aby byl následně ( z Plzně ) zaslán Gopher-klientu.
K tomu snad ještě jedna poznámka. Pro některé
alternativní
varianty přístupu [13] přes WWW-klienta lze takovýto požadavek na Gopher
rozpoznat jako přechod na FTP. I když ona situace nebyla standardizována,
získává pak WWW-klient soubor přímo z anonymního FTP.
Aktuálně je třeba doplnit, že zmiňovaná nadstavba ke Gopheru není takto
od začátku roku 2000 na Západočeské univerzitě již k dispozici.
Nejsnazší nakonec bylo tuto činnost nasimulovat na WWW-serveru, na nějž se
( až na odlišný port 80 ) může Gopher-klient obracet zcela stejně jako na
Gopher-server. I zmíněná alternativní variantu přístupu
byla přitom nasimulována, ale pouze
pro náhradní
přístup přes WWW [42] k
informacím umístěným na Gopheru.
Typicky je využíván tento přístup za situace, že nějaký správce
firewallu iniciativně někde (někomu) zakázal jakýkoliv přístup na port 70 .
Pro úplnost by bylo dobré uvést menu rozebírané výše ještě ve formě,
v jaké je definováno pro server ( správcem Gopheru ):
Name=Radeji prepnete "Caps Lock" ( na VELKE ) Type=0 Path=0/kizi/iksy/BEZ/ZAJIMAVE_PRIKLADY/velke.bez Host=alfa.vse.cz Port=70 Name=System NOTIS Type=T Host=132.236.240.20 Port=23 Name=System LOCIS Type=T Host=140.147.254.3 Port=23 Name=Anonymne pristupny LYNX Type=1 Path=1/kizi/iksy/BEZ/ZAJIMAVE_PRIKLADY/UFL Host=alfa.vse.cz Port=70 Name=Diskusni skupiny LISTSERVu Type=1 Path=1/kizi/iksy/ZAJIMAVE_PRIKLADY/LISTSERVer Host=alfa.vse.cz Port=70 Name=Knihovni sluzby v siti CESNET nebo SANET Type=1 Path=1/kizi/iksy/BEZ/ZAJIMAVE_PRIKLADY/LIB_CS Host=alfa.vse.cz Port=70 Name=INTEROP Pocket Glossary Type=0 Path=ftp:pub.vse.cz@/pub/docs/rfc/rfc1208.txt Host=gopher.zcu.cz Port=70 Name=Co chybi v Internetu - UFT Type=1 Path=1/kizi/iksy/ZAJIMAVE_PRIKLADY/UFT Host=alfa.vse.cz Port=70 Name=.. Ruzne .. Type=1 Path=1/kizi/iksy/BEZ/ZAJIMAVE_PRIKLADY/RUZNE Host=alfa.vse.cz Port=70
Odhlédneme-li od přehození řádků Name= a Type= ,
je za jednotlivými identifikátory uváděno přesně to, co Gopher-server zasílá
jako text s tabulátory při požadavku klienta na menu. ( Správce nemusí nutně
zadávat implicitní Port=70 a taktéž se implicitně doplní
neuvedené jméno počítače, v tomto případě Host=alfa.vse.cz ).
V takovémto tvaru se rovněž zadávaly požadavky na Gophermail , což
je způsob, jakým je možno získat soubory z Gopheru pomocí E-mailu - pouze
Host= přitom vždy musel být poslední parametr. Tento plně
vystihující způsob popisu je hlavně zajímavý tím, že pro Gopher vlastně
těchto pět parametrů zahrnuje dohromady HTML a URL , známé
později z WWW.
WWW ( World-Wide
Web ) úzce souvisí s těmito třemi pojmy:
HTML - Hypertext Markup Language , URL - Uniform Resource Locator(s) a HTTP - Hypertext Transfer Protocol
Právě na HTTP, jež popisuje spolupráci WWW-klienta s WWW-serverem, lze ilustrovat postupný rozvoj této internetovské funkce, který zároveň můžeme srovnávat s nám známým Gopherem.
Zcela analogicky předchozího například vypadá odkaz na WWW-stránku .. /kizi/information/ [14] takto [15]-[24] :
Index of /kizi/information
Name Last modified Size Description
Parent Directory 19-May-98 18:19 -
FAQ 07-Feb-95 14:57 7k
ASCII2.html 22-Sep-97 15:06 3k
INDEX 19-Sep-95 15:21 1k
Z WWW-serveru se přenese takovýto soubor, který jest v jazyce HTML :
<HEAD><TITLE>Index of /kizi/information </TITLE></HEAD><BODY>
<H1>Index of /kizi/information</H1>
<PRE><IMG SRC="downloader/0.gif" ALT=" "> Name Last modified Size Description
<HR>
<IMG SRC="downloader/1.gif" ALT="[DIR]"> <A HREF="/kizi/">Parent Directory</A> 19-May-98 18:19 -
<IMG SRC="downloader/2.gif" ALT="[TXT]"> <A HREF="FAQ">FAQ</A> 07-Feb-95 14:57 7k
<IMG SRC="downloader/2.gif" ALT="[TXT]"> <A HREF="IULP">IULP</A> 03-Oct-94 15:26 12k
<IMG SRC="downloader/2.gif" ALT="[TXT]"> <A HREF="http://alfa.vse.cz/kizi/ISIS+NET/BEZ/ZAJIMAVE_PRIKLADY/RUZNE/iksy">IKSy</A> 02-Nov-95 13:04 3k
<IMG SRC="downloader/3.gif" ALT="[HTM]"> <A HREF="ASCII2.html">ASCII2.html</A> 22-Sep-97 15:06 3k
<IMG SRC="downloader/2.gif" ALT="[TXT]"> <A HREF="libraries.602">libraries.602</A> 27-Oct-94 14:23 26k
<IMG SRC="downloader/2.gif" ALT="[TXT]"> <A HREF="cely.cdsthes.602">cdsthes.602</A> 31-Oct-94 17:52 70k
<IMG SRC="downloader/2.gif" ALT="[TXT]"> <A HREF="isis.paperback">isis.paperback</A> 02-Nov-94 13:02 1k
<IMG SRC="downloader/0.gif" ALT=" "> .. .. .. ..
<IMG SRC="downloader/4.gif" ALT="[ ]"> <A HREF="INDEX">INDEX</A> 19-Sep-95 15:21 1k
<IMG SRC="downloader/4.gif" ALT="[ ]"> <A HREF="DIR">DIR</A> 22-Sep-97 15:06 1k
</PRE></BODY>
Vysvětlivky:Tato stránka pro Index je část "profesionálně" psané WWW-stránky, kterou takto vygeneroval WWW-server ( když nenalezl soubor index.html ). Obrázky v ní použité jako text.gif , unknown.gif a pod. se musejí přenést rovněž z WWW-serveru. Klient si je musí postupně vyžádat podle obsahu uváděného HTML-souboru. Grafická podobnost této stránky, jak ji klient zobrazuje uživateli, s grafickým tvarem pro Gopher Menu je jednoznačně úmyslná.
Ještě snad poznámka, jak se výše uvedený (zdrojový) tvar HTML-souboru jeví při použití textového prohlížeče. Jeho řádky překračující délku zobrazitelnou na obrazovce ( nejčastěji 79 znaků ) pokračují vždy bezprostředně na řádku následujícím. Pro lepší čitelnost jejich obsahu byl za každý takovýto řádek (zde) přidán ještě jeden prázdný. ( Použitím ALT=" '0A' " ) V grafickém prohlížeči se takováto situace neobjeví. Jeden zcela prázdný řádek je přesně (nezbytnou) součástí HTML-souboru, a to kvůli použité specifikaci <PRE>.
Oproti jednoduchosti textového souboru, který Gopher přenášel kvůli Menu, jsou textové soubory, které se přenášejí ve WWW nejen větší, ale i složitější. Způsob jejich interpretace určuje jazyk HTML . WWW-klient podle něj vytváří konečný tvar výstupu předávaného uživateli. Pokud jeho součástí jsou kromě textu i obrázky ( a klient je umí zobrazit ), vyžádá si je podle odkazů úvodního HTML-textu a zakomponuje je do konečného výstupu uživateli.
Možnosti a varianty čím dál vyšších verzí jazyka HTML a analogicky tomu
i různě sofistikovaní WWW-klienti jsou často předmětem nejzasvěcenějších
diskusí týkajících se sítě Internet. Princip jazyka HTML se ale dá velmi
stručně shrnout asi takto:
V jazyce HTML se příkazy určující způsob formátování zapisují do "závorek"
< ... > ,
vně těchto závorek je text onoho dokumentu, jenž WWW-klient naformátuje
uživateli na obrazovku. Přitom za normálních okolností ( pokud tedy například
nebyl předem použit příkaz <PRE> )
se jednotlivá slova vždy umisťují bezprostředně s (jednou) mezerou za sebou,
až kolik se jich vejde na jeden řádek. ( Pokud samozřejmě není některé slovo
delší než celý řádek.) "Normálně" dlouhá slova se na konci řádku nerozdělují,
ale začínají na novém řádku. Ve zdrojovém textu, který klient získal
z WWW-serveru, se za jednotlivá slova pokládají řetězce znaků oddělené
mezerou ( anebo více mezerami po sobě ) anebo též koncem řádku. Většina
grafických klientů přitom s výhodou využívá i pohlednějšího proporcionálního
písma pro formátování obrazovky.
Z tohoto je zřejmé, že pokud má v textu naformátovaném klientem někde začínat
nový řádek nebo odstavec, musí to být explicitně zadáno pomocí příkazů
<BR> nebo
<P> .
Všímavý čtenář, který čte tento text přes WWW-klienta, si jistě uvědomil,
že <BR> a <P> nemohou být ve zdrojovém textu takto zapsány, neboť
by se pak takto v naformátovaném textu neobjevily. Ve zdrojovém textu totiž
musí být uváděna místo "levé závorky" ( znak menší <
) speciální posloupnost znaků <
( zkratka z "less than") a místo "pravé závorky"
> pak >
( "greater than" ). Nakonec ale ani < a >
není možno takto ve zdrojovém textu napsat, namísto &
je třeba uvést & .
Tedy < se ve zdrojovém textu zapíše jako &lt;
a právě toto pak jako &amp;lt; - dále již pokračovat
nebudeme. Pro úplnost ale uveďme ještě syntakticky potřebnou posloupnost
" pro " (uvozovky)
, například pro možnost specifikace: ALT=" ..".. " .
Problém, jak bývá obvyklé, je někdy s koncem řádku ve zdrojovém textu, jakožto oddělovačem slov. RFC1866 [25] říká, že by klient měl respektovat kteroukoliv ze tří možností: '0A' nebo '0D' '0A' nebo '0D' . Ve skutečnosti vždy správně asi všichni klienti reagují jen na první variantu, typickou pro oddělování řádků v systému Unix, tedy použití pouze znaku LF = '0A' . Možná proto, že nejčastěji jsou WWW-servery provozovány na počítačích pracujících v systému Unix. Dokonce i WWW-klienti pro MS-DOSové prostředí, v němž je typicky konec řádku dvouznakový CR LF ( = '0D' '0A' ), mají buď zásadní potíže právě s takovýmto koncem řádků zdrojového textu, jako DOSLYNX, anebo jej někdy správně interpretují až napodruhé ( Arachne ). Snad proto, že je programově snazší nějak zpracovat vždy znak na jeden byte než ošetřit najednou dva byty zakončující řádek.
Příkazy nebo lépe řečeno specifikace jazyka HTML vždy začínají specifickým
slovem hned za "závorkou", tedy :
<slovo ... > . Podle
svého významu a povahy specifikace jsou buď jednorázové ( jako třeba
specifikace nového odstavce ) anebo platí až do odvolání. Pak se platnost
ukončuje pomocí
</slovo ... > .
Kromě již výše zmiňovaných
<BR> a
<P> je jednorázovou
specifikací třeba <HR> , specifikace
pro umístění (horizontální) čáry. A obdobně též specifikace umístění
obrázku, jejíž tvar je možno (stručně) vyjádřit takto:
<IMG SRC=odkaz ALT="text"> .
Přitom odkaz vyjadřuje místo, odkud WWW-klient musí
získat soubor, jenž je obrázkem. Pokud WWW-klient není schopen obrázek
zobrazit, uvede místo něj text , tak jak je naplněn
v atributu ALT= .
Specifikace <IMG ... > může kromě SRC= a ALT= obsahovat
ještě další atributy, které mohou upřesňovat způsob umístění obrázku při tvorbě
konečného výstupu. Tak například ALIGN= určuje jeho umístění
vzhledem k ostatnímu (řádkovému) textu. Text sousedící s obrázkem je vůči němu
(podle angličtiny): BOTTOM , MIDDLE ,
TOP , v dalších verzích jazyka HTML pak bylo možno zadat
kromě LEFT také RIGHT určující
umístění vůči celkovému formátování textu. Potom je také možno používat atributy
určující rozměry při formátovaných obrázků.
WIDTH=Phoriz určuje horizontální velikost
obrázku a HEIGHT=Pvert jeho rozměr
vertikální. Rozměry jsou zadávány počtem obrazových prvků neboli bodů ("pixelů").
Ještě snad je zajímavý atribut BORDER= . Ten vyjadřuje tloušťku
ohraničení obrázku. Klient obrázek obvykle sám nějak ohraničí, pokud je na něm
umístěn odkaz, tedy pokud lze na tento obrázek kliknout. Tímto atributem lze
pro tloušťku ohraničující čáry stanovit jiný počet obrazových prvků než bývá
klientem implicitně používané 1 či 2 . BORDER=0 tak znamená, že
ohraničující čára bude všude nulová (žádná).
Větší část specifikací v jazyce HTML platí až "do odvolání". Tak je tomu i
pro nejpodstatnější specifikaci ve WWW, kterou je hypertextový odkaz.
Zadává se takto:
<A HREF=odkaz> .. další zdrojový text .. </A>
Jako "další zdrojový text" je obvykle uvedeno
jedno slovo anebo kratší sousloví, ale může to být třeba celý odstavec anebo
i právě zmíněná specifikace obrázku. A stejným způsobem jako u obrázku se
uvádí "odkaz" i zde, a to podle pravidel pro URI
- Uniform Resource
Identifier
( viz blíže RFC2396
[26] ).
V podstatě to znamená, že do odkazu se zapisuje jméno dalšího (odkazovaného)
souboru případně i cesta, která k němu vede, je-li uložen v jiném adresáři.
Odkázat lze ale i na soubor na úplně jiném počítači a ten dokonce může být
přístupný i jinak než přes WWW-server. Potom je nutno v odkazu uvést:
funkci, počítač a celou cestu k souboru ( včetně jeho
jména ). Takovýto univerzální způsob popisu souborů přístupných v Internetu,
jenž se ve WWW objevil, je asi nejvýznamnějším přínosem pro celý Internet.
A odtud se také odvíjí
URL
[27], bez kterého si už nelze
představit třeba ani vizitky mnohých pracovníků. Zajímavé přitom je, že původně se
( v RFC1630
[28] )
hovořilo o Universal Resource Identifiers.
Odkazy mají zpravidla takovou syntaxi, že WWW-klient je bez problémů schopen
zjistit hodnotu atributu. Přesto má být i tato hodnota správně zapsána do
uvozovek ( anebo do apostrofů ). Takto jsou odkazy též uvedeny ve shora
zmíněném konkrétním příkladě zdrojového HTML-textu.
Většina specifikací platících do odvolání se týká typů písma, způsobu
zarovnání či rozmístění textu na obrazovce. Příkladně:
<I> text zobrazovaný kurzívou </I>
<STRONG> text zobrazovaný tučným písmem </STRONG>
<BLOCKQUOTE> odsazovaný odstavec textu </BLOCKQUOTE>
<CENTER> ve vyšších verzích text při formátování centrovaný </CENTER>
<FONT SIZE=j> ve verzích novějších stanovitelná velikost písma </FONT>
Zvláštní postavení má při formátování výstupu specifikace <PRE> . WWW-klient má používat neproporcionální písmo a zároveň respektovat počty všech mezer ( vně závorek ) a přesně dodržet i konce řádků tak, jak byly uvedeny ve zdrojovém textu - a to až do nalezení </PRE> . Zároveň je to asi nejrychleší způsob, jak vytvořit HTML-stránku z textového souboru, zvláště když má obsahovat sloupce či tabulky.
Jiný způsob, který by respektoval původní grafický tvar textu, je v jazyce HTML
mnohem komplikovanější, neboť vybočuje z původní představy spojitě plynoucího
textu. V prvních verzích jazyka HTML byla takováto situace někdy těžko řešitelná,
což se týká i verze 2.0 popisované v již zmiňovaném RFC-dokumentu
1866 [25].
Popsaná situace se nejčastěji řeší použitím tabulek ( s nulovým ohraničením ), které se
ovšem objevují až ve verzi 3.0 . Mezi RFC-dokumenty se jen k tomu
ale objevilo samostané RFC1942 [29].
Obdobně také RFC1980 [30]
rozšiřuje možnosti verze 2.0 , a to o použití atributu USEMAP=
ve specifikaci <IMG ... > . To dává WWW-klientu
možnost, aby mohl sám zprostředkovávat rozdílné odkazy skrývající se pod jedním
obrázkem podle toho, na jakou jeho část uživatel kliknul. Této možnosti se dá i
využít ke snížení přenosové náročnosti graficky bohatých WWW-stránek, kde lze
mnohdy kliknout na celou řadu významových obrázků. Nahrazení jedním obrázkem
s více odkazy snižuje dobu konverzace klienta (se serverem) i práci potřebnou
k formátování výstupu.
S postupným rozšiřováním možností WWW-klientů a jejich schopnostmi zprostředkovat
uživateli i soubory získané pomocí jiných internetových funkcí nemusejí nutně
být všechny zdrojové texty interpretovány pomocí jazyka HTML. Pro odstranění
případných problémů a nejasností na straně WWW-klienta má mít zdrojový
HTML-soubor takovouto strukturu:
<HTML>Všechny dosud popisované možnosti se týkají hlavní části označené jako <BODY> . Naproti tomu do části <HEAD> se kromě nepříliš funkčně podstatného <TITLE> název WWW-stránky </TITLE> umísťují informace související především s přenosem souboru:
<HEAD> ... </HEAD>
<BODY> zdrojový text </BODY>
</HTML>
Nejrozšířenějším případem je u nás situace na Unixu ( s WWW-serverem
Apache ), kde uživateli stačí založit si "u sebe" adresář
public_html . Jedině je v Unixu potřebné, aby tento adresář
a soubory v něm byly přístupné ke čtení i pro programy WWW-serveru. ( K tomu
obvykle bývá potřeba explicitně povolit WWW-serveru i přístup do adresáře
/home/user-name/ .) O souborech z tohoto adresáře se pak hovoří
jako o uživatelské home-stránce, kterou WWW-server zná ( z nejvyšší úrovně )
jako podadresář .. /~user-name .
Analogicky lze nyní i na LAN-ových serverech, kde je provozován WWW-server,
vytvářet často vlastní home-stránky. Příkladně jako na Novellovských
serverech nb.vse.cz [31]
a st.vse.cz [32] ,
přitom bývá potřeba založit si ( na síťovém disku ) adresář pojmenovaný jako
PUBLIC.WWW . Takovýto adresář
( se souborem index.htm ) by se měl - obvykle automaticky
přes noc - zpřístupnit
do sítě Internet. Na NB je uživatelská stránka adresovatelná zcela
analogicky jako v popsaném případě na Unixu, na ST bývalo ještě
potřeba uživatelské jméno rozšířit o sufix podle fakulty:
~user-name.fakn . Podrobnější informace
lze k tomu najít v hlavních WWW-stránkách obou serverů.
Takovéto vlastní WWW-stránky uživatelé převážně využívají ke své osobní
prezentaci v Internetu. Jedna z možností však bývá používána jen sporadicky,
a tou je předání nějakého souboru, jenž není zcela veřejný, jinému uživateli.
V Internetu je k přenosu souborů určen příkaz FTP, pro jehož využití by bylo
potřeba, aby některý ze zainteresovaných uživatelů druhému sdělil své heslo.
E-mail je koncipován pro přenos kratších textových souborů, a tak se při
předávání většího binárního souboru druhému uživateli mohou objevit problémy
ve zvoleném způsobu zakódování či se samotnou velikostí dopisu. Předávaný
soubor či soubory může ovšem uživatel umístit (překopírovat) někam do adresáře,
v němž je jeho home-stránka. Pokud na soubor nebude uveden odkaz na některé
WWW-stránce ( například tedy v index.htm ), je ( při šikovně
zvoleném jménu ) pro ostatní uživatele v síti Internet chráněn na srovnatelné
úrovni, jako jsou běžně používaná přístupová hesla. Druhému uživateli lze
přesnou cestu a jméno souboru sdělit i pomocí E-mailu, aby jej byl schopen
získat přes WWW-server ( pomocí protokolu http ). V nejhorším případě se tak
cizí uživatelé mohou dostat jen do některých neveřejných podadresářů na
vlastní home-stránce. S tím je raději lepší předem pro jistotu počítat.
Zajímavou situaci je možno vypozorovat při přístupu na uživatelské home-stránky. Ty jsou zpravidla napsány mnohem pečlivěji než oficiální WWW-stránky vytvářené správci WWW-serverů, s čímž mnohdy souvisí i špatná čitelnost pro textové klienty anebo pro (grafické) klienty starších verzí. Jedním z důvodů je možná i skutečnost, že "soukromý" uživatel své vlastní stránky postupně odladí tak, jak mu jeho známí používající různé typy a verze WWW-klientů sdělují, která místa jim jejich klient nesprávně interpretoval. Naproti tomu "profesionálové" takto ke své tvorbě nepřistupují. Typickým příkladem poněkud zvláštního způsobu ladění zdrojového textu jsou informace typu: "Tato stránka je optimalizována pro takovýto typ klienta. - Stáhnout si ho můžete zde." A tak uživatel amatér by asi měl začít stahovat ze sítě určeného WWW-klienta ( a třeba shánět i odpovídající operační systém ) a také si ho správně nakonfigurovat. Daleko rychlejší pochopitelně je si někam uložit zdrojový text a opravit ho tak, aby informace byly alespoň čitelné. Vzniká potom otázka, čím se v takovýchto poměrech liší profesionální WWW-stránky od stránek amatérských. No přece tím, zda za ně tvůrce dostal od někoho zaplaceno.
V čem spočívají některé (syntaktické) nepečlivosti při psaní WWW-stránek ? Tak například pro specifikace jazyka HTML by mělo být jedno, zda jsou uvedeny v malých nebo velkých písmenech. Některým klientům však může vadit, je-li platnost specifikace <slovo...> ukončena v druhém fontu, jako </SLOVO> . Samozřejmě je také nesprávné použít uprostřed textu samotný znak > , přestože s tímto jsou klienti většinou schopni se úspěšně vyrovnat. Pro některé klienty může být dokonce problémem i nesprávné "závorkování" při otevírání a ukončení definovaných fontů. Například zadáme-li tučnou kurzívu jako: <STRONG><I> , měla by být ukončena </I></STRONG> . ( A nikoliv jako </STRONG></I> .)
Odhlédneme-li spíše od takovýchto detailů v syntaxi jazyka HTML, je celkově tvorba WWW-stránek v podstatě vždy kompromisem mezi dvěma požadavky:
Ve světě ( na rozdíl od nás ) se v tomto směru od důležitých WWW-stránek dají využívat i jejich textové verze. Nejsou určeny jen pro textové WWW-klienty, ale jsou napsány tak, aby i v nižších verzích grafických klientů byly poskytnuty uživateli všechny potřebné informace, především ale je minimalizováno přenášení těch obrázků, které pro uživatele mají prakticky nulovou informační hodnotu.
Na to se dá namítnout, že uživatel sám buď může použít textového WWW-klienta,
anebo si zvolit při práci s grafickým klientem režim bez přenosu obrázků.
Nehledě k tomu, že výsledek většinou nevypadá zdaleka tak pěkně a přehledně,
opět takovýto přístup odráží zájem a vztah tvůrce WWW-stránek ke koncovému
uživateli ( na tom nejstarším počítači někde na nejzastrčenější lince
Internetu ). Konec konců pro příklad nemusíme u nás chodit nikam daleko.
Stačí se přes textového klienta podívat na
WWW-přístup [33] do knihovního
katalogu VŠE. Najít místo, kde se skrývá Help , lze asi jedině
ze zdrojového textu, v němž je uváděn požadavek na přenos obrázku jména
help.gif [34].
( Ve specifikaci obrázku není totiž uveden atribut
ALT= , což možný odkaz zcela znepřehledňuje nejen při použití
textových WWW-klientů, ale i nové verze grafických klientů nemohou po
umístění myši na tento obrázek uvést jeho vysvětlující text. Jsou-li grafické
významy i ostatních obrázků málo zřejmé, může pak uživatel myší bloudit po
obrazovce, jako by osvobozoval princeznu ve hře pro děti. Na takovouto činnost
jsou v Internetu spíše zaměřeny jiné servery. )
Dobře navržené WWW-servery mají alespoň úvodní stránky vytvořeny tak, aby byly úspěšně čitelné pro většinu ( i koncepčně rozdílných ) klientů. To minimálně předpokládá, že tvůrce stránku doladil nejméně pro dva různé klienty. ( Čímž nejsou zrovna myšleny Netscape a Internet Explorer , které oba koncepčně pokračují v pojetí jednoho z prvních grafických klientů, kterým byl Mosaic od NCSA [35].)
Někdy je přitom obtížné přesně vědět, které specifikace jsou možné v určité variantě HTML-jazyka, podle níž by měl ten který klient pracovat. Jak již bylo řečeno výše, RFC-dokumenty se dosud zmiňují pouze o verzi 2.0 s několika dodatky. Existující varianty spolu s dalšími aktuálními odkazy jsou přehledně uváděny třeba v Helpu [36] textového prohlížeče Lynx. Učit se psát WWW-stránky podle těchto referenčních odkazů je ale dosti obtížně. Nejrychlejší cesta ( tak jako asi i u jiných programovacích jazyků ) vede přes opisování. Což je u WWW-stránek velmi jednoduché, neboť zdrojový text se vždy dostává až ke klientovi. ( K takovému způsobu učení byla u nás většina těch uživatelů, kteří nesnášejí nedokonalosti, nakonec přinucena, když se rychle snažili pro svého klienta opravit nějaké zajímavé WWW-stránky.)
Vývoj možností jazyka HTML stále pokračuje především obohacováním grafického
tvaru výstupů ( viz třeba
"frames" [37]
ve verzi 4.0 - možnost dělit obrazovku na rámce, anebo například
účelově pojímané výstupy matematických symbolů od
verze 3.0 [38] až
k novému návrhu jazyka MathML [39] ).
Pro algoritmické usnadnění tvorby WWW-stránek by bylo spíše účelnější rozšiřovat
syntaxi HTML například v duchu některého formátovacího jazyka používaného
pro tvorbu výstupů z rešeršního systému. Třeba konkrétně, mít možnost využít
podmínku if podle situace dosažené právě při formátování předchozí
části zdrojového textu.
Tím se myslí něco jiného, než co v současnosti umožňují často již používané Java-scripty. Jejich hlavní myšlenka je založen na využití počítačových kapacit v době, kdy uživatel sedí u obrazovky a pročítá si získaný dokument. V této době může na počítači pracovat program, který buď po určitém časovém intervalu, anebo při určité akci uživatele, třeba při pohybu myší, vykonává sám další činnosti. Od vysvětlujících upozornění až třeba po samostatnou aktivaci dalšího ( velmi často reklamního ) přenosu. A tím se mnohdy dociluje rovněž animace na získaných WWW-stránkách.
HTML-jazyk
verze 4.0 [40]
hovoří o možnosti takovéto specifikace scriptů v různých jazycích:
<SCRIPT type="text/jazyk">
příkazy (jazyka)
</slovo>
Program vždy nemusí ve zdrojovém textu následovat bezprostředně za specifikací scriptu. Ta totiž může obsahovat ( analogicky specifikace obrázku ) atribut SRC=odkaz na místo, odkud jej lze získat. V každém případě se ovšem musí platnost specifikace zakončit, což zde učiní (netypicky) jakákoliv ukončující sekvence </... > .
Nejčastěji se lze ve WWW-stránkách setkat s programy, kde jazykem je javascript.
A to především pro jeho implementaci ve vyšších verzích prohlížečů
Netscape a Internet Explorer. Scripty jsou obvykle specifikovány "nedoporučovaným"
způsobem jako:
<SCRIPT LANGUAGE="javascript">
příkazy javascriptu
</SCRIPT>
Jak bývá obvyklé, mohou i Java-scripty být různých verzí. Nesprávné interpretace
anebo chyby, které se tak mohou na straně klienta objevit, někdy výrazným
způsobem prodlužují přenos WWW-stránek či využití dalších jejich odkazů.
S určitou nadsázkou je možno říci, že nejefektivnější spolupráce s WWW-serverem
je mnohdy pomocí klienta, který Java-scripty vůbec neumí. Při využití ve
vlastních WWW-stránkách bývá proto dobré použít (některou)
knihovnu
připravených Java-scriptů [41].
