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"

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?

I think you're right. Let me reassign this to you. Qa verification also needs with non Latin1 file names (e.g. Japanese).

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??

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).

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)

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.