Closed Bug 23111 Opened 25 years ago Closed 25 years ago

Filename gets lost when sending mail with attachment with int. chars in the filename

Categories

(MailNews Core :: Internationalization, defect, P3)

x86
Windows 98
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: nhottanscp)

Details

Attachments

(2 files)

I attach a file called "זרו.jpg" with Mozilla and sends it. The Mime part is now: Content-Type: image/jpeg; name="=?ISO-8859-1?Q?jpg?=" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="=?ISO-8859-1?Q?jpg?= The filename got lost.... Using build 2000010416
Status: NEW → ASSIGNED
Adding rhp to cc.
When we apply MIME encode to the file name, we get URI escaped string and unescape it. But it also needs charset conversion from platform file system to UTF-8. MIME encoder requires an input string in UTF-8. We have the data loss because the encoder expecting UTF-8 while the input string is some other charsets. So we need to get the platform charset and convert the string to UTF-8.
All I need was the file name "nscpnáo.gif", didn't have to attach the image...
Oe more thing to keep in mind.
Summary: Filename gets lots when sending mail with attachment with int. chars in the filename → Filename gets lost when sending mail with attachment with int. chars in the filename
Adding mscott to cc as this may be related to 23109.
Target Milestone: M13
Attached patch patch file for the fix (deleted) — Splinter Review
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
checked in, I tested latin1 and japanese file names.
marina, could you check this for Latin 1 names? I'll check for JPN names.
** Checked with 1/24/00 Win32 build ** On Japanese Windows, I can see file names in Japanese and save them also through a save as dialog. On US Windows-NT, I was also able to see the file name in Latin 1 accented characters but as I went to save this file the characters for the Save as dialog's suggested name were incorrect. We are probably not sending the data in system charset. Should we file a separate bug for this?
I guess this bug is only about whether or not the filename gets deleted in the Content headers. That is no longer the case. I'll mark this fix verified and deal with the data charset problem under US Windows in another bug.
Status: RESOLVED → VERIFIED
The dialog problem has been filed separately as 24864.
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: