[imp] Problem with charsets (head)
Michael M Slusarz
slusarz at bigworm.colorado.edu
Fri Apr 16 10:57:26 PDT 2004
>> > But this doesn't work for me anymore.
>> > Because viewing a text/html attachment doesn't change the content and so
>> > UTF-8 chars are displayed in a ISO-8859-1 frame/window, yet.
>>
>> As an update, this is being worked on. Jan has dsecribed the
>> problem as such:
>>
>> ----
>> The real problem is actually deeper in the MIME code. See the FIXME comment
>> in MIME_Part::transferDecode(), this is too much magic.
>>
>> The problem is, that the mime part (if it is a text/* type) already *is*
>> converted to the users charset, so it doesn't help to send the original
>> charset to the browser when viewing the part in a separate window. We end
>> up with UTF-8 text being sent along with an Big5 charset header, for
>> example.
>>
>> The correct solution would be (and I already started this once, but never
>> finished it) to remove all NLS::getCharset() calls from the MIME framework.
>> The controller should define the target charset, not the model, to speak in
>> MVC words.
>> ---
>>
>> I am currently in the process of doing what the last paragraph suggests.
OK - the charset conversion code has been removed from the MIME_Part:: library
so now we should have control over what we send to the user. This means that
viewing in a separate window and saving a message *should* now correctly be
done in the character set of the original message.
Since we were counting on MIME_Part:: to do this conversion before, there are
likely several (many?) places where we will now need charset conversion
code to
be done manually. Let me/Horde developers know locations that aren't working
properly (being an English-speaking user, I don't typically run into any of
these cases) so we can fix them.
michael
______________________________________________
Michael Slusarz [slusarz at bigworm.colorado.edu]
The University of Colorado at Boulder
More information about the imp
mailing list