[rt-users] Email output encoding and "RT Essentials"
Leif Nixon
nixon at nsc.liu.se
Fri Oct 21 11:22:57 EDT 2005
Leif Nixon <nixon at nsc.liu.se> writes:
> On the other hand, I now discovered that I18N.pm has a *hardcoded*
> fallback from $EmailOutputEncoding to iso-8859-1 to utf-8, so if I
> change $EmailOutputEncoding from its default value utf-8 to us-ascii,
> I should get my dream behaviour already in RT 3.4.4, right?
No, actually I don't understand SetMIMEEntityToEncoding in
I18N.pm at all.
First it does "$charset = _FindOrGuessCharset($entity)" to guess the
current encoding, then it does
Encode::from_to( $lines[$_], $charset => $enc ) for ( 0 .. $#lines );
where $enc is $EmailOutputEncoding. Now, this will not fail even if
the body can't be encoded into $enc, since the optional CHECK argument
to from_to is missing.
However, if the from_to call still manages to fail, the function tries
Encode::from_to( $lines[$_], 'iso-8859-1' => $enc ) for ( 0 .. $#lines );
instead. Perhaps the reasoning here is that _FindOrGuessCharset might
guess incorrectly, and that the encoding might work if we interpret
the body as iso-8859-1 instead?
Anyway, the result of all this is that the mail will be forcibly
encoded into $EmailOutputEncoding, whether it's possible or not.
--
Leif Nixon - Systems expert
------------------------------------------------------------
National Supercomputer Centre - Linkoping University
------------------------------------------------------------
More information about the rt-users
mailing list