Attachments with int. char doesn't show correct

VERIFIED FIXED in M13

Status

MailNews Core
Internationalization
P3
normal
VERIFIED FIXED
18 years ago
9 years ago

People

(Reporter: Henrik Gemal, Assigned: Jean-Francois Ducarroz)

Tracking

Trunk
x86
Windows 98

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

18 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
(Reporter)

Comment 1

18 years ago
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"

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 2

18 years ago
Adding rhp to cc.

Comment 3

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

Comment 4

18 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
escaped.
Unescape and possibly charset conversion is required.

Comment 5

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

Comment 6

18 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

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

Comment 8

18 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

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

Updated

18 years ago
Assignee: nhotta → mscott
Status: ASSIGNED → NEW

Comment 10

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

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 11

18 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

18 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

18 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

18 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

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

Comment 16

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

Comment 17

18 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

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

Updated

18 years ago
Assignee: mscott → ducarroz
Status: ASSIGNED → NEW
Target Milestone: M13
(Assignee)

Comment 19

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

Comment 20

18 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).
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
(Reporter)

Comment 21

18 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
(Reporter)

Comment 22

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

Comment 23

18 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.
(Assignee)

Comment 24

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

Comment 25

18 years ago
I have a fix. I will probably check it in tomorrow afternoon
(Assignee)

Comment 26

18 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)
(Assignee)

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 27

18 years ago
mark it as fixed for real!

Comment 28

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

Comment 29

18 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

18 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

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