Re: gnus: incorrect conversion of Subject and From field from utf-8 to koi8-r

[Kenichi Handa <handa@m17n.org>]

In article <b4mll0vfake.fsf@jpl.org>, Katsumi Yamaoka <yamaoka@jpl.org> writes:
> I confirmed Handa-san's patch is 99% perfect and doesn't lower
> the performance.  However I hesitate to commit it to Gnus
> because I found out the `MUST NOT' phrase in RFC2047 as follows:

> 5. Use of encoded-words in message headers

> [...]

>    The 'encoded-text' in an 'encoded-word' must be self-contained;
>    'encoded-text' MUST NOT be continued from one 'encoded-word' to
>    another.  This implies that the 'encoded-text' portion of a "B"
>    'encoded-word' will be a multiple of 4 characters long; for a "Q"
>    'encoded-word', any "=" character that appears in the 'encoded-text'
>    portion will be followed by two hexadecimal characters.

> The encoded-words that Boris B. Samorodov presented comes just
> under this case.  Even so, should Gnus support such encodings?

>>>>>>  In <E1EQ6NU-000GJF-2s@bsam.ru>
>>>>>> 	"Boris B. Samorodov" <bsam@ipt.ru> wrote:

>>  Subject: =?UTF-8?B?W2lwdC5ydSAjMTYzXSDQkNCy0YLQvtCe0YLQstC10YI6INCc0KHQmjog0KHQ?= =?UTF-8?B?nyDRgtC10YHRgg==?=

This example doesn't violate the above restriction.  Each
'encoded-word' is surely "multiple of 4 characters long".

Please note that the above restriction is for
'encoded-text', not for the underlining coded character set.
So, I think the above document doesn't prohibit diviging
UTF-8 byte sequence at non-character boundary.

---
Kenichi Handa
handa@m17n.org