Věc: Test

Středa Květen 14 06:23:07 CEST 2014

Zdravím,

> 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

Toto je přesně správné chování.
Dle RFC, jediným platným oddělovačem řádků v textovém dokumentu je CRLF.
Jako takové se dle doporučení níže neenkóduje.
Vše ostatní včetně kombinace LFCR se bere jako binární sekvence, ne jako
oddělovač řádků, a tedy se enkóduje.

> 
> 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ě?

Ano. RFC-compliantní e-mail klient musí napřed upravit text do RFC-compliantní
podoby, což mimo jiné znamená konverzi samotných CR nebo samotných LF nebo
čehokoliv jiného na CRLF. Pak se provede quoted-printable encoding, který
CRLF ponechá. Je to třeba proto, aby příjemce mohl přijímat maily ze systému
s jiným vyjádřením oddělovače řádků než CRLF. Např. v *IXech se používá bare
LF, AmigaOs blahé paměti používal bare CR. Tedy pokud by tato konverze přes
"universální" CRLF neproběhla, mezi těmito OS by se vůbec nedalo mailovat,
resp. dalo, ale maily by byly nečitelné.

> 
> 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? 

Ano. Zdekóduje se to do původní podoby a naruší to formátování.
Např. v Linuxu samotné CR zapůsobí jako znak návratu "vozíku" (kursoru)
na začátek řádku a další text tedy bude přepisovat text původní, který tím
zmizí. Naopak samotné LF zpravidla zmate dekodér tak, že skutečně výpis pouze
odskočí na nový řádek, aniž se vrátí na první znak, takže v textu vznikne
"schod".

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

To záleží na tom, jak chápete pojem "správně". Děj popsaný v tomto odstavečku
se nejpíše skutečně stane, takže se stane přesně to, co popisuji já ve svém
předchozím odstavečku, což ale nebude nejspíše odpovídat původnímu záměru
autora. Důležitý moment ale je v tom, že v mailu, který to vše vyvolal, se
vyskytovaly DVOJÍ CRLF - jedny "naturální", neenkódované, a druhé enkódované
a ještě k tomu "rozbité" těmi neenkódovanými do podoby
=OD<CRLF>=0A, což už je OPRAVDU jen těžko tolerovatelná prasárna. Co pak má
korektní dekodér udělat ? 2 CRLF ? Jedno CRLF ? Linuxový mutt to řeší tak,
že extra CR zobrazí jako znak "^M", což skutečně je (Ctrl-M) (a ten je ještě
ke všemu obarvený) a extra LF po tom "naturálním" CRLF nejspíše ignoruje.

Zdraví Pavel

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