RE: [Evolution] Charset for mail messages: ANSI_X3.4-1968?

[Not Zed <notzed ximian com>]

Hrm ok.

Although perhaps this could be implemented implictly if the charset is
changed, and there is text content setup?  But that sounds risky of
overprocessing the data.

The problem I was thinking of actually was what to do when you dont have
a charset assigned, and want to change what you show it as.  Then the
initial conversion may be wrong, or not done, or even corrupted, so it
is quite likely you will have invalid data to work with.

This is specifically when for example you receive an 8 bit mail with no
charset, and default to the local charset (inside camel) to process it,
but that decision is actually wrong.  Chances are you will end up with
nonsense, nonrecoverable, as the 'internal, utf8' wont actually be at
all (camel passes mail content all the way from the raw message to utf8
and back again, including transfer-encodings, every time the message is
read/written, etc).

 Z

On 12 Jun 2001 19:11:56 +0500, Dan Winship wrote:
> > > x-user-defined, etc. And you will be able to override incorrect
> > > encodings for display, and change the encoding for specific messages in
> > > the composer when you don't want to use the default.
> >
> > Override?  Oh?  And just how do you plan to do that?  The camel api is
> > utf-8 ...
>
> You still know the original charset from the mime headers though. So
> converting from utf8 to that should get you back the original content,
> and then you can convert that back to utf8 using the user-specified
> source charset.
>
> (Or if the mime part had no charset or an invalid charset specified,
> then you don't even need to do the first conversion.)
>
> I wrote a "camel_mime_part_override_charset" that does this, but I'm not
> sure that's the right way/place to handle it. (It's good to have it as a
> mutator, because then if you do "override charset" and then reply,
> you'll be replying to the charset-overriden copy, which is what you
> want.) The attached diff isn't quite right anyway, because you want it
> to fail and return an error if the conversion can't succeed losslessly.
>
> -- Dan