Closed Bug 21743 Opened 25 years ago Closed 24 years ago

4.x vCard with Japanese chars is garbled.

Categories

(MailNews Core :: Internationalization, defect, P3)

All
Linux
defect

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 38901

People

(Reporter: ji, Assigned: nhottanscp)

Details

Attachments

(6 files)

The vCard that is created with 4.x using Japanese chars for the firstname and lastname is garbled on 5.0. Steps of repro: 1. Create a vCard using 4.7, enter Japanese chars for the firstname and lastname. 2. on 4.7, compose a mail with the vCard as an attachemnt and send it to a testing account on 5.0. 3. Use 5.0 to view the mail, the firstname and lastname on the vCard is displyed garbled in the message view pane.
Status: NEW → ASSIGNED
Target Milestone: M15
Please ignore the first attachment. The second attachment is the source for the mail with Japanese vCard.
The part has a charset label "iso-2022-j" but the actual Japanese text are encoded in Shift_JIS with QP. 4.7 generates incorrect vCards for Japanese. The auto charset detection is not used because the part has a charset label. We can explicitly set a charset (to Shift_JIS) after we enable charset menu (override) but the main body cannot be seen because it's usually JIS (not Shift_JIS).
Yes. This has been a known bug in 4.x. Are we at least decoding QP-encoded strings?
QP decoding is applied according to the attached screen shot.
Adding rhp to cc.
Hi Guys, I did some debugging on this one and I think that I addressed a problem that could have existed. We didn't seem to be picking up the actual Content-Type header from the mime part, so we probably never applied charset conversion. I've attached a patch here to address this problem. Now, it still won't fix the problem if the part is labeled incorrectly. I'm really not sure how we deal with that situation? Let me know and I will checkin this first fix. - rhp
Unfortunately, some of our own Communicator versions send out incorrect charset info with vCard. I think this is a special situation with Japanese (and possibly Russian) where the mail charset could be different from the one used for OS (and thus for vCard). Either we come up with a way to detect the charset in such a case or we need to have Charset override take care of it. In 4.x, we use auto-detection and ignore the charset info for the vCard, it seems. And that is why it probably works. Given the widespread nature of this problem, I'm not sure if we shouldn't be doing the same thing for vCard in 5.0.
Well, I've done the code to handle the case of the correctly labled vCard. I'll leave it to Naoki to handle the other case. - rhp
Since the incoming data from 4.x is incorrect, there is no clean way of fixing this. I think we can check the part charset then if "ISO-2022-JP" then 1) apply auto detecion for each field or 2) apply Shift_JIS conversion to the fields which are known to be containing incorrect data.
QA contact --> ji
QA Contact: momoi → ji
move to M16
Target Milestone: M15 → M16
checked in
checked in
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Looks like there is an unresolved problem with Phone and Fax numbers. I'll attach an image for the remaining problem.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
There is a bug filed specific to phone and fax numbers. *** This bug has been marked as a duplicate of 38901 ***
Status: REOPENED → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → DUPLICATE
Thanks! I was looking for that bug to see if it had been fixed. Looks like we are targeting nsbeta3. Xianglan, this is yours.
Verified it as a dup.
Status: RESOLVED → VERIFIED
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

Creator:
Created:
Updated:
Size: