Proč posílat soubory e-mailem? (Prosba o korekturu článku)

16.6.2007 16:44 | Přečteno: 1659× | Škola | poslední úprava: 17.6.2007 13:50

Tímto jsem si založil blog!

Tento článek je původně určen pro školní časopis. Pokud v něm najdete jakékoli nesrovnalosti, dejte mi, prosím, vědět v diskuzi. Děkuji.

---

Proč posílat soubory e-mailem

Na toto téma se mezi 'pokročilými uživateli' debatovalo už mnohokrát. Taková debata většinou konči povzdechem nad neznalostmi uživatelů začátečníků (tj všech ostatních), nebo nad neexistencí lepší alternativy rozesílání dat.

Proč vlastně uživatelé používají e-mail k šíření souborů?

Nejspíše proto, že je to mnohdy jediný jim známý způsob; typický uživatel internetu zná tak akorát web a e-mail a někteří mezi nimi dokonce nerozlišují (tomu napomohla i existence web-mailu). Dalším důvodem je ohromná pohodlnost tohoto způsobu - soubor skončí adresátovi přímo pod nosem v jeho mailové schránce. Zdálo by se, že s nástupem širokopásmových internetových přípojek, toho web-mailu a gigabajtových schránek padla hlavní nevýhoda – že zvětšení souboru v příloze asi o 1/3 v důsledku kódování příloh do Base64 již nehraje žádnou roli, jenže spousta uživatelů je připojena asymetricky (tedy odesílání po uživatelově lince probíhá několikrát pomaleji, než stahování), a proto se odesílání takového nabobtnalého (neboť base64) souboru může protáhnout. Tento neduh sice řeší web-maily, které base64 při přenosu přílohy k sobě na server nepoužívají, jenže další velice podstatná nevýhoda, totiž že v případě přerušení přenosu jej není možné obnovit, ta zůstává. Představte si. že se vám odesílání řekněme 24MB souboru přeruší na 99 procentech a vy musíte začít odznova.

A proč je to politicky nekorektní?

Protože e-mail jednoduše nebyl navržen k transportu souborů. Tato funkce byla implementována až následně* a neschopnost protokolu SMTP (Simple Mail Transfer Protokol) přenášet něco jiného než text** byla vyřešena překódováním příloh (třeba přiložených obrázků) do textu. Znáte pořekadlo, že jeden obrázek vydá za tisíc slov?

* - v nejnovějším znění v RFC 2047 z roku 1996. Pokud se nudíte, zavítejte na http://www.ietf.org/rfc/

** - RFC 20: ASCI – formát pro výměnu informací v rámci počítačových sítí - z roku 1969. Dýchla na nás historie.

A proč objemné přílohy v mailech iritují administrátory?

Hlavně z toho důvodu, že 'jejich strojový park' (v některých případech ani jeho programové vybavení, například e-mailový server, který pro každého adresáta zařadí do fronty novou kopii mailu, není příliš vhodný k odeslání 'řeťězáku') nebyl dimenzován na takovou zátěž, jakou představuje typická uživatelská korespondence – řetězové dopisy, vtipná videa o biatlonistech, powerpointové prezentace o tchyních („topím tchyni v kyselině, ona ještě, mrcha, žije...“) nebo koťatech všech tvarů a barev. Hodně (amerických i evropsko-unijních) společností se také potýká s problémem zákonné archivace e-mailů, když jim drahocenné místo zabírají švédští biatlonisté střílející finské soupeře.

Ani samotný proces odeslání takového maxi mailu není bez problémů. Asi před dvěma roky se podařilo úředníkům anglického ministerstva obrany přetížit síťovou infrastrukturu masovým šířením humorného videa, které natočili britští vojáci v Iráku. Každému byrokratovi bylo samozřejmě, vinou lavinovitého rozesílání, doručeno několikrát, což systém neustál.

A závěr?

Pokud využíváte služeb některého freemailového portálu (Seznam, Google, Centrum...), nebude mít vaše extrémně přílohové mailování nejspíš žádné následky – provozovatelé těchto služeb s tím počítají a mohou si takové uživatele dovolit. Pokud tedy nezahltíte adresátovi schránku, můžete mailovat do aleluja. Samozřejmě v případě, že se snažíte o systémové a elegantní řešení, měli byste zavítat ke službám jako je e-disk (www.edisk.cz), nebo YouTube (www.youtube.com) v případě videa. V případě velkého množství adresátů, nebo záměru rozšířit soubor mezi opravdu velkou skupinu uživatelů je také možné využít služeb nějaké P2P sítě. Poslední zmiňované řešení má oproti službám typu e-disk výhodu v rozptýlení celkového objemu přenesených dat mezi větší množství počítačů, zatímco u e-disku, a jemu podobných, si všechno oddře poskytovatel té služby (což vám samozřejmě nemusí vadit.)

A ještě k firmám – mnohé problém řeší úpravou mailu na serveru, který přílohy ze zprávy vypreparuje, dekóduje z base64 a do e-mailu uloží adresu, na které si je může příjemce mailu v následujících sedmi dnech stáhnout.

Kódování textu /* Do rámečku */

ASCII

Nejprve se zaměřme na ASCII. Jedná se o kódování standardizované v RFC 20. Pro každý znak se použije osm bitů, samotné kódování je však sedmibitové a nejvyšší bit (co ve dvojkovém rozvoji toho osmibitového čísla určuje přítomnost /u ASCII vždy nepřítomnost / členu 1*128) je jen vycpávka a je vždy nulový. Tím pádem je zde místo jen pro 127 písmen:

tisknutelné znaky:

písmena, číslice, jiné znaky (závorky, matematické znaky (+-*/%½¼ ...), interpunkční znaménka (,.:; … (ano, pro ležatou trojtečku existuje zvláštní znak))

speciální znaky (@$~ ...)) a řídící (netisknutelné) kódy, které byly původně určeny pro řízení periferních zařízení (např. tiskárny nebo dálnopisu)).

Pro další jazyky byla vytvořena rozšíření, která definují dalších 128 znaků (písmena s diakritikou a tak) při nejvyšším bitu nastaveném na jedničku. O standardizaci v této oblasti se zasadila ISO, ale její kódování, jako třeba ISO 8859-2 pro češtinu muselo o své místo na slunci bojovat s výplody velkých IT firem, které cítily potřebu vyvinout si kódování vlastní a jinými regionálními kódováními. V naší malé zemi se víceméně používala tato vzájemně nekompatibilní kódování češtiny:

Windows-1250, ISO 8859-2, CP852 (Latin2), x-mac-ce od Apple, jako ČSN norma schválené KOI-8 a kód bratří Kamenických.

Unicode

Neudržitelnost zatím popsaného stavu je nabíledni. Proto nepřekvapí, že (již ke konci osmdesátých let minulého století) se objevily snahy o sjednocení znakových sad do jedné univerzální. Sjednocující sady vzniky hned dvě (Unicode, UCS - Universal Character Set), naštěstí jsou (a až na váhavé začátky vždy byly) vzájemně kompatibilní, jen Unicode navíc oproti UCS definuje i třídící a řadící postupy pro textové řetězce v různých jazycích a podporuje i zprava doleva psaný text (tj. arabštinu a jí podobné jazyky). A co že Unicode obsahuje? Snad všechny symboly všech jazyků na Zemi (i japonštiny či čínštiny), fonetické symboly a vědecké znaky. Unicode má samozřejmě své nevýhody, z nichž nejvýznamnější je při použití čistého Unicode (tím je myšleno kódování UTF-32) zčtyřnásobení celkové délky textu. Tento problém však řeší kódování s proměnnou šířkou (velikostí v bitech) znaku. A pojďme od specifikace k nejužívanější implementaci (v tomto případě jsou implementacemi další specifikace konkrétních kódování). Například i tyto Křenoviny jsou psány povětšinou v:

UTF-8

UTF-8 vzniklo jako systémové kódování pro experimentální operační systém Plan 9 from Bell Labs (název je inspirovaný nízkorozpočtovým filmem Plan 9 from Outer Space) a je standardizováno v RFC 3629 z roku 2003. V této definici je maximální délka znaku stanovena jako 4 bajty. Zdálo by se, že v oproti UTF-32 jsme si, co se týče zvětšení textu, oproti osmibitovému kódování moc nepomohli. Ale vězte, že se zde používá proměnná šířka znaku, že čeština má všechny svoje háčkované, kroužkované a čárkované znaky dvoubytové, a že zbývající česká písmena jsou uložena stejně jako v ASCII (páč kompatibilita, bude to ještě zmíněno níže), tedy mírný nárůst velikosti textu (o byte za každé písmeno s diakritikou) za pohodlí, které nám celosvětově použitelné kódování přináší, rozhodně stojí.

A jakže se pozná, kolik písmen znak vlastně zabírá? Kde končí jeden a začíná druhý? Ve dvojkovém zápisu je celkový počet bytů pro znak shodný s počtem bitů od začátku prvního bytu znaku po první nulový bit. Dalším vodítkem je, že první bajt znaku na rozdíl od druhého, třetího a čtvrtého nikdy nezačíná na 10, zatímco ty další v pořadí takto začínají vždy. Přehledně v tabulce (písmenko 'v' vyjadřuje libovolný bit; 'v' proto, že má ve většině fontů stejnou šířku jako číslice a já tak nemusím používat monospaceový font; bity označené v tabulce 'v' opravdu kodují znak, ostatní jsou jakoby řídící):

celkem bytů tvořících znak	bitů kódujících znak	posloupnost bytů ve dvojkové soustavě
1				7			0vvvvvvv
2				11			110vvvvv 10vvvvvv
3				16			1110vvvv 10vvvvvv 10vvvvvv
4				21			11110vvv 10vvvvvv 10vvvvvv 10vvvvvv

UTF-8 tedy může kódovat až 10FFFF (hexadecimálně) znaků (tj. 1114111). Další zajímavostí je, že pokud v našem textu použijeme jen jednobitové znaky, bude text vypadat úplně stejně jak v ASCII, tak v UTF-8, což je prvek zpětné kompatibility.

Base64 /*Do rámečku*/

Jak možná z textu vyplynulo, jde o metodu na převod jakéhokoli souboru do textu, který je pomocí SMTP protokolu jednoduše transportovatelný (tím je myšlen čistý text, tedy binární 'textové' dokumenty MS Wordu musí být též převedeny.) Princip kódování je vysvětlen už názvem (základ64): data souboru se rozdělí po šesti bitech a každá šestice se jednoduše vyjádří v 64kové soustavě pomocí tisknutelných znaků ASCII. Desítkové hodnotě 1 odpovídá A, dvojce B, padesáti malé ypsilon... Proč zrovna 64kové? Protože v ASCII tabulce máme 64 tisknutelných znaků (tedy, máme jich o něco víc, ale snažit se je využít všechny by bylo komplikované, nehospodárné, a nebo obojí - kvůli těm několika písmenkům přece nebudeme používat hned 128-kouvou (2^7) soustavu). Pokud není možné soubor do oněch šestic rozdělit bezezbytku, nastává čachrování s rovnítky, ale popis tohoto by jen zbytečně zdržoval, užitečnější je zamyslet se, co způsobuje ono třetinové (oproti původní, binární podobě) nabobtnání dat, která jsou takto zakódována. Pokud máte zrovna volnou chvilku /asi ano, když čtete Křenoviny/, můžete si nad tím popřemýšlet, pro nás ostatní je tu stručné vysvětlení: - každý znak ve starém ASCII (neUnicode) kódování zabírá osm bitů - z binárního souboru bereme data po šesti bitech a každou šestici zakódujeme jako znak (jako osmibytový znak), tedy ke každé šestici přidáme dvoubitovou 'omáčku' zlomek 2/6 se vykrátí na... 1/3 tedy omáčka bude tvořit třetinu souboru.

EOF        

Komentáře

[a]

youtube,com -> youtube.com
plain 9 -> plan 9

[AsciiWolf]

Proč se vlastně uživatelé používají -> Proč vlastně uživatelé používají

[David Jaša]

zjednatřícetinásobení je co?

Udělej si pořádek v bitech, bytech, bajtech a podobné verbeži...

[Jiří Daněk]

Takže jestli to dobře chápu, základní Unicode je UTF-32, takže s jeho použitím by se mi text zvětšil ne 31x, ale 4x. V UTF-8 může mít jeden znak až 6 bajtů (protože kromě, jak to značím, 'v'ček musí každý bajt ještě obsahovat tu 'hlavičku'), ale vzhledem k tomu, že tolik obvykle nemá, představuje UTF-8 značnou úsporu místa. Je to takhle dobře?

Jinak, díky za všechny dosavadní opravy.

[pavlix]

UTF-8 má zhruba 1.2 bajtu na znak českého textu.

Kdyby nějaký pochybnosti nebo dotazy, můžeš napsat na Jabber.

[Jiří Daněk]

Vlastně ne, nechápu. Jak to, že v anglické Wikipedii píšou:

UTF-8 uses one to four bytes (strictly, octets) per character

a v české:

Zakódované znaky mohou být až 6 bajtů dlouhé

Asi bych řek, že má pravdu ta česká, protože nejvyšší přípustná hodnota Unicodového znaku je 10FFFF a to se do čtyřbajtového UTF-8 nevejde.

Ano?

[Elwood]

6 bytů byla možná délka v původní specifikaci. Nová specifikace omezila maximální hodnotu znaku na výše zmíněných 10FFFF což je něco přez jeden milion a proto se do 4 bytů podle kodování UTF8 vejde.

[Jiří Daněk]

Jo vlastně, vejde se: 3*6 + 3 = 21 a 10FFFF má binárně 21 číslic

Jdu to opravit

[pavlix]

6 bajtů u utf-8 platí IMHO pořád, ale je to jen horní hranice, většinou se nepoužije na žádný znak

[pavlix]

Tak to vypadá, že jse opravdu nějaká drobnost změnila, jen mi to přijde trošku nesmyslné, když to nepřinese žádnou úsporu (je to pouze horní limit)

[pavlix]

Tak poslední oprava.

Věc se má takhle, v současném unicodu má utf-8 reprezentace znaku nejvýše čtyři bajty, ale pětibajtové a šestibajtové sekvence jsou rezervovány do budoucna.

[Elwood]

Ta tabulka je poněkuď špatně. Podle wikipedie zabírá jeden znak 1-4 bytů proto by měly být v tabulce čtyři řádky. Rovněž v stávající tabulce počet bitů kódujících znak neodpovídá počtu v. Výpočet pro možný počet znaků by měl vypadat 2^21 + 2^16 + 2^11 + 2^7 tedy něco nad dva miliony.

[Jiří Daněk]

Jak jsem se už zmínil, čtyři bajty mně přijdou málo na to, že číslo znaku v Unicode má až 24 bitů.

[Luboš Doležel (Doli)]

Co? 4 bajty jsou 32 bitů.

[Jiří Daněk]

Tohle mě právě poprve zmátlo, ale maximální číslo označující unicodový znak je ono 10FFFF, které má binárně 21 bitů.

[Miloslav Ponkrác]

jen 21 bitů v současné době

[pavlix]

číslo v unicode má až 31 bitů, jeden bit se nepoužívá

utf-8 má max. 6 bajtů, většinou ale zabírá jen jeden bajt

[pavlix]

Jo pardon, trošku pletu dohromady technické rozvržení Unicode a sadu už definovaných znaků.

[Filip Jirsák]

Chybí mi jedna podstatná nevýhoda pro uživatele odesílajícího e-mail s velkou přílohou: spousta uživatelů je připojena asymetricky, tj. mají nižší rychlost uploadu. Tzn. odesílání takového e-mailu se může protáhnout. A navíc ani SMTP ani HTTP upload (webové rozhraní e-mailů) není vybaveno technologií na navázání přerušeného odesílání. Takže uživatel odesílá 20MB e-mail, po odeslání 95 % se přeruší spojení, a může začít znovu…

[Dušan Hokův]

K posilani souboru slouzi napriklad protokol FTP. Vice nez 10M soubory mejlem posilaji jen naprosti ignoranti. Je to jako posilat 500 tun obili ceskou postou namisto nakladnim vlakem.

[Jiří Daněk]

Ano, jenže FTP schránku ti narozdíl od schránky mailové žádný free-Ftípkový portál nenabídne

[Dušan Hokův]

Kazdy si muze udelat vlastni FTP server, tedy pokud neni jen u nejakeho radoby poskytovatele, ktery nedava verejnou IP adresu nebo nepresmerovava porty dovnitr site na privatni adresy.

[Jiří Daněk]

Samozřejmě, jenže je s tím mnohem víc práce, než s mailem:

soubor mně není možné doručit, pokud nesedím u počítače (odborně: pokud není počítač zapnutý a on-line)

lidé, co mi posílají soubor, musí mít u mě účet, takže proces potom vypadá asi takhle:

1) "chci ti poslat soubor"

2) "v Průzkumníku napiš po dpole adresa toto: 'ftp://usrename@passwd:host.cz' (bez vnějších apostrofů), stiskni enter a ten soubor to toho okna přetáhni"

3) Pepa mi poslal soubor

oproti mailu:

1) jéé, Pepa mi poslal soubor

samozřejmě můžu udělat jeden univerzální veřejný účet, jenže potom Pepa uvidí, co mi poslal Martin

FTP prostě není dělané na tohle použití

[Luboš Doležel (Doli)]

Tak mu to pošlu třeba přes Jabber.

[Jiří Daněk]

Jenže než si váš protějšek stáhne vhodného klienta (než zjistí, že na něho nepotřebuje crack ) a než ho nainstaluje a registruje si účet, třikrát se na to vykašle.

[Luboš Doležel (Doli)]

Ufff, tak třeba přes ICQ.

[pavlix]

[rejp]To se ti zase taky nemusí povést[/rejp]

[Lu-Tze]

Ne, jsou to lidé, kteří se chovají naprosto přirozeně Bohužel ajtíci budou raději brblat cosi o nějakých rfc a nazývat lidi ignoranty, než aby ten protokol pro dnešní potřeby rozšířili o nějakou nadstavbu :-P Velké přílohy by se mohly po odeslání ukládat na server poskytovatele služby pro odesilatele, odkud by si je příjemce mohl stáhnout (buď jen k sobě nebo i na server svého poskytovatele) a to např. automaticky nastavením v poštovním klientu - pak by pro něj bylo vše transparentní (k nerozeznání od běžné přílohy).

Veškerá navrhovaná řešení v tomhle blogu a komentářích totiž v obecném případě nefungují. Vždy je potřeba ještě něco přidat a ještě vše uživatelům zkomplikovat. Např. při použití služby jako edisk.cz by uživatel musel soubor ještě nějak zabezpečit - tohle ovšem v případě mailu udělá poštovní klient, pro uživatele je to velmi pohodlné.

[kavol]

ano, lidé jsou ignoranti, včetně tebe (doufám, že to Ignorovi lichotí ) - je blbost "rozšiřovat protokol o nadstavbu", když máme hafo protokolů jiných, které danou věc zvládají bez problémů

[Lu-Tze]

Tak tou nadstavbou může být třeba to, že se klient a server domluví, kam se má ta příloha na serveru uložit. K samotnému uložení nechť se využije třeba i nějaký vhodný existující protokol. Mám hromádku fotek a nějaké povídání o nich, chci je poslat jedné konkrétní osobě. Podle tebe je asi přirozené, abych ty logicky související části rozdělil a k příjemci je dopravil dvěma různými cestami, přičemž to, že jde o dvě různé cesty, pocítí odesilatel i příjemce.

A ano, lichotí mi to

[Michal Vyskočil]

Pokud se nějaká technologie používá jinak, než její tvůrci očekávali, je logičtější

• nadávat lidem, aby ji používali "správně" a z RFC tak defakto udělat dogma ne nepodobné svatým textům
• rozšířit/upravit ji tak, aby novému způsobu využití vyhovovala

Obávám se, že ignorance je spíše bod 1, než 2 . A pro samotný přenos vůbec není třeba vymýšlet speciální protokoly, ale použít už některý ze stávajících.

[Käyttäjä 11133]

nevíhoda?
---
Nejprve se zaměřme na ASCII. Jedná se o kódování standardizované v RFC 20. Pro každý znak se použije osm bitů, ale (ale ten nejvyšší, co reprezentuje číslici 128, je vždy nulový. Tím pádem je zde místo jen pro 127 písmen:
-- do osmi bitů narvu 2^8 čísel. což je 256 , jelikož je tam možnost zakódovat i nulu tak se dostávám k tomu, že poslední člen je 255. Nějak nechápu tu poznámku o 128. A vůbec mi to připadne nějaké zmatené.

[Jiří Daněk]

Pokusil jsem se to trochu vylepšit, je to teď alespoň o něco méně zavádějící?

[kavol]

kydy o strašlivém nárůstu velikosti vlivem překódování 8bit => 7bit jsou k smíchu ... podstatné je, že se mailem posílají sračky; když už, tak bych zmínil posílání fotek v bmp místo jpg, posílání vektorové grafiky jako rastrové, posílání rastrové grafiky jako bmp vložený v .doc místo obyčejného png apod.

RFC 20: ASCI => RFC 20: ASCII

ASCII - celkově je to zmatené ... znaky 1/2, 1/4 a výpustek ("ležatá teojtečka") v ASCII nejsou; @$~ jsou samozřejmě znaky tisknutelné

"o standardizaci se snažila organizace ISO" - ehm, nesnažila, prostě standardizovala; btw spojení "organizace I.S. Organizace" je divné

jinak KOI8-CS je součástí nějaké ČSN, bylo dávno před ISO a o "bratrech z východu" bych pomlčel, to je naše věc

"páč" - kdeže to chceš zveřejňovat?

"jednobitové znaky" - ???

"každý znak ve starém ASCII (neUnicode) kódování zabírá osm bitů" - nesmysl, sám o kus výše píšeš, že ASCII je sedmibitové

[Jiří Daněk]

"každý znak ve starém ASCII (neUnicode) kódování zabírá osm bitů" - nesmysl, sám o kus výše píšeš, že ASCII je sedmibitové

Ne, tohle je jedna z mála věcí, která je dobře. Znaky jsou sice sedmibitové, jenže každý má ještě vycpávkový nulový bit na začátku, aby se s tím dobře pracovalo

[kavol]

Znaky jsou sice sedmibitové, jenže každý má ještě vycpávkový nulový bit na začátku, aby se s tím dobře pracovalo

nikoliv, to si pleteš kódování a jeho representaci ("encoding form" vs. "encoding scheme") ... to už bys rovnou mohl říci, že na 64bit procesoru je ASCII 64bitové kódování, protože má na začátku 57 vycpávkových nulových bitů ...

[Prcek]

misto apostrofu bych dal ceske uvozovky, obcas se tam dost neprehledne vnoruji zavorky

debata většinou konči
Zdálo by se, že s nástupem širokopásmových internetových přípojek, toho web-mailu a gigabajtových schránek<carka> padla hlavní nevýhoda
spousta uživatelů je připojena asymeticky
(tedy odeslání po uživatelově lince probíhá několikrát pomaleji, než stahování)
Tento neduch sice řeší
v případě přerušení přenostu
Představte si. že se vám odesílání
speciální znaky<mezera>(@$~ ...))
řadící postupy pro textová řetězce
Zdálo by se, že v oproti s UTF-32 jsme si, co se týče zvětšení textu oproti osmibitovému kódování<carka> moc nepomohli.
páč kompatibilita
že první byt znaku
opravdu kodují znak
128-kouvou
stručné vysvětlení: - každý znak

[Luk]

Češtin:

64kové -> čtyřiašedesátkové

128-kouvou -> stodvacetosmičkovou

(ostatní kopance už označili jiní)

[black - aka pol]

Ten článek prostě nezní, závorka místo vsuvky, fráze, nucený styl. Nečetl se mi nic moc.

[Tomáš]

Vzhledem k Tvému věku je to docela slušné. Doporučuji (důrazně) dělat korekturu na papíře. Na monitoru snadno přehlédneš překlepy, na papíře máš větší šanci. Pár vytištěných listů je bohatě vyváženo kvalitou a rychlostí odvedené práce.