Last Comment Bug 2671 - Messenger ignores MIME charset label
: Messenger ignores MIME charset label
Product: MailNews Core
Classification: Components
Component: MIME (show other bugs)
: Trunk
: All All
P2 normal (vote)
: M5
Assigned To: rhp (gone)
: Katsuhiko Momoi
Depends on:
  Show dependency treegraph
Reported: 1999-01-26 17:27 PST by lchiang
Modified: 2008-07-31 01:23 PDT (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---


Description User image lchiang 1999-01-26 17:27:04 PST
<Initial description transferred from bugsplat bug 333117.  Assigning to phil
for now because jefft and bienvenu do not yet have a bugzilla account>

Messenger ignores MIME charset label

Messenger always ignores the value of the charset= parameter of the
Content-Type: header of the text part it is displaying.

------- Additional Comments From phil  11/14/98 22:42 -------

Bob and Naoki, any comments on our capability to support this?
Comment 1 User image leger 1999-02-03 08:08:59 PST
Setting all current Open/Normal to M4.
Comment 2 User image lchiang 1999-02-09 11:00:59 PST
qa contact to pmock for now
Comment 3 User image Phil Peterson 1999-03-15 14:37:59 PST
Reassigning to Rich Pizzarro
Comment 4 User image rhp (gone) 1999-03-24 08:41:59 PST
Should be able to deal with this in the new emitters.

- rhp
Comment 5 User image rhp (gone) 1999-04-03 07:33:59 PST
Setting to M5 for now. Does anyone have an example of this that I could use.

- rhp
Comment 6 User image nhottanscp 1999-04-05 14:54:59 PDT
Adding nhotta and bobj to cc: list.
Latin1 example can be easily created by 4.5.
1) In the subject field hold "Alt" key and type 0201 in the num key then release
the "Alt". You should be able to see É.
2) Make sure that MIME encoding is enabled in the pref.
3) Sent out header should contain
Subject: =?iso-8859-1?Q?=C9?=
4) If the MIME decoder is properly hook up, É should be seen for the above line.
Comment 7 User image nhottanscp 1999-04-05 15:02:59 PDT
Rich, can this be done for M4? This was working for M3.
I think we just need to hook up the MIME decoder.
Comment 8 User image John G. Myers 1999-04-05 19:02:59 PDT
Also, if you change the "iso-8859-1" to "iso-8859-5" you should see something
other than latin capital letter E with acute.
Comment 9 User image rhp (gone) 1999-04-06 05:23:59 PDT
Sorry, but my development system has imploded as of yesterday at noon and I
really dont have a stable build environment. I have some changes that I've
salvaged that I need to checkin today, but that is about all I will be able to
do. Sorry :-(

- rhp
Comment 10 User image nhottanscp 1999-04-19 11:07:59 PDT
I think this has been fixed but the verification is blocked by XML UTF-8 bug.
Rich, is there way to verify this (e.g. by view source)?
If so, please change the status to 'FIXED'.
Comment 11 User image rhp (gone) 1999-04-19 11:14:59 PDT
If the problem here is that the UTF-8 conversion is getting truncated, then the
view source will look truncated as well. I think this should remain fixed,
(which it is) and the verification will have to wait on the other bug.

- rhp
Comment 12 User image bobj 1999-04-19 11:42:59 PDT
Verification depends upon a fix for
Comment 13 User image nhottanscp 1999-04-19 12:06:59 PDT
The main blocker of this is the XML bug #4463.
Comment 14 User image nhottanscp 1999-04-21 17:15:59 PDT
The MIME decode is done but I am seeing ISO-2022-JP string appears in the view
instead of UTF-8.
After MIME decode, we need to convert from the charset returned by MIME decoder
to UTF-8.
Comment 15 User image nhottanscp 1999-04-22 15:54:59 PDT
Clear the resolution.
I think Rich has a fix, waiting for the tree to open.
Comment 16 User image rhp (gone) 1999-04-26 19:41:59 PDT
Got these changes FINALLY checked in so this should be fixed. Thanks naoki :-)

- rhp
Comment 17 User image pmock 1999-04-28 14:36:59 PDT
Verified on the in the April 27 Win32 build (build id 1999042708).  When I send
my a message to myself that contain an accented character the received message
header contains the string "=?iso-8859-1?Q?=C9?=".

On Linux build (build id 1999042708), I have not been able to verify on this
platform because, there doesn't appear to be an easy way to generated accented
I have asked a couple of unix engineers but they didn't know.  It was
suggested to talk to Akkana so I emailed her.

Side note, the only information I found was on our international qa web page,  In previous projects, I got
around this problem by sending myself a message from windows that
contained the desired accented character then doing a copy and paste.
Unfortunately, copy and paste is not implmented.

Final verification is pending...
Comment 18 User image Katsuhiko Momoi 1999-04-28 14:45:59 PDT
Peter, we need to test this for a variety of charsets to see
if this is working.Please re-assign this bug verification to me.
Comment 19 User image pmock 1999-04-28 16:27:59 PDT
Received message to Akkana. You can copy and paste the accented character in.
I was able to test the bug successfully. It didn't work for me previously
because I was still using Alt+C and Alt+V.  I didn't know the short cut keys
changed from Nova to Ctl+C and Ctl+V.  It works on Linux.

Per Momoi request, I am reassigning this bug to him for final verification.
Comment 20 User image Katsuhiko Momoi 1999-04-29 18:45:59 PDT
** Checked with 4/29/99 Win32 and Linux builds **

We are now able to display headers and body of messages in
many different languages without switching the encoding menu.
(In fact, at this stage, the encoding menu for Mail lists
only Latin1 and Japanese.) As long as we have the right fonts --
I use the new Bitstream Cyberbit 2.0 font for this purpose --
we can display the following languages headers and body without
doing anything on the part of the user, which is what this bug
fix addresses.


The list of converters to/from Unicode enabled up to M5 can be
found at the above URL. I've confirmed that the following charset
msgs can be displayed on Windows:

ISO-8859-1 (French, German)
ISO-8859-2 (Czech)
ISO-8859-4 (Estonian: Baltic)
ISO-8859-7 (Greek)
ISO-8859-9 (Turkish)
Japanese: ISO-2022-JP
Korean (EUC-KR)
Traditional Chinese (Big5)
Simplified Chinese (Gb2312)
Cyrillic (KOI8-R)

On Unix/Linux, display seems correct only for Japanese and Latin 1,
but this is currently a known limitation on Unix where GFX nulti-
font rendering needs to be implemented properly.

All the above shows that charset label honoring is now in
place. Marking the fix verified on Win32 and Linux.

Note You need to log in before you can comment on or make changes to this bug.