[rt-users] Email output encoding and "RT Essentials"

Jesse Vincent jesse at bestpractical.com
Sat Oct 22 13:35:43 EDT 2005


Leif Nixon wrote:
> 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.


And based on your description, I agree that it's probably just...wrong.
I've opened a ticket. We have three or four issues in that chunk of code
that need looking at. We'll try to take care of them together, unless
some kind user beats us to it.

Jesse

>
> 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.
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20051022/305b28b4/attachment.sig>


More information about the rt-users mailing list