Closed Bug 127612 Opened 23 years ago Closed 14 years ago

Need a better handling for multipart/alternative mails when the body and the header have different charsets

Categories

(MailNews Core :: Internationalization, defect)

Product:
MailNews Core
Component:
Internationalization
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 378008

People

(Reporter: u32858, Assigned: nhottanscp)

Details

(Keywords: intl) 

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205
BuildID:    2002020511

Subject is corrupted when I reply to an iso-2022-jp email. It displays fine. Its
an outlook HTML email. Forward keeps the title ok and email. So bug is specific
to "reply"

Subject: =?iso-2022-jp?B?UmU6IFtjanBjaGF0XSAbJEIkXiRfJEEkYyRzJE4/Nz1JJVElRiUjGyhC?=
	=?iso-2022-jp?B?GyRCPEw/PxsoQg==?=



Reproducible: Always
Steps to Reproduce:
1.Get an email in iso-2022-jp click reply
2.
3.

Actual Results:  Re: Re: [cjpchat] $B$^$_$A$c$s$N?7=I%Q%F%#(B$B<L??(B

Expected Results:  Re: [cjpchat] まみちゃんの新宿パティ写真

From - Mon Feb 25 13:50:08 2002
X-UIDL: 2cQ"!+J]!!@^\"!M-F"!
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000

	Mon, 25 Feb 2002 13:44:30 +0900 (JST)
Message-ID: <00a601c1bdb5$98202be0$670c14ac@brianhorhq>
To:  
References: <3C79BA1A.9010102@jguk.org>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
From: "Brian Ho" <brianho@ssac.yamatake.co.jp>
X-Yahoo-Profile: hobkt2000
MIME-Version: 1.0
Mailing-List: list cjpchat@yahoogroups.com; contact cjpchat-owner@yahoogroups.com
Delivered-To: mailing list cjpchat@yahoogroups.com
Precedence: bulk
List-Unsubscribe: <mailto:cjpchat-unsubscribe@yahoogroups.com>
Date: Sun, 24 Feb 2002 22:33:07 -0600
Subject: =?iso-2022-jp?B?UmU6IFtjanBjaGF0XSAbJEIkXiRfJEEkYyRzJE4/Nz1JJVElRiUjGyhC?=
	=?iso-2022-jp?B?GyRCPEw/PxsoQg==?=
Reply-To: cjpchat@yahoogroups.com
Content-Type: multipart/alternative;
 boundary="----=_NextPart_000_00A0_01C1BD83.3B6C8E20"
X-UIDL: 2cQ"!+J]!!@^\"!M-F"!
Status: U



------=_NextPart_000_00A0_01C1BD83.3B6C8E20
Content-Type: text/plain;
	charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

So anyone down for part 2 sometime soon?  I realized when I got home I coul=
d have at least lasted another good 2 hours. Next time I will guarantee an =
even better show. Thanks Mami for finding and reserving us a restaurant!

------=_NextPart_000_00A0_01C1BD83.3B6C8E20
Content-Type: text/html; charset=US-ASCII
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-2022-jp" http-equiv=Content-Type>
<META content="MSHTML 5.00.2920.0" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>

<FONT face=Arial size=2>So anyone down for part 2 sometime 
soon?&nbsp; I realized when I got home I could have at least lasted another good 
2 hours. Next time I will guarantee an even better show. Thanks Mami for finding 
and reserving us a restaurant!</FONT>

<br>
<tt>
<BR>
</tt>
<br>

<br>
<tt>Your use of Yahoo! Groups is subject to the <a
href="http://docs.yahoo.com/info/terms/">Yahoo! Terms of Service</a>.</tt>
</br>

</BODY></HTML>

------=_NextPart_000_00A0_01C1BD83.3B6C8E20--
The mail is not recognized as iso-2022-JP mail, the charset is marked as
ISO-8859-1, so reply mail has a garbled subject. After manually correcting the
charset to iso-2022-jp for the orginal message, reply won't have this problem.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: intl
Hardware: PC → All
this is an old build, could that be that it was pulled before the reloading on
reply problem was fixed?
I saw the same thing on toda's build (02/25).
The testing mail is a multipart mail. The 1st part has charset specified as
iso-2022-jp while the 2nd part is specified as us-ascii. It seems our charset
menu takes the 2nd one.
We used to have problems with charset reflection for multiplart/alternative
mails (bug 46881). It seems the fix for bug 46881 only deals with mails that
have the same charset for all the parts. If the charsets are different for
different parts, I think the charset menu should reflect the first one.
We try to use the last part if multipart/alternative.

http://www.ietf.org/rfc/rfc2046.txt
see
5.1.4.  Alternative Subtype
Status: NEW → ASSIGNED
So cannot change the multipart handling.
We may need a better handling when the body and the header have different charsets.
OS: Linux → All
Target Milestone: --- → mozilla1.2
Why does it detect it as ISO-8859-1? It should use iso-2022-JP as that is all
that is mentioned in the email. Even the subject line has iso-2022-JP preciding it.

Subject: =?iso-2022-jp?B?UmU6IFtjanBjaGF0XSAbJEIkXiRfJEEkYyRzJE4/Nz1JJVElRiUjGyhC?=
	=?iso-2022-jp?B?GyRCPEw/PxsoQg==?=

My default charset is UTF-8


JG




> ------- Additional Comments From ji@netscape.com  2002-02-25 10:25 -------
> The mail is not recognized as iso-2022-JP mail, the charset is marked as
> ISO-8859-1, so reply mail has a garbled subject. After manually correcting the
> charset to iso-2022-jp for the orginal message, reply won't have this problem.
> 
It's actually "US-ASCII" which is specified in the last part of the message.
Content-Type: text/html; charset=US-ASCII

OK, i see what you mean now. So the MIME says US-ASCII but the actual html says
JP and as the subject was specified as JP it should still show that correctly.
it seems this 1 occurance of US-ASCII overides the rest


------=_NextPart_000_00A0_01C1BD83.3B6C8E20
Content-Type: text/html; charset=US-ASCII
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-2022-jp" http-equiv=Content-Type>


Hello,

Another japanese conversion example, tested in 2002022700.

Displays the subject correctly, (iso-8859-1 highlighted on charset menu)

But clicking reply leaves a subject like this

Re: $B$4O"Mm(B

------- origional email

Subject: =?ISO-2022-JP?B?GyRCJDRPIk1tGyhC?=
Message-ID: <200203061212496873.507@swan.sanyo.co.jp>
X-Mailer: StarOffice/MailGateway[5.1]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-UIDL: id)"!)=$!!2:5"!_X[!!
Status: U

Hi. xxxxxx

xxxxxxxx



That's because charset menu reflects the charset info in the mail body. In this
case (charset in the header is different with the one in the mail body), you can
set proper folder charset from Edit | Property or manually select the charset
only for one-time view. After this is done, reply shouldn't have any problem for
the subject.
Hi Ji,

yes I agree, this is a workaround, but in most cases when the subject has
Subject: =?iso-2022-jp?B?Um

thats a clear indication that the email is not US-ASCII as its defined.

I have yet to get an email where it has a subject in one language and the
message in another (correctly) 

as this is the only occuracene of this bug with subject japanese and message
US-ASCII overfuling the sujbect could the subject be set to override the body
Content-Type please?

JG



> set proper folder charset from Edit | Property or manually select the charset


I can not find Edit | Propery, only View ->charset
Sorry, it's Edit | Folder Properties
Summary: Garbled subject when replying to iso-2022-jp email → Need a better handling for multipart/alternative mails when the body and the header have different charsets
As far as I see, the problematic behaviour here is caused by what I described in
bug http://bugzilla.mozilla.org/show_bug.cgi?id=115096, which did not seem to
have generated much reaction at the time.

My analyses is that the charset of the body overwrites the charset that should
be used for the header when replying.

I'll check the reaction, but I think I will mark 115096 as a duplicate of this one.
Target Milestone: mozilla1.2alpha → ---
Product: MailNews → Core
Product: Core → MailNews Core
QA Contact: ji → i18n
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.