Věc: Test

Středa Květen 14 06:31:58 CEST 2014

Zdravím,
  ještě jeden dodatek pro vysvětlenou. Víte, proč byl přijat jako jediný
správný tvar oddělovače řádků CRLF a ne např. LFCR ?
  Kvůli dálnopisným strojům a elektrickým psacím strojům.
  Akce "CR" zde skutečně znamenala "Carriage Return", tj. návrat vozíku
(buďto typového koše nebo válce dle konstrukce stroje), zatímco LF je
skutečně Line Feed, neboli posun na nový řádek. Výše uvedená mechanická
zařízení byla konstruována tak, aby obě činnosti mohly probíhat současně,
tj. během návratu vozíku se současně pootočil válec na nový řádek. Jako
první ale musela být iniciována akce návratu vozíku, neboť tato pohybuje
mnohdy těžkou mechanickou sestavou a tedy její provedení trvá výrazně déle.
Přijetí znaku "LF" bylo vítaným zpožděním, kdy během posunu o řádek stihl
vozík dojet do výchozí polohy. Pokud jste do dálnopisného streamu poslali
místo CRLF LFCR a bezprostředně na to další znaky, buďto bylo první písmeno
nového řádku vytištěno na nedefinovaném místě papíru a nebo se dokonce
papír o typovou páku při prudkém pohybu vozíku zpět roztrhl. A uvědomte si,
že tyto standardy vznikaly v době, kdy kompatibilita s mechanickými 
výstupními zařízeními ještě musela být udržována.
  Zdraví Pavel

> Tak jsem právě zjistil, že se php funkce quoted_printable_encode chová 
> takhle:
> CRLF nechá jako CRLF
> samotné CR zakóduje na =0D 
> samotné LF zakóduje na =0A
> LFCR zakóduje na =0A=0D
> 
> V dokumentaci se píše "Returns a quoted printable string created according 
> to ? RFC2045, section 6.7."
> 
> Přišel jsem an to náhodou úplně bez souvislosti s tímto vláknem a nejdřív mě 
> to dost zarazilo, ale jak tak koukám, ono to je nejspíš v souladu s tím RFC. 
> Ale asi jsem to ještě pořádně nepochopil: Když zdroják v php, který něco 
> posílá mailem, bude napsaný na platformě používající jako konec řádku jen 
> LF, tak to taky tak bude ve stringu co tvoří tělo mailu. Ten když se podhodí 
> quoted_printable_encode, tak se to LF dostane do těla mailu zakódované a u 
> příjemce se to zase rozkóduje na LF. Vadí to něčemu? Anebo se mají před 
> voláním quoted_printable_encode v tom stringu konce řádků přeměnit na CRLF 
> aby to bylo důsledně v kanonické formě?
> 
> Dále: Pokud se v těle mailu před kódováním objeví samotné CR, samotné LF 
> nebo dvojice LFCR, tak vadí to něčemu? Podle mě to snad bude chápáno jako 
> jeden nebo dva oktety a ne jako "(4) (Line Breaks)", takže to bude následně 
> zakódováno a na straně příjemce nejspíš zase odkódováno do stejného oktetu 
> jako to poslal odesílatel, aniž by došlo k automatické konverzi konce řádku 
> na CRLF nebo LF podle platformy. Skoro bych řekl, že dobrý mailový klient má 
> umět zobrazit jako konec řádku jak CRLF tak samotné LF bez ohledu na to, že 
> možná puristi říkají, že jen jedno je správně a to druhé nesmí v mailu být. 
> 
> D.O.
> 
> On 5 May 2014 at 10:10, Pavel Troller wrote:
> > Zdravím,
> > 
> > > Mozete to prosim vysvetlit?
> > 
> > Ale zajisté, velmi rád!
> > 
> > > 
> > > Ja tam vidim quoted-printable a =0D=0A ako CRLF, co je na tom nepatricne?
> > 
> > No právě to celé je nepatřičné! Viz tento odstavec, přímo z RFC 2045:
> > 
> >     (4)   (Line Breaks) A line break in a text body, represented
> >           as a CRLF sequence in the text canonical form, must be
> >           represented by a (RFC 822) line break, which is also a
> >           CRLF sequence, in the Quoted-Printable encoding.  Since
> >           the canonical representation of media types other than
> >           text do not generally include the representation of
> >           line breaks as CRLF sequences, no hard line breaks
> >           (i.e. line breaks that are intended to be meaningful
> >           and to be displayed to the user) can occur in the
> >           quoted-printable encoding of such types.  Sequences
> >           like "=0D", "=0A", "=0A=0D" and "=0D=0A" will routinely
> >           appear in non-text data represented in quoted-
> >           printable, of course.
> > 
> > Takže, tato sekvence má oprávnění výskytu v quoted-printable pouze pro
> > "non-text data", což není náš případ, alespoň tak tomuto odstavci rozumím.
> > 
> > Jako důkaz přikládám i verbatim verzi původního mailu, ovšem celou:
> > 
> > --_-_-_=_Next_Part:FFFFFFFF.FFFFFEAE_=_-_-_
> > Content-Type: text/plain;
> >         charset=UTF-8
> > Content-Transfer-Encoding: quoted-printable
> > Content-Disposition: inline
> > 
> > Fruku Bruku :-) =0D=0A=0D=0A* P=C5=AFvodn=C3=AD zpr=C3=A1va *=0D=0AOd:=0D=
> > =0Ahwnews na zirafoviny.cz=0D=0AOdesl=C3=A1na:=0D=0A8:25:49=0D=0A05.05.2014=0D=
> > =0AKomu:=0D=0Ahw-list na list.hw.cz=0D=0AP=C5=99edm=C4=9Bt:=0D=0ATest=0D=0A=0D=
> > =0ABruku fruku - test :-)   Sa=C5=A1a Svobodov=C3=A1
> > --_-_-_=_Next_Part:FFFFFFFF.FFFFFEAE_=_-_-_ Content-Type: text/plain;
> > charset="iso-8859-2" MIME-Version: 1.0 Content-Transfer-Encoding:
> > quoted-printable Content-Disposition: inline
> > 
> > _______________________________________________
> > HW-list mailing list  -  sponsored by www.HW.cz
> > Hw-list na list.hw.cz
> > http://list.hw.cz/mailman/listinfo/hw-list
> > 
> > --_-_-_=_Next_Part:FFFFFFFF.FFFFFEAE_=_-_-_--
> > 
> > Všimněte si prosím, že obsahuje 2 quoted-printable části, a to vlastní e-mail a
> > hlavičku mailing-listu. A ta, ač je též quoted-printable, CRLF enkódované nemá.
> > Japato ?
> > 
> > > 
> > > Dakujem,
> > 
> > Není opravdu zač!
> > 
> > > 
> > > wek
> > 
> > Zdraví Pavel
> > 
> > > 
> > > _______________________________________________
> > > HW-list mailing list  -  sponsored by www.HW.cz
> > > Hw-list na list.hw.cz
> > > http://list.hw.cz/mailman/listinfo/hw-list
> > _______________________________________________
> > HW-list mailing list  -  sponsored by www.HW.cz
> > Hw-list na list.hw.cz
> > http://list.hw.cz/mailman/listinfo/hw-list
> 
> 
> 
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list