Jak opravit neopravitelné
Každý se s tím již někdy setkal. Na Vašem počítači, ve Vaší konfiguraci něco nejde, nefunguje anebo se alespoň špatně zobrazí. Většinou se člověk obrátí na některého správce systému. Nejhorší (někdy i nejčastější) odpověď, kterou se člověk dozví, je typu: "Na tak zastaralém počítači a v tak staré verzi programového vybavení Vám nic nemůže fungovat!". Nejhorší je, když se vše týká nějakého souboru na WWW-serveru. To pak můžete argumentovat třeba pěti RFC-dokumenty, že takto by soubor nikdy neměl být WWW-serverem poskytován, ale obvykle je Vám to málo platné. Mě jednou dokonce jeden správce serveru zval, abych se přišel k němu podívat, že on to na svém počítači má dobře, zprostředkované samozřejmě tím klientem, kterého on jedině používá. A pokud mně to v něčem jiném nefunguje, tak abych to přestal používat. Mé odkazy na standardy Internetu byly jen přitěžující okolností.
Je pravda, že jednou jedinkrát jsem správce WWW-serveru přiměl, aby věc opravil. Jeho WWW-server totiž zasílal soubor ve Wordu se specifikací text/plain v http-hlavičce (předávané každým WWW-serverem vždy před začátkem souboru). Ale došlo k tomu až po několika týdnech, když jsem si vybral jeden soubor ve Wordu, což byla nějaká studie o vlivu na životní prostředí, a já se začal vydávat za ochránce životního prostředí s tím, že soubor je snad schválně předáván s chybnou http-hlavičkou, aby si ho nemohli všichni tak snadno přečíst. Ona oprava vázaná na změnu jednoho řádku v konfiguračním soubor WWW-serveru pracujícího pod Unixem, kde zrovna soubory s koncovkou .doc nejsou nijak významné, vydržela jen do nejbližšího upgrade(u) WWW-serveru. Zrovna v ní se totiž místo do tří konfiguračních souborů začaly všechny parametry psát jen do jednoho. A tak již nikdo nevěděl, co by se mělo opět opravit. Snad jedině až budou časem zase něco stavět - a vypracují k tomu zase studii o vlivu na životní prostředí.
Možná na samostatnou knihu by vystačily problémy s českou diakritikou, nepoužíváte-li z nějakého důvodu zrovna kód češtiny Windows-1250. V poslední době se ovšem začínají objevovat problémy i při přístupu do knihovních systémů, které kdysi bývaly velmi odolné vůči jakémukoliv typu klienta. Jaké je pak řešení? Každý si po večerech musí někde sehnat nebo sám vytvořit WWW-klienta, který by mohl být aktivován na nějakém WWW-serveru, třeba i na vlastní WWW-stránce. Prostě takový malý osobní proxy-server. Nevyhovuje Vám kód češtiny, vadí Vám, že nemáte třeba do kódu ISO-8859-2 převedenu z Windows-1250 "trojtečku" (hexadecimálně `85`) na tři obyčejné tečky. Toto si snadno sami opravíte na svém "osobním proxy-serveru". A není sebemenšího důvodu, proč byste místo jednoho znaku nemohli současně opravit třeba celou řádku, kde její tvůrce omylem podruhé uvedl <body> (protože zrovna jeho WWW-klientovi to nevadilo).
Tato poněkud absurdní představa však není ani zdaleka tak nereálná. Volně se na Internetu dají nalézt skripty, které při aktivaci na WWW-serveru sami stáhnou WWW-stránku a tu Vám teprve poté předají. V jazyce php se lze podívat třeba na www.phpwizard.net/header, kde jsou barevně u Helpu napsány příkazy pro získání informace z WWW-serveru. (Místo HEAD je třeba použít ve skriptu GET.) Jedna snazší možnost je však poměrně velmi málo využívaná. Jak je napsáno v FAQ (v často kladených otázkách) k Perlu, viz man perlfaq9:
How do I fetch an HTML file?
One approach, if you have the lynx text-based HTML
browser installed on your system, is this:
$html_code = `lynx -source $url`;
$text_data = `lynx -dump $url`;
Princip je vlastně jednoduchý: v nějakém skriptu (na WWW-serveru) si zavoláme Lynx, kterému jsme předem specifikovali úplné URL, a získaný obsah v proměnné html_code drobně opravíme (než z něj "printem" vytvoříme novou WWW-stránku).
Jednou při opravě použijeme podle SaCzech-ových skriptů operaci translate, čímž se asi nejsnáze dají překódovávat znaky z jednoho kódu češtiny do jiného. (Tabulku kódování si musíme pochopitelně doplnit o převod třeba dolních uvozovek na normální, a nebo i o převod nečeských znaků - těmi se u nás v konverzním programu asi dosud nikdo hlouběji nezabýval.)
Jindy při opravě použijeme operaci replace, kterou lze nahradit jeden vybraný řetězec jiným řetězcem znaků. Tak třeba ono druhé <body...> nahradíme prázdným řetězcem znaků, anebo jeden znak trojtečky (`85`) nahradíme třemi normálními tečkami. Anebo také nezměníme vůbec nic, jen http-hlavička našeho skriptu bude místo text/plain uvádět application/msword.
Jak vývoj pokračoval, WWW-klient Lynx se postupně zdokonaloval. V poslední době především směrem ke zpracování WWW-stránek, které mohou být i ve velmi rozdílných jazykových kódech. Zdrojový kód WWW-stránky může být také jiný než kód, ve kterém bude stránka zobrazována. Pro nás je podstatné, že současný Lynx zná kódy ISO-8859-2, CP852, Windows-1250, ale zná také UTF-8, ve kterém můžeme současně používat znaky ze všech předchozích kódů, tedy například onu trojtečku, uvozovky dole, ale i rámečky a pozadí typické pro češtinu CP852 v MS-DOSu. Dokonce může být tento kód použit i pro výsledné zobrazení stránky. Navíc lze stránku zobrazit též v ASCII-1, buď zcela bez diakritických znamének, eventuálně i pomocí jejich mnemotechnického předpisu (například jako a`, c<, u0, jež znamenají á, č, ů). Lynx prostě lze tak využít i jako konvertor mezi různými kódy. Co je třeba zdůraznit, konverzní tabulky v něm zabudované jsou takové, že navzájem převádějí všechny korespondující si znaky. Tedy nikoliv jen česká písmena s diakritikou, jak je obvyklé ve většině konverzních programů používaných u nás na WWW-serverech. Pokud nějaký znak nemá svou interpretaci v novém kódu, není z konverze vynechán, ale je mnemotechnicky nějak nahrazen. Konečně tedy někdo za nás vyřešil úplnou konverzi kódových tabulek češtiny! - Jedině snad s výjimkou kódu Kamenický, jenž ovšem nebyl řádně (v Internetu) standardizován.
Používáme-li tedy ve skriptu pro získání WWW-stránky Lynx, lze pomocí něj i stránku konvertovat do jiného kódu, třeba do UTF-8. Takto je třeba na WWW-serveru konvertována (do UTF-8) stránka o UTF-8.
Jediným problémem při realizaci bylo, že v "batchovém režimu" Lynx provádí konverzi pouze při parametru -dump a naopak pro -source není získaný text vůbec nijak měněn. To je sice výhodné pro "opravu" http-hlavičky v nesprávně zasílaných souborech Wordu, ale pro překódování do UTF-8 by bylo potřeba nejprve změnit nějak správné text/html na "nesprávné" text/plain (a pak použít lynx -dump). Tuto změnu lze vyřešit zcela analogickým způsobem jako situaci pro soubory ve Wordu. Pouze místo na originální WWW-server se bude lynx -dump obracet na další náš skript, který onu WWW-stránku předává jako textový soubor. Způsob konverze je pak určen parametry v konfiguračním souboru, který Lynx použil.
Je relativně jednoduché, pokud používáme takovýto skript anebo skripty jen sami pro sebe, a to ještě na pevně určené WWW-stránky. Problémem přitom mohou být další odkazy na opravené WWW-stránce, které bychom možná také chtěli hned mít opravené, anebo samotné získání obrázků do opravených WWW-stránek.
Konkrétně zde zmíněný skript UIW, který převádí WWW-stránky do UTF-8, umí překódovávat stránky z libovolného WWW-serveru. Kód originální stránky skript předpokládá jako ISO-8859-2, ale úspěšně převede i české znaky z Windows-1250, konkrétně tedy ž, š, ť, jejichž umístěním (naštěstí pro češtinu disjunktním) se kódy liší. Převádí tedy pseudo-kód "ISO-Latin-1250" do UTF-8. (Toto rozšíření je realizováno operací translate již v pomocném skriptu, který stránku jako textový soubor předává Lynxu ke kódové konverzi.) Problémy správného získávání obrázků řeší skript tak, že ony odkazy ponechává nezměněné na server původní. Pokud přesto nějak směřují na server s oním konverzním skriptem, přesměruje skript všechny snahy o získání obrázku (pomocí jím vytvářené odpovědi serveru 301 Moved permanently) na originální WWW-server. Obdobně, jako se to dělalo už v SaCzech-ových skriptech. Odkazy uváděné na stránce pomocí <A HREF=...>, a to na stejný WWW-server, na kterém je ona konvertovaná stránka, se snaží opravit tak, aby i ty se při kliknutí konvertovaly stejným způsobem. (Nevyrovná se ale úspěšně třeba se všemi způsoby odkazů vytvořenými pomocí Java-skriptů a neumí zpracovávat odpovědi klienta metodou POST.)
Druhým problémem skriptů, které nepoužíváme jen sami pro sebe a z místa známého jen nám, je pak ochrana proti úmyslnému zneužití parametru předaného programu Lynx, a to k dalším funkcím, které by byl případně skript schopen vykonávat na WWW-serveru. Základ to veškeré práce serverových hackerů. Zde mnohdy platí, že často ty nejjednodušší změny oproti standardnímu návodu (třeba z Helpu) bývají ty nejúčinnější. Asi jako to, že i krátké heslo je mnohdy těžko překonatelná překážka. (Ovšem nesmí nikdo začít tušit, že si pravidelně dáváme jako heslo třeba rok anebo den narození.) Mnohdy totiž hackeři používají standardní triky a postupy, které za ně často provádějí programy, některé dokonce i volně získatelné z Internetu. A ty zpravidla nepočítají s úplnými trivialitami a hloupostmi.
Oproti překódovávacím skriptům, ať již definujeme vlastní transformační tabulku anebo musíme správně definovat konfigurační soubor pro Lynx, je realizace opravy pro nevyhovující (statickou) WWW-stránku méně složitá. Ve zdrojovém HTML-textu oné stránky nejprve vyhledáme místo, které nám z nějakého důvodu pro určitého klienta nevyhovuje. (Česky řečeno, stránku za tvůrce doladíme i pro jiného WWW-klienta, než kterého používal on.) Ve velké většině případů se jedná o jedno kratší místo, kde zpravidla bývá použita nějak nestandardní syntaxe, kterou jen určitá verze IE případně Netscapu je schopna správně překonat.) Vybereme z onoho místa nějaký (trochu delší) řetězec znaků, který bude vstupem pro operaci replace. Jejím výstupem bude řetězec začínající i končící ve stejných místech zdrojového text, ale s vnesenou opravou. Obvykle se řetězec včetně mezer a konců řádek dá snadno najít takový, že jeho opakování v jiném místě textu nebo na jiné WWW-stránce je málo pravděpodobné. Tak je možno opravu jednoduše realizovat "bezhlavou" záměnou zrovna takovéhoto řetězce v každé stránce získané skriptem. Dá se tedy (třeba po omezenou dobu) přidat i do skriptu vykonávajícího pro nás jinou činnost, například zmiňovaný převod do jiného kódu češtiny. (O jisté záludnosti takovýchto změn pro nezasvěceného uživatele je zmínka ještě dále.)
A tímto způsobem lze přistupovat i k situaci, že třeba knihovní systém (nově) předpokládá, a to zpravidla v úvodní WWW-stránce, že se nějakým způsobem přiděluje identifikační označení. Uživatele přistupujícího k systému pomocí WWW-klienta pak totiž informační systém může obsluhovat obdobně jako TELNETovou seanci, při níž je vždy schopen například vědět, jaké rešeršní dotazy uživatel prováděl. Pod WWW pak ono identifikační označení systém obvykle udržuje po určitý (trochu delší) časový interval, neboť v "trvale nespojovaném" prostředí WWW se nedá přesně zjistit, kdy uživatel přestal pracovat. (Některé systémy proto uživatele prosí, aby při ukončení práce klikl na WWW-stránce na "exit".) Takovéto systémy nabízejí sice uživateli při WWW-přístupu lepší možnosti, jako například textové filtrování záznamů získaných v předcházející rešerši, ale obvykle již nejde, aby uživatel někde na své WWW-stránce měl třeba u citace odkaz na určitou knihu (nebo knihy), které jsou k dispozici v knihovně. Odkaz by pak asi musel být s vysvětlením, že po kliknutí se ve formuláři nejprve vyplní to a to. Ale i toto by přece mohl být WWW-klient sám schopen učinit třeba pomocí REFRESH.
Odkaz na citované knihy tedy nemusíme směrovat přímo na WWW-stránky knihovního systému, ale opět na náš "osobní skript". Ten nějak získá WWW-stránku s formulářem a přitom se nějak přidělí potřebné identifikační označení, stránku skript poopraví tak, jak by do ní měl uživatel vyplnit dotaz na onen pramen, a takovouto stránku předá jako odpověď. Ovšem s tím, že do úvodu přidal specifikaci <META ..="REFRESH" CONTENT="1; URL=...">. WWW-klient si má onu stránku z místa URL= sám vyžádat. Zmiňovaný skript buď může pouze převzít identifikační označení, tak jak je již přidělil originální WWW-server, a to již potom bude součástí onoho URL. Nebo pokud knihovní systém požaduje, aby si identifikaci WWW-klient sám nějak dopočítával (třeba jako náhodné číslo), a kdyby právě to některý klient neuměl, lze to zpravidla programovými prostředky používanými pro skript snadno zrealizovat. A tím lze zároveň překonat i problém, že přístup do některého systému nutně vyžaduje klienta, který zná Java-skripty (a rámce).
Takto je například realizován odkaz nyní do nového systému Aleph v Národní knihovně http://146.102.64.30/ISO/NKP/standardy+and+informačního+and+systému, který jsem zmiňoval ještě v souvislosti se starým WebALEPHem. (Odkazy pro nový Aleph500 nyní opravený skript zpřístupňuje i klientům, které neumějí Java-skripty.)
Na WWW-serverech ale existuje ještě jeden (možná dokonalejší) způsob, jak realizovat automatický přechod klienta na jinou stránku. A to již zmíněným typem odpovědi 301 anebo také 302 Found, což je používáno pro dynamické WWW-stránky. Pro méně průhledné systémy vyžaduje tento postup velmi pečlivé doladění, neboť uživatel nemá možnost (na rozdíl od REFRESH) takovouto činnost snadno zastavit (třeba příkazem STOP).
Pro novou verzi systému TinWeb byla ovšem tato varianta využita. Princip použitých skriptů (napsaných v Perlu) lze nahlédnout v adresáři ftp://beta.vse.cz/pub/SaCzech/. Skripty Tin-500 a Tin-Do kombinují oba principy. Tin-500 vznikl kvůli opravám odkazů z WWW-serveru vyuka na literaturu podle uváděného ISBN. Pomocí odpovědi 302 skript opraví parametry pro "Listuj" v TinWebu na parametry pro "Hledej". Odpověď TinWebu je pak ještě skriptem opravena na formálně stejný tvar jako pro originální odkazy z "výuky". Tato oprava rychle vyřešila nejasné odpovědi systému, pokud by uváděné ISBN neexistovalo.
A navíc. Někdy někde při přímém odkazu na knihovní záznamy není (pod novým rozhraním systém t.č. schopen správně přidělit požadované identifikační označení (&SID). Místo, aby pak uživatel (při odpovědi serveru 500) začal sám znovu z úvodní stránky, kde se problémy s přidělováním identifikačního označení neobjevují, a vyplnil zde ručně ono ISBN, může i toto za něj hned udělat skript. Zjistí-li skript, že má "opravit" odpověď 500 Internal Server Error, zasílá klientovi odpověď 302, ale se požadavkem na použití jiného skriptu Tin-Do. A ten začíná z úvodní WWW-stránky, doplní parametry a k nim přidá REFRESH , analogicky principu zmíněnému už výše pro Aleph.
Snad ještě poznámka, že skript Tin-Do vznikl ze skriptu pro Aleph500, který zároveň měnil kódování Windows-1250 na ISO-8859-2. Způsob jednoduchého principu překódovávání je z něj možná také patrný, neboť příkazy pro tuto činnost v něm byly ponechány jako poznámky.
Oprava ISBN-odkazů byla zabudována i do zmiňovaného skriptu UIW, jenž umí stránky převádět do UTF-8. Překódujeme-li WWW-stránky "výuky" do kódu UTF-8 pomocí UIW, jsou odkazy týkající se ISBN přesměrovány na výše popsané opravné skripty. Kódování češtiny a přístupy do knihovních systému (i s ISBN) se totiž vždy probírají v první polovině semestru. - Nedostáváte pro ISBN vždycky správnou odpověď? To asi nepoužíváte odkazy přes UTF-8.
V tomto momentě je třeba připomenout onu záludnost úprav WWW-stránek na jiném WWW-serveru. K pouhé změně kódu byla připojena i oprava všech odkazů, které mají určitý tvar. Takovýto dočasný detail určitě nikdo nebude psát do návodu nebo Helpu. Tím ale může dojít k dezinformaci uživatele. A v Internetu právě existují počítače, přes které můžeme získat WWW-stránku, aniž o tom vlastně přesně víme. Jsou to například již zmiňované proxy-servery. Ty pro urychlení přístupu si jednou získané stránky sami ukládají, aby je mohly poskytnout dalšímu uživateli a ten nemusel získávat onu stránku ze vzdáleného (a těžko dostupného) serveru. Získá ji tedy takto v průměru o něco dříve. Na proxy-server zanesené úmyslné opravy by tedy mohly způsobit zásadní dezinformaci pro velkou řadu uživatelů. Dokonce se mnohde používají "tajné proxy-servery", které si nemůže uživatel odpojit. Veškerý provoz z části sítě (využívající port 80 pro WWW) bývá někdy směrován pouze přes ně. (Nepříliš výstižně se o nich hovořívá jako o transparentních proxy-serverech.) A obecně proxy-servery nejsou zdaleka tak hlídány správci sítě, jako třeba samotné WWW-servery některých organizací, na které se počítačoví hackeři zaměřují. Ještě že tyto možnosti hackeři zatím neobjevili (a proxy-servery příliš nestudovali). Přesto by se při získání podstatné informace přes WWW měli uživatelé raději přesvědčit - třeba jen z jiného místa sítě - o jejím skutečném původu.
A ještě jednu důležitá poznámka na závěr pro ty, kteří by si takto chtěli opravit něco, s čím neuspěli u správce serveru. O vaší "opravě neopravitelného" ať se žádný správce pokud možno nedozví. Podle základní zásady chování platné v Internetu: Komu dál Pán Bůh "roota", tomu dal i rozum. Když se jednou správce serveru rozhodl, že pro přístup k jeho WWW-stránkám budete používat pouze Internet Explorer verze alespoň 5, tak si to stále musí myslet. Za jakékoliv neuposlechnutí úřadů bývají tresty nejvyšší. Abyste totiž do ukončení Vašich oprav neopravitelného, které nějak zpochybňují jediného "roota", nemuseli začít navštěvovat internetovou kavárnu!