Attachments with int. char doesn't show correct



19 years ago
10 years ago


(Reporter: bugzilla, Assigned: bugzilla)


Windows 98

Firefox Tracking Flags

(Not tracked)



(1 attachment)



19 years ago
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

Comment 1

19 years ago
This bug also show when attaching files like "זרו.jpg" with Mozilla. Then in the
attachments window of the compose the filename is:


19 years ago

Comment 2

19 years ago
Adding rhp to cc.

Comment 3

19 years ago
marina, we should check this out. Do we have another bug like this?

Comment 4

19 years ago
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
Unescape and possibly charset conversion is required.

Comment 5

19 years ago
Using today's build (2000010608),
the first problem now URI escaped but showing is not correct (showing raw UTF-8
the second problem does not occure (at least for Latin1 data).
I will investigate after I update to the latest tree.

Comment 6

19 years ago
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 )

Comment 7

19 years ago
That's may be the sending problem 23011 if you sent it by 5.0.

Comment 8

19 years ago
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?

Comment 9

19 years ago
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

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?


19 years ago
Assignee: nhotta → mscott

Comment 10

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


19 years ago

Comment 11

19 years ago
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?

Comment 12

19 years ago
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.

Comment 13

19 years ago
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.

Comment 14

19 years ago
I tried the second problem with my NT-J. The file name is unescaped as Latin1
but it's showing garbage.

Comment 15

19 years ago
Naoki, just some I'm clear, what was the second problem that failed for you.

Comment 16

19 years ago
I'm forgetting how to write. That should have read:
"just so I am clear"

Comment 17

19 years ago
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.

Comment 18

19 years ago
Okay so I've fixed the msg display problem. We need someone in compose to decode
the name. Ducarroz or rhp??


19 years ago
Assignee: mscott → ducarroz
Target Milestone: M13

Comment 19

19 years ago
lokks like it would be me. Reassign to myself.

Comment 20

19 years ago
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).


19 years ago

Comment 21

19 years ago
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

Comment 22

19 years ago
Created attachment 4168 [details]
Mime info about int chars in filename turning into japanese

Comment 23

19 years ago
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.

Comment 24

19 years ago
You can reproduce the problem using a US Mac as the MacOS file Mgr doesn't use Latin-1 as charset.

Comment 25

19 years ago
I have a fix. I will probably check it in tomorrow afternoon

Comment 26

19 years ago
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)


19 years ago
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 27

19 years ago
mark it as fixed for real!

Comment 28

19 years ago
marina, could you chck this for Latin 1 names? I'll check for JPN names.

Comment 29

19 years ago
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.

Comment 30

19 years ago
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?

Comment 31

19 years ago
Naoki informs me that there is a dialog Bug 24864.
In that case, we can mark this fix verified.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.