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. _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
