Closed Bug 263254 Opened 20 years ago Closed 19 years ago

Can't reply to Japanese message correctly

Categories

(MailNews Core :: Internationalization, defect)

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

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: nomura, Assigned: smontagu)

Details

Attachments

(1 file)

test message file to reply
4.20 KB, application/x-zip-compressed
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041006
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041006

When replying to Japanese message ( ISO-202-JP ), some quoted characters such as
株式会社
取るべき
(These are japanese characters, you might not see them)
can't be displayed correctly.
This symptom has occured from Mozilla 1.8 until current nighty build, but not in
1.7.
If it is known problem and will be fixed in beta or release version, there is no
problem. However, this fuction is vital when Japanese people use the alpha
version of Mozilla for testing.


Reproducible: Always
Steps to Reproduce:
1. unzip the attached file. 
2. copy it to mozilla Mail folder
3. launch mozilla
4. choose the message in test1 folder.
5. replay to the message and change to: address to yourself.
6. receive the message and see it.

Actual Results:  
株式会璽献磧楮戮�
(These are Japanese characters)

Expected Results:  
株式会社テムザック　事業戦略部マネージャー　檜山 康明
(These are Japanese characters)
It requires to display Japanese characters.
Please report your settings in
  Preferences | Mail | Composition
for
  Character Encoding [dropdown]
  [] Always use default character encoding in replies
Japanese ( ISO-2022-JP ) is set for Character Encoding.
It works fine in Mozilla 1.7 with the same account, the same settings.
With the sample message, I am not seeing a problem with 1.7.2 or with 1.8a4-1005 
-- but I don't read Japanese and could easily have missed it.  Is there a 
particular point in the message where I should be looking?
This problem is not be seen with 1.7.2 but must be seen with 1.8a4-1005.
You must look at the following lines.

Line 32   株式会璽爛廛軋膺�(B 優喜氏
Line 35   株式会��(B 情報保護法施行を控え、企業が�(B 商務情報政策局情報経済課 課長補
Line 48   大阪大学大学院工学研究科　知能・機能創生工学専攻教璽�砲弔い董廖崔羮�覿
箸�(B
Line 52   株式会璽献磧楮戮�

( space line must be counted for line number )

It's very difficult to figure out what you're pasting into Bugzilla when you use 
different character sets.  The characters pasted in the original report were 
apparently encoded with UTF-8 (Unicode) -- which is just fine -- but the 
characters pasted into comment 5 are in something else -- perhaps ISO-2022-JP, 
altho I can't find any match in the test message for those characters when I 
look at it like that.

Anyway: I found a line with the characters shown in the "Actual Results".  It's 
near the bottom of the original message, in the section just before the sig, in 
the paragraph that begins with a standard numeral "4."  It's the second line of 
that paragraph.

That line is quoted without error in the reply, on my Win2K system, 1.8a4-1006.  
The original mail is shown as encoded with ISO-2022-JP, and so is the reply.
Comment #5 is Shift_JIS code, sorry.
Reproduce steps are little bit incorrect.
1. - 5. correct
6. delete some quoted lines in the middle of message body.
7. insert some Japanese characters into the deleted position.
   Note. quoted message is ISO-2022-JP, but insert character might be  UTF-8 ?
8. change to: address to yourself and sumbit
9. receive the message and see it.
   Below the inserted lines, some Japanese characters were not converted
correctly from UTF-8 to ISO-2022-JP or vice versa , I suppose.
(In reply to comment #7)
>    Note. quoted message is ISO-2022-JP, but insert character might be  UTF-8 ?
> [...]
>    Below the inserted lines, some Japanese characters were not converted
> correctly from UTF-8 to ISO-2022-JP or vice versa , I suppose.

In the editor, all the characters are stored internally as Unicode (16-bit wide 
characters, I believe).  They are converted from whatever the original encoding 
is when the Reply is initialized, and converted to whatever the outgoing 
encoding is.

It's possible to enter characters that do not have a 2022 encoding, but if you 
did that you'd get a prompt when you tried to send the message, telling you that 
the characters were not supported by the selected encoding and offering to 
convert to Unicode.


The original message is HTML; is the reply as HTML or as plain text?  I'm not 
sure it matters; I've tried reproducing the problem with the "delete some lines" 
technique and I'm still seeing the text quoted precisely.
is the reply as HTML or as plain text? <-- Plain text.

Can't you reproduce the problem ?

Try again very simple method.
1. Choose the message and click "reply"
2. Insert some ascii characters such as "qqqqqqqq" at the top of the message.
3. Submit
5. Receive the message
5. You will see incorrect Japanese characters,
株式会��(B 情報保護法施行を控え、企業が�(B 商務情報政策局情報経済課 課長補佐

This must be,
       株式会社日本システムディベロップメント小松 昭隆氏
講演3：個人情報保護法施行を控え、企業が取るべき対策
　　　　講師 ： 鳥丸 忠彦氏

　　　　経済産業省 商務情報政策局情報経済課 課長補佐

  It is located just above the line including 'crm-kansai@personalize.co.jp'. 
I haven't yet tried the latest 'recipe' for reproducing the bug (I have tried
othee methods and couldn't reproduce the bug). 

I still cannot reproduce the problem, following the instructions in comment 9.  
I tried resetting the composition preference to "Place reply above quote" 
thinking that might have been hinted at by the instruction "Insert some ascii 
characters ... at the top of the message" but there was no difference in 
behavior.

Are there any extensions installed in your Mozilla build (such as Enigmail) 
which might affect composition?

Is this a JA-localized version of Mozilla that you're running?
Tomoo Nomura, is the broken text seen in the composition window, or only after 
the message has been transmitted?  If only after transmission, does it appear 
incorrectly in the copy of the message in the Sent folder, or only in the 
version that's actually gone thru an SMTP server?

Possibly a regression from the patches in bug 260725 and bug 234958?

xref reporter's bug 263797.
The broken text is not seen in the composition window, but is seen in both Inbox
and Sent folder.

> Are there any extensions installed in your Mozilla build (such as Enigmail) 
which might affect composition?     <-- No.

> Is this a JA-localized version of Mozilla that you're running?   <-- No.
Product: MailNews → Core
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

It seems to be fixed in Seamonkey 1.1a Gecko/20050923 Linux.
PLS close it.
=> WFM per reporter's comment 15,
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: