abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    včera 20:00 | Komunita

    V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.

    Ladislav Hagara | Komentářů: 0
    včera 19:22 | IT novinky

    Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).

    Ladislav Hagara | Komentářů: 0
    30.4. 22:33 | Nová verze

    Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.

    Ladislav Hagara | Komentářů: 0
    30.4. 17:44 | Zajímavý článek

    Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.

    karkar | Komentářů: 0
    30.4. 12:11 | Humor

    Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).

    Ladislav Hagara | Komentářů: 7
    30.4. 10:44 | IT novinky

    Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.

    Ladislav Hagara | Komentářů: 29
    30.4. 09:55 | IT novinky

    Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.

    Ladislav Hagara | Komentářů: 7
    30.4. 09:33 | IT novinky

    Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.

    Ladislav Hagara | Komentářů: 0
    30.4. 08:11 | Nová verze

    Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.

    Ladislav Hagara | Komentářů: 0
    29.4. 20:55 | Nová verze

    Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.

    Ladislav Hagara | Komentářů: 0
    Jaký filesystém primárně používáte?
     (58%)
     (1%)
     (9%)
     (21%)
     (4%)
     (1%)
     (2%)
     (0%)
     (1%)
     (3%)
    Celkem 497 hlasů
     Komentářů: 19, poslední 30.4. 11:32
    Rozcestník

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

    16.6.2007 16:44 | Přečteno: 1658× | Š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        

    Hodnocení: 82 %

            špatnédobré        

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    16.6.2007 17:05 a
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    youtube,com -> youtube.com
    plain 9 -> plan 9
    AsciiWolf avatar 16.6.2007 17:14 AsciiWolf | skóre: 41 | blog: Blog
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    Proč se vlastně uživatelé používají -> Proč vlastně uživatelé používají
    16.6.2007 17:14 David Jaša | skóre: 44 | blog: Dejvův blog
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    zjednatřícetinásobení je co?

    Udělej si pořádek v bitech, bytech, bajtech a podobné verbeži...
    16.6.2007 18:03 Jiří Daněk | skóre: 12 | blog: muj_blogisek
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    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.
    Byl jeden pán a ten měl psa. HAFUŠA se jmenoval.
    pavlix avatar 17.6.2007 22:47 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    UTF-8 má zhruba 1.2 bajtu na znak českého textu.

    Kdyby nějaký pochybnosti nebo dotazy, můžeš napsat na Jabber.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    16.6.2007 18:27 Jiří Daněk | skóre: 12 | blog: muj_blogisek
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    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?
    Byl jeden pán a ten měl psa. HAFUŠA se jmenoval.
    16.6.2007 18:31 Elwood
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    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.
    16.6.2007 18:50 Jiří Daněk | skóre: 12 | blog: muj_blogisek
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    Jo vlastně, vejde se: 3*6 + 3 = 21 a 10FFFF má binárně 21 číslic

    Jdu to opravit
    Byl jeden pán a ten měl psa. HAFUŠA se jmenoval.
    pavlix avatar 17.6.2007 22:48 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    6 bajtů u utf-8 platí IMHO pořád, ale je to jen horní hranice, většinou se nepoužije na žádný znak
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    pavlix avatar 17.6.2007 22:51 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    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)
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    pavlix avatar 17.6.2007 22:54 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    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.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    16.6.2007 18:19 Elwood
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    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.
    16.6.2007 18:35 Jiří Daněk | skóre: 12 | blog: muj_blogisek
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    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ů.
    Byl jeden pán a ten měl psa. HAFUŠA se jmenoval.
    Luboš Doležel (Doli) avatar 16.6.2007 18:45 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    Co? 4 bajty jsou 32 bitů.
    16.6.2007 18:52 Jiří Daněk | skóre: 12 | blog: muj_blogisek
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    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ů.
    Byl jeden pán a ten měl psa. HAFUŠA se jmenoval.
    16.6.2007 19:23 Miloslav Ponkrác | blog: miloslavponkrac
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    jen 21 bitů v současné době
    pavlix avatar 17.6.2007 22:50 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    čí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
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    pavlix avatar 17.6.2007 23:05 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    Jo pardon, trošku pletu dohromady technické rozvržení Unicode a sadu už definovaných znaků.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    16.6.2007 18:58 Filip Jirsák | skóre: 68 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    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…
    16.6.2007 20:32 Dušan Hokův | skóre: 43 | blog: Fedora a další...
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    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.
    16.6.2007 20:35 Jiří Daněk | skóre: 12 | blog: muj_blogisek
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    Ano, jenže FTP schránku ti narozdíl od schránky mailové žádný free-Ftípkový portál nenabídne ;-)
    Byl jeden pán a ten měl psa. HAFUŠA se jmenoval.
    16.6.2007 20:37 Dušan Hokův | skóre: 43 | blog: Fedora a další...
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    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.
    16.6.2007 20:52 Jiří Daněk | skóre: 12 | blog: muj_blogisek
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    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í
    Byl jeden pán a ten měl psa. HAFUŠA se jmenoval.
    Luboš Doležel (Doli) avatar 16.6.2007 21:25 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    Tak mu to pošlu třeba přes Jabber.
    16.6.2007 21:35 Jiří Daněk | skóre: 12 | blog: muj_blogisek
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    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.
    Byl jeden pán a ten měl psa. HAFUŠA se jmenoval.
    Luboš Doležel (Doli) avatar 16.6.2007 22:09 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    Ufff, tak třeba přes ICQ.
    pavlix avatar 17.6.2007 22:57 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    [rejp]To se ti zase taky nemusí povést[/rejp]
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    16.6.2007 22:10 Lu-Tze | skóre: 15 | blog: Lu-Tzeho blog
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    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é.
    16.6.2007 22:15 kavol | skóre: 28
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    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ů
    16.6.2007 22:24 Lu-Tze | skóre: 15 | blog: Lu-Tzeho blog
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    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 :-)
    16.6.2007 23:01 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    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.
    When your hammer is C++, everything begins to look like a thumb.
    16.6.2007 20:44 Käyttäjä 11133 | skóre: 58 | blog: Ajattelee menneisyyttä
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    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é.
    16.6.2007 21:00 Jiří Daněk | skóre: 12 | blog: muj_blogisek
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    Pokusil jsem se to trochu vylepšit, je to teď alespoň o něco méně zavádějící?
    Byl jeden pán a ten měl psa. HAFUŠA se jmenoval.
    16.6.2007 22:13 kavol | skóre: 28
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    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é
    17.6.2007 13:18 Jiří Daněk | skóre: 12 | blog: muj_blogisek
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    "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
    Byl jeden pán a ten měl psa. HAFUŠA se jmenoval.
    20.6.2007 13:23 kavol | skóre: 28
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    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 avatar 16.6.2007 22:29 Prcek | skóre: 43 | Jindřichův Hradec / Brno
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    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
    Člověk je takový, jak vypadá... A já vypadám jako pravá, nefalšovaná děvka!!!
    Luk avatar 16.6.2007 23:29 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    Češtin:

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

    128-kouvou -> stodvacetosmičkovou

    (ostatní kopance už označili jiní)
    Šifrování je absolutní nutnost a pomáhá chránit před nekalými živly
    17.6.2007 02:19 black - aka pol | skóre: 19 | blog: Ze_sveta
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    Ten článek prostě nezní, závorka místo vsuvky, fráze, nucený styl. Nečetl se mi nic moc.
    17.6.2007 22:43 Tomáš | skóre: 31 | blog: Tomik
    Rozbalit Rozbalit vše Re: Proč posílat soubory e-mailem? (Prosba o korekturu článku)
    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.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.