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

[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.