Získání webové stránky přes e-mailovou bránu

Druhý úkol do IZI220 – Získání webové stránky přes e-mailovou bránu

Zadání:

Do 5.5.2004 získejte pomocí E-mailu z „Veverky“ (poštovního serveru VŠE) soubor/stránku z nějakého WWW-serveru mimo VŠE. Takto získaný soubor pak uložte na svou vlastní home-stránku! Dopisy k tomuto úkolu si uschovejte až do závěrečného testu.

Zvolená brána:

Pro tento úkol bylo možné zvolit z více různých veřejně přístupných bran. Tyto brány se odlišují ve způsobu zadávání dotazu, v tom, jestli jsou schopny najednou stáhnout celý obsah stránek nebo jen jednotlivé soubory a nebo třeba v rychlosti, jakou dokáží zodpovědět dotaz.
Mezi tyto služby patří například některé, pracující na níže uvedených e-mailových adresách:

Z uvedených služeb jsem si vybral posledně jmenovanou, popis této služby a důvod jejího výběru uvedu v dalším textu.

Popis služby Web4W3 E-mail Gate

Pro vypracování úkolu jsem si vybral službu Web4W3 E-mail gate, jejíž domovské stránky jsou přístupny na adrese web4w3.com/web2email.html. Tato služba je primárně určena pro získání celých stránek prostřednictvím e-mailové zprávy, dokáže tedy zaslat nejen samotný (X)HTML dokument, ale také připojenou grafiku a CSS soubory. Služba je limitována tím, že nedokáže načíst další soubory vkládáné externím souborem, tedy například grafiku vkládanou externím CSS stylem.
Z tohoto důvodu je tato služba vhodná pro rychlé získání stránek (odezva se pohybuje do jedné minuty), ovšem pro některé stránky, které obsahují složitější vnořené CSS styly nebo používají rozmístění grafiky pomocí CSS stylů nebo grafiku pozicují java scriptem je vhodné získat zbylé soubory některou jinou službou, která je zaměřena na jednotlivé soubory, jako například na gophermail@eunet.cz.
Na druhou stranu jsou u většiny dnešních stránek výsledky velmi dobré.

Dotaz:

Mnou vybraná služba umožňuje zadání URL vybrané stránky dvěma způsoby. Prvním je zadání URL přímo přes formulář na domovské stránce služby, druhou možností je zaslání prázdné e-mailové zprávy na adresu web2mail@web4w3.com v jejímž předmětu uvedeme URL požadované stránky. V hlavičce zprávy musí být samozřejmě uvedena adresa odesílatele, na kterou má služba požadovanou stránku poslat.

V souvislosti se zasláním dotazu jsem narazil na zajímavý problém. Při zaslání dotazu přes klienta prohlížeče Mozilla a použití poštovního účtu na veverce mi nepřicházely odpovědi, zatímco při použití mého soukromého mailového účtu na serveru jinak.cz odpovědi normálně docházely. Přitom pro oba účty používám SMTP servre vse.vse.cz a i při srovnání hlaviček zasílaných při zvolení obou účtů v mailovém klientu jsem nenalezl podstatný rozdíl. Navíc při odeslání dotazu z webového rozhraní veverky je odpověď v pořádku doručena. Odhalit podstatu tohoto problému se mi nepodařilo, chyba mohla vzniknout kdekoliv na cestě klient – SMTP server – brána, přičemž k druhým dvoum článkům nemám potřebný přístup.

Pro svůj dotaz jsem si vybral české stránky firmy Microsoft. Tato firma je známá ignorancí webových standardů, takže jsem byl zvědavý na výsledek.
Jako první jsem zkoušel zadat logickou volbu, tedy adresu www.microsoft.cz. Bohužel jako odpověď příšla pouze prázdná zpráva. Při pohledu do jejího kódu. Samotný kód teď nebudu rozebírat, stačí si všimnou kousku HTML kódu na konci dopisu, který přesměrovává na URL www.microsoft.com/cze.
Můj další požadavek tedy byl na tuto URL, tentokrát se mi vrátila požadovaná odpověď.

Výsledek dotazu

Výsledek je v přiloženém souboru. V případě, že poštovní klient podporuje zobrazení webových stránek, je stránka zobrazena přímo v okně zprávy (takto se chová většina dnešních okenních klientů a i některé klienty webové). Pro popis principu, jakým klient stránku ze správy zrekonstruuje popíšu postup, jakým je možné ručně stránku z kódu zprávy sestavit.

Pro pochopení způsobu, jakým je webová stránka v mailu zakódována je nutné zaměřit se nejprave na hlavičku mailu. Většinu informací v hlavičkách nemá pro tento účel smysl rozebírat, důležité jsou tyto řádky:

Content-Type: multipart/related;
boundary="----=_NextPart_000_0001_01C431DC.37C80CC0"

Tento MIME type, popsaný podrobně v RFC 2387, označuje zprávu, skládající se z více částí, které jsou ve vzájemném vztahu. Řádek boundary označuje textový řetězec, který odděluje jednotlivé části zprávy.
První část dopisu obsahuje pouze MIME typ

Content-Type: multipart/alternative;
boundary="----=_NextPart_001_0002_01C431DC.37C80CC0"

Multipart alternative označuje oblasti, které jsou vzájemně zaměnitelné. Tyto části jsou ohraničeny řetězcem uvedeným za boundary. Tento způsob se používá pro zasílání e-mailů, které obsahují jak kód v HTML, tak prostý text. Tento způsob je použit i zde.
První část, uvozená hlavičkami

Content-Type: text/plain;
charset="windows-1250"
Content-Transfer-Encoding: quoted-printable

Tyto hlavičky označují čistý text, v kódování windows-1250 (jak jinak u Microsoftu), ve kterém jsou české znaky zakódovány pomocí kódování quoted-printable. Tento text se zobrazí v klientovi, který neumí, nebo má zakázáno zobrazovat html dokumenty.

Druhá alternativní část je uvozena hlavičkami

Content-Type: text/html;
charset="windows-1250"
Content-Transfer-Encoding: quoted-printable

Jedná se tedy o část, která obsahuje HTML dokument; použité kódování je stejné jako u čistého textu. Kódování češtiny brána převzala z původního dokumentu.
Jakým způsobem jsou do dokumentu vloženy externí soubory (obrázky, CSS styly…)? Při pohledu do kódu jsou URI těchto prvků nahrazeny kódem, jako je tento: cid:000101c431fd$be20e41e$_CDOSYS2.0. Tento kód označuje objekt, který je součástí zprávy, každý takovýto objekt je oddělen způsobem, jaký byl popsán při popisu MIME typu multipart/related. Každá takováto část je definována hlavičkami, např:

Content-Type: image/gif
Content-Transfer-Encoding: base64
Content-ID: <000e01c431fd$be20e41e$_CDOSYS2.0>
Content-Disposition: inline

Část content-type označuje druh objektu pomocí jeho MIME typu, v tomto případě jde o obrázek ve formátu GIF. Část Content-Transfer-Encoding označuje způsob zakódování binárních dat (kvůli 7 bitové kompatibilitě), v tomto případě Base64, používá se také např uuencode. Další část, Content-ID, je jednoznačným identifikátorem části v rámci zprávy a je použita při odkazování na tuto část (v html dokumentu místo URI). Content-Disposition inline naznačuje (dle RFC 2183), že tato část je zobrazena v rámci zprávy, ne pro příklad jako příloha.

Rekonstrukce zprávy

Když víme, co která část znamená, můžeme zrekonstruovat původní webovou stránku. V první řadě je nutné část obsahující html kód (tedy všechno mezi a včetně) uložit do souboru (nejlépe s příponou htm nebo html). Nyní je vhodné tento soubor zbavit kódování quoted printable. Pro tento účel jsem použil příkaz recode, který je obsažený ve většině linuxových distribucí, v tomto případě v syntaxi recode cp-1250/qp..cp-1250 text.htm (text.htm je název převáděného souboru, cp-1250/qp původní kódování, cp-1250 nové kódování).
Dalším krokem je rekonstrukce obrázků. Ty jsou zakódovány pomocí Base64. Pro jejich dekódování je třeba uložit řetězec znaků Base64 do textového souboru s libovolným jménem. Pro dekódování jsem použil program base64, který jsem si sehnal v balíčku pro svou distribuci. Program se používá z příkazového řádku takto: base64 -d "zdroj" "novy_soubor".

Po překódování všech částí je nutné nahradit v html dokumentu cid obrázků za jejich nové názvy. Po té je ještě nutné uložit do textového souboru soubor s CSS a nahradit jeho cid jeho novým názvem.

Dalším krokem je připojení CSS stylu. Ten bývá většinou uložen v ISO Latin-I, takže jen stačí obsah uložit do souboru s příponou .css a jeho název vložit do html kódu místo jeho cidu.

Vhodné je také smazat všechny tagy , , jelikož chybí připojené javascriptové soubory, takže prohlížeč by některé informace interpretoval špatně.

Výsledná stránka

Výslednou stránku si můžete prohlédnout, původní stránka, tak jak ji zobrazuje prohlížeč Mozilla je k dispozici jako snímek obrazovky (pro případ, že se stránky změní).
Jsou zde určité rozdíly, ty jsou způsobeny absencí java scriptu ve výsledných stránkách. Zajímavým rozdílem je nápis Česká republika na původních stránkách a Microsoft na vytvořených. Během testování mi dokonce stránky přišly s českým textem a nápisem Japan. Microsoft pravděpodobně posílá tento nápis podle zeměpisné polohy přistupujícího webového klienta, v případě použité služby ho asi buď neumí určit, nebo určuje do Japonska.

Shrnutí

Přes všechny nedostatky, které tato služba má, mi přijde poměrně užitečná. Kladně hodnotím její rychlou odezvu, snadnost používání, správně použité kódovací tabulky a nabídku čistého textu. Služba je navíc k dipozici ke stažení zdarma.