Re: [Evolution] "Default character Encoding" doesn't effect message header

[Not Zed <notzed ximian com>]

On Wed, 2002-06-05 at 16:52, Kenn Sakai wrote:
> Hi.
>
> I chose iso-2022-jp character code for "Default character Encoding",
> however, message header is encoded into UTF-8.

Unfortunately there is currently no relationship between the default
character encoding option for message bodies, and that for headers.

We're still trying to work out the best way to implement this.  The main
problem is the encoding process for headers is abstracted away beyond
several layers of code, and it must be multithread safe.  So we can't
just set a global name of the preferred charset AND give the user the
option on each message they send.

> Subject: =?UTF-8?Q?=E6=97=A5=E6=9C=AC=E8=AA=9E=E3=81=AE=E3=82=B5=E3=83=96?=
>         =?UTF-8?Q?=E3=82=B8=E3=82=A7=E3=82=AF?= =?UTF-8?Q?=E3=83=88?=
>
> The message body itself is encoded into iso-2022-jp.
>
> Is UTF-8 used as a last-resort when Evolution couldn't detect
> the characters in message header ?

Yes.  Well, more precisely, when it couldn't detect a character set (of
its short list) that contains all of the characters in the string, it
falls back to UTF-8.

The list it tries is limited to mainly european languages at the moment
however - mainly because character sets like iso-2022-jp can contain
just about as much as utf-8 can, so it could be chosen 'wrongly'. 
There's been some debate on the best way to implement this (e.g.
fall-back to iso-2022-jp only in certain locales, etc), but no consensus
reached, and then we just got busy with other stuff.

> Are there any configurable options to choose the character code
> for encoding message headers.

Not yet, sorry :(

Well, now I think about it, there might be a way to implement it,
although this does seem a bit hacky, and will still require a reasonable
chunk of work because some api's need changing.

Perhaps we could scan the content of the message any textual parts with
a charset parameter, and if there is one, try to use that as a fallback,
before utf-8 is used.  Or just have a 'preferred charset' member on the
message object.  Could also take the locale into account, but this
conflicts a bit with giving an explicit choice for the content.

How important is this to Japanese users?  i.e. is it common for their
email clients not to support utf8?  Does it make Japanese-language
evolution-generated emails unreadable to almost everyone it might be
sent to?  etc etc.