Closed Bug 59798 Opened 24 years ago Closed 20 years ago

Japanese autodetect is not working for UTF-8 mail(?) & attachments

Categories

(MailNews Core :: Internationalization, defect, P3)

x86
Windows NT
defect

Tracking

(Not tracked)

RESOLVED WORKSFORME
Future

People

(Reporter: marina, Assigned: nhottanscp)

References

Details

(Keywords: intl)

Attachments

(1 file)

**** observed with 2000-11-08 MN6 build ****
 Steps to reproduce:
 (it is not a mail specific bug, it could be reproduced with any web page by
removing a meta tag)
- compose a mail message (plain, html) in JA ;
- send it out using UTF-8;
- get message, turn autodetect for JA on;
- open View source;
//note: the JA text shows up incorrectly (it works for Shift-jis)
same problem is observed when forwarding a message sent in UTF8 and opening an
attachment from the envelope: the JA text is not displaying correctly
I would like to propose to split 2 issues in this bug.

1. View source is not displayed correctly under Auot-Detection.
2. Unlabled attachments are not displayed correctly. 

For view source, I think we should settle the spec we would like
first. We are not correctly reflecting the "current" charset
as we load the message into the view source window.
Instead of applying "auto-detection" to the view source window,
we should first of all correctly reflect the charset info in
the current message. This way if we apply auto-detection, 
it would have applied to the message itself, not to the source.

I think we should deal with problem #2 in this bug.
The problem #1 is addressed in Bug 40613 and Bug 49230.
Let's fix these first -- the current behavior of applying
Auto-detection to the view source window is not desirable.

I changed the summary above so that the issues are 
restricted to mail body parts.
Summary: Japanese autodetect is not working for UTF-8 encoding → Japanese autodetect is not working for UTF-8 mail(?) & attachments
Interestingly, even though Japanese Auto-detect
fails on some UTF-8 data in attachments (without MIME
charset info), Detect-All seems to work much better --
in fact without an error in my short test case attached below.
I wonder if this is not essentially the same problem as
EUC-JP detection failure in Mail only. Given the small amount of data it
processes for each chunk -- unlike Browser pages -- I wonder if
this methodology itself is at fault. 
Keywords: intl
Mass change to bugs filed by marina --> QA contact to marina.
thanks!
QA Contact: momoi → marina
again, this is the same problem as other auto detect bug with mail. The real 
solution is to change the mail/news code to call the stream base auto detector 
instead of using the string base auto detector.
nhotta- I really think there are no way we can address this without change the 
mailnews arch.
Assignee: shanjian → nhotta
Depends on: 12481
Target Milestone: --- → Future
Status: NEW → ASSIGNED
naoki,
reading frank's comments on this bug,how realistic is to fix this? 
It has been improved by Shianjian's check in but not sure this particular one
got resolved.
This bug no longer manifests, insofar as Autodetect=Japanese (as well as 
Autodetect=Universal) detect the attachment to this bug as Unicode (UTF-8).
This works whether opening the file directly in a browser or displaying it as an 
inline attachment to a (ISO-2022-JP) mail message.

xref bug 236866.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: