Re: a bug about format-patch of multibyte characters comment

[Jeff King <peff@peff.net>]

On Sun, Feb 13, 2011 at 07:14:20PM +0900, xiaozhu wrote:

> I am not similar with mail format. I read the rfc2047 again, but I didn't
> see any description about line separator encoding. Perhaps a base64 encoded-word
> will contain the line separator involuntarily? I also found a sample in
> rfc2047 it show us a line broken subject mail, but it didn't say any thing
> about line separator encoding.

If the encoded-word contains the line separator, wouldn't it be a
literal character in the header value then? I.e., using rfc2047 you can
embed a literal newline into your subject (or possibly, a 0x0a byte may
be part of a multi-byte character; that can't happen in utf8, but I
believe it can in utf16).

> A sample of rfc2047 show us a legal line broken subject mail, like following:
> ------------------------------------------------------------------
>  Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=
>     =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=
> ------------------------------------------------------------------
> 
> I understand that the current format-patch is not not valid to rfc2822/rfc2047,
> but even a valid one just like above, most of the mail client will can not show it
> correctly, they show the first line only, I think that's a problem of user
> friendliness.

Then those mail clients are broken. That should first be unfolded to put
both encoded-words on the same line (separated by whitespace, I think,
though it doesn't matter for encoded words), and then each encoded word
should be decoded (the resulting text is "If you can read this you
understand the example.").

Mutt and other MUAs do this just fine. If you have a MUA that doesn't,
complain to the author.

-Peff