I noticed that the
while (camel_mime_is_dtext(*inptr) && *inptr)
got reversed in your camel-lite patch, which must mean that you had
locally changed the code to do the *inptr check first...
I think your change was correct, we should be checking *inptr first
before passing it to camel_mime_is_dte
Awesome! In the afternoon I started with the exact same port, but had to
pause because of "family visiting", I'm back home and you have it
finished :). Thanks a lot!
Brought it to tny's camel. FYI:
http://tinymail.org/trac/tinymail/changeset/3203
On Tue, 2007-12-25 at 19:28 -0500, Jeffrey Stedf
This patch is a port of my GMime rfc2047 decoder which is even more
liberal in what it accepts than Thunderbird and is what I will be
committing to svn.
closing bugs:
#302991
#315513
#502178
Jeff
Index: camel-mime-utils.c
===
--- c
FWIW, even Thunderbird doesn't handle multi-byte characters split across
multiple encoded-word tokens. I was just checking out their
implementation in
mozilla/netwerk/src/nsMIMEHeaderParamImpl.cpp:DecodeRFC2047Str()
Jeff
On Sun, 2007-12-23 at 23:09 +0800, jacky wrote:
> Hi, all.
>
> The rfc204
On Tue, 2007-12-25 at 15:56 +0800, jacky wrote:
> But the problem describe below has not been solved.
> > 1) An encoded-word was divided into two line. This
> was
> > sent by dotProject v2.0.1 .
>
> As I seen this kind of email use quoted encode only,
> and header_decode_text() can get all encode
--- jacky <[EMAIL PROTECTED]>worte:
>
> --- Peter Volkov <[EMAIL PROTECTED]>wrote:
>
> >
> > В Пнд, 24/12/2007 в 13:21 +0800, jacky
> > пишет:
> > > --- Jeff Stedfast <[EMAIL PROTECTED]>wrote:
> > > There are two kind of email need to support:
> > > 1) An encoded-word was divided into two line
