GNOME Bugzilla – Bug 84987
qp encoding doesn't work
Last modified: 2006-06-18 05:15:28 UTC
..for subjects like this: Subject: =?iso-8859-2?Q?Re:_to_v=B9ichni_sp=EDte=3F?=
Cc'ing Chris on this because he's usually the one to say "hmm, I think that's an illegal encoding", and Fejj, because he's usually the one to say "Charles and Chris, you bozos, you're doing it wrong. You were *supposed* to do xyz..." Honestly, the only thing I'm good for is pestering Chris and Fejj with "have you fixed this charset encoding bug yet?" and then saying "oh, I get it now" once I read the diff. :)
from rfc2047: IMPORTANT: 'encoded-word's are designed to be recognized as 'atom's by an RFC 822 parser. from rfc822, Appendix D: atom = 1*<any CHAR except specials, SPACE and CTLs> specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- / "," / ";" / ":" / "\" / <"> ; string, to use / "." / "[" / "]" ; within a word. word = atom / quoted-string
In plain English: 'This is an illegal encoding' :) Specifically, the colon shouldn't be there (not as a literal anyway). We've been down this road before and the consensus was that we can't address every non-compliant agent out there.
ok, so I looked over some header fields, which pan doesn't decode as author of specific news client meant. this one is afaik rfc compliant: Subject: Re: !!! =?windows-1250?Q?Nab=EDz=EDm_scanov=E1n=ED_negativ=F9?= =?windows-1250?Q?=2C_p=F8edloh_do_A4=2C_=E8/b_lasertov=FD_ti?= =?windows-1250?Q?sk_a_=E8/b_inkoutov=FD_tisk_do_A2!!!?= pan decodes only first line here (to the end of first =?widows-1250xyz?=)
yea, it looks like it should be decoding. I'll take a look tonight when I get home :-)
looks like my gmime-utils.c:quoted_decode() function was a bit too aggresive with erroring out. If it encountered a SPACE or ESPECIAL it would abort. The check for ESPECIAL was wrong, since ESPECIALs are actually allowed to be in the encoded-text section of an encoded-word (rfc2047). The SPACE check was just plain redundant since our caller does this, so I removed that whole else-if section. this is now fixed in gmime-2, gmime-1 and pan HEAD I also updated gmime-table-private.h since I found some problems with it as well. thanks for the bug report, otherwise I probably would never have noticed ;-)