Closed
Bug 65702
Opened 24 years ago
Closed 23 years ago
Can't decode subject if it contains ASCII and Japanese
Categories
(MailNews Core :: Internationalization, defect, P3)
MailNews Core
Internationalization
Tracking
(Not tracked)
VERIFIED
WORKSFORME
People
(Reporter: kazhik, Assigned: jgmyers)
References
Details
(Keywords: intl)
Attachments
(1 file)
732 bytes,
text/plain
|
Details |
If the subject of a message contains encoded ASCII code and Japanese code, Mozilla cannot decode it. For example, $B$"$$$&$($*(B(abcdefghijklmnopqrstuvwxyz) Mew(Mailer for emacs) encodes this subject as below: Subject: =?iso-2022-jp?B?GyRCJCIkJCQmJCgkKhsoQihhYmNkZQ==?= =?us-ascii?Q?fghijklmnopqrstuvwxyz)?= Mozilla can't decode it. But NC4.7 can decode it.
Reporter | ||
Comment 1•24 years ago
|
||
Comment 2•24 years ago
|
||
change platform to ALL and mark this as P3 moz0.9.1
Updated•24 years ago
|
QA Contact: momoi → ji
Comment 3•24 years ago
|
||
Change QA contact to ji.
Comment 4•24 years ago
|
||
MIME decoder is being rewritten by jgmyers@netscape.com, reassign to him.
Assignee: nhotta → jgmyers
Target Milestone: mozilla0.9.1 → ---
Assignee | ||
Comment 6•24 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 7•24 years ago
|
||
The fix was done by changed the MIME decoder to do a charset conversion and always returns UTF-8 string. There are a couple of issues appeared by that implementation. * By always returning UTF-8, there is no way for the caller to correct mislabeled charset headers (e.g. ISO-8859-1 labeled Big5, US-ASCII labeled Shift_JIS). * There are places which optimizes charset conversions in libmime. By doing charset conversion inside MIME decoder, we cannot take advantage of them. The first issue caused a regression of bug 65277. I reopen this bug and propose a better implementatiuon. * Do the UTF-8 conversion only if the header contains multiple charsets. That can be done by pre-parsing the header to check charsets in the header. This is a litter overhead but avoiding the charset conversion inside the decoder helps performance gain.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 8•24 years ago
|
||
A better approach would be to pass an override charset down to the encoded-word decoder. Converting to UTF-8 only in the multi-charset case requires a 2-pass decoder and prevents charset override in the multi-charset case. What charset conversion optimizations are you talking about? The only one I know of is the one which no-ops conversions between UTF-8 and US-ASCII. I believe this bug should remain closed fixed and override work be done on bug 65277.
Comment 9•24 years ago
|
||
I think my proposal has minimum impact for the caller (and less chances of another regression) because it is basically requesting to back to the old behavior. I am not sure if anybody care about overriding multiple charsets case. In fact, multiple charset in a header itself is rarely seen. So the other option could be no support for multiple charset at all then no need for the pre-parsing. Anyway, please try whatever you think it's right to fix the problem but please test to prevent another regression. About the optimization, we cache the charset convertors which saves extra createintance and getservice.
No longer blocks: 68344
Assignee | ||
Comment 10•23 years ago
|
||
This code is still working. Override work is being done as bug 65277
Status: REOPENED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Comment 11•23 years ago
|
||
The testing mail that the original reporter attached does't show in the folder. I'd like to reopen this bug.
Assignee | ||
Comment 12•23 years ago
|
||
I suggest you wait another day. You may be seeing bug 75390.
Comment 13•23 years ago
|
||
It doesn't show with previous builds, like 04/02 build either. I'll wait until tomorrow anyway.
Comment 14•23 years ago
|
||
The attached testing mail doesn't show up either with today's trunk build (04/11). Reopened the bug.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 15•23 years ago
|
||
Once I added a "From " line to the test case, it worked for me.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
Comment 16•23 years ago
|
||
The original testcase does include the "From:" line. How did you edit it to get it work?
Assignee | ||
Comment 17•23 years ago
|
||
"From ", not "From:".
Comment 18•23 years ago
|
||
Yes. it appears correctly. Marked it as verified.
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•