Closed Bug 23109 Opened 25 years ago Closed 25 years ago

Attachments with int. char doesn't show correct

Categories

(MailNews Core :: Internationalization, defect, P3)

Product:
MailNews Core
Component:
Internationalization
Platform:
x86
Windows 98
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: bugzilla)

Details

Attachments

(1 file)

Mime info about int chars in filename turning into japanese
2.54 KB, text/plain
Details 
I have a mail with attached jpeg file called "זרו.jpg".
In Mozilla this attachment is shown as "%C3%A6%C3%B8%C3%A5.jpg"
I think there's missing some decoding of int. chars.
Using build 2000010416
This bug also show when attaching files like "זרו.jpg" with Mozilla. Then in the
attachments window of the compose the filename is:
"file://C|/TEMP/%E6%F8%E5.jpg"
Status: NEW → ASSIGNED
Adding rhp to cc.
marina, we should check this out. Do we have another bug like this?
The first viewing problem is showing the data in UTF-8 and URI escaped.
The compose problem, the data in platform charset (e.g. ISO-8859-1) and URI
escaped.
Unescape and possibly charset conversion is required.
Using today's build (2000010608),
the first problem now URI escaped but showing is not correct (showing raw UTF-8
data).
the second problem does not occure (at least for Latin1 data).
I will investigate after I update to the latest tree.
i've tried this out today (with 2000-06M13 build). In the compose window the
attachment look fine :"a-pläçe.gif" but when i'm getting the mail with attached
file and click on the clip icon this is what i see : a-ple.gif (instead of
a-pläçe.gif )
That's may be the sending problem 23011 if you sent it by 5.0.
Adding mscott to cc.
Scott, this bug has two problem. The behavior of the first problem changed since
yesterday. The string now unescaped but still needs UTF-8 to UCS2 conversion. Do
you think anything related to your change?
Naoki, I'm not converting the attachment name that appears in the attachment
menu popup in the message header from UTF-8 to unicode like I am with other mail
headers.

I forgot to do this. Is this the only problem that's left with this bug? I'll
fix that right now.

As part of my landing yesterday I did fix a problem where the attachment names
were being shown escaped. I noticed that too.

So I'm thinking if I just add the code to decode the attachment name we should
be able to mark this bug as fixed yes?
Assignee: nhotta → mscott
Status: ASSIGNED → NEW
I think you're right. Let me reassign this to you.
Qa verification also needs with non Latin1 file names (e.g. Japanese).
Status: NEW → ASSIGNED
Okay, I believe I have the fix for this. I now convert the attachment name to
unicode before broadcasting it to the xul overlay.

Naoki/Kat, can you send me a message with an attachment that has 8bit data in
the attachment name so I can verify this before I check it in?
I just checked in code to convert the attachment name to unicode before setting
it in the attachment menu popup. Now attachment names with intl characters shows
up just fine.

I did have one failure however, Kat sent me an attachment with japanese
characters in the attachment name. The mime converter failed to convert this
UTF-8 string to unicode. It returned ?? instead.
I pulled the Scott's changed and I can see the Japanese file name. Maybe because
of the font availability on Scott's machine. So the first problem is fixed.
I tried the second problem with my NT-J. The file name is unescaped as Latin1
but it's showing garbage.
Naoki, just some I'm clear, what was the second problem that failed for you.
I'm forgetting how to write. That should have read:
"just so I am clear"
The second problem is about composing as described in the report of gemal in
2000-01-05 03:59.
When attaching a file, the file name view in the top right pane, I see Japanese
file name is garbage.
Okay so I've fixed the msg display problem. We need someone in compose to decode
the name. Ducarroz or rhp??
Assignee: mscott → ducarroz
Status: ASSIGNED → NEW
Target Milestone: M13
lokks like it would be me. Reassign to myself.
It it is currently working for Latin1 but not Japanese. Let me know if you want
me to test once you got a fix (I have WinNT-J).
Status: NEW → ASSIGNED
I have another variant of the problem where I again are getting japanese chars.
I took a normal mail with an attachment which contained int chars. I forwarded
it with Outlook Express and got japanese chars when reading the forwarded mail
in Mozilla

I've attached the mail's mime info.

Build 2000011108
Regarding the Japanese problem gemal mentioned, we had a simillar problem in
vCard (interpreted three Latin1 chars as one UTF-8 character), see bug 23324.
You can reproduce the problem using a US Mac as the MacOS file Mgr doesn't use Latin-1 as charset.
I have a fix. I will probably check it in tomorrow afternoon
Fixed and checked in.

QA, the fix alter the previous fix for bug 23111, therefore you may consider
re-testing it. I have also fix a problem when you forward inline a message with
attachment which file name use 8bits characters.

Remark: now, we display only the file name and not anymore the full path in the
attachment pane (see bug 23331)
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
mark it as fixed for real!
marina, could you chck this for Latin 1 names? I'll check for JPN names.
I tried a Japanese named file as attachment and had no problem
showing it with 1/24/00 Win32 build. 
Marina, try Latin 1 names and in particular gemals's 
example. If it works, please mark it verified.
As I reported in another Bug 23111, the Latin 1 names are
displayed correctly but the name which sent to Save dialog
as the suggested name does not show correctly under US Windows.
I tried gemal's original file name "זרו.jpg".

Should we file a separate bug for this part?
Naoki informs me that there is a dialog Bug 24864.
In that case, we can mark this fix verified.
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: