Closed Bug 315353 Opened 19 years ago Closed 19 years ago

Cannot process attachments with Unicode characters in filename

Categories

(Thunderbird :: Message Compose Window, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 162361

People

(Reporter: EliteBadger, Assigned: mscott)

Details

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8) Gecko/20051025 Firefox/1.5 Build Identifier: 1.5 rc1 (version 1.5 (20051025) in the about box) When attaching a file to an e-mail that uses Unicode (ex. Japanese or Chinese characters), the characters are converted to ? and the attachment cannot be sent (since Thunderbird looks for a file called ??????? instead of whatever it should have been called). Reproducible: Always Steps to Reproduce: 1. Locate a file with a name using Unicode characters 2. Attach that file to an e-mail message 3. Note that the file appears as (example) ???????.txt 4. Attempt to send the message 5. Note that the message cannot be sent because Thunderbird cannot find ???????.txt. Actual Results: "Sending of message failed. Unable to open the temporary file H:\Desktop\20050614\???????.txt Check your 'Temporary Directory' setting." [OK] Expected Results: Sent the message. My OS is Windows XP x64 edition, which I don't think matters, but it wasn't an option in the "Operating system" dropdown...
Related to bug 243506?
>Related to bug 243506? Apparently so. Sorry I didn't find it when searching the bug list.
If you have a look at that bug its a duplicate of a duplicate which resolves back to Bug #229872 which is marked FIXED in 2004. Are we sure it is a dupe? *** This bug has been marked as a duplicate of 229 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
This is a dupe of bug 162361. Bug 229872 is about attachements whose names can be represented in the file system character encoding (but not in ASCII). This bug is about names that cannot be represented in the file system character encoding. On Mac OS X and modern Linux (where UTF-8 is used by default), this is not an issue.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Examples: Chinese/Japanese/Arabic/Hebrew names on French/English Windows. Hebrew/Arabic names on CJK Windows, etc. *** This bug has been marked as a duplicate of 162361 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → DUPLICATE
OS: other → Windows 2000
Apologies for the resolving as duplicate.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Grrr, collisions. Sorry for the bugspam *** This bug has been marked as a duplicate of 162361 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → DUPLICATE
Hello, You said: >This bug is about names that cannot be represented in the file system character encoding. I don't think that's correct. Under my English version of XP x64 the file I was trying to send was named using Chinese characters, and the filesystem seemed to recognize it just fine.
(In reply to comment #8) > >This bug is about names that cannot be represented in the file system character > encoding. > > I don't think that's correct. Under my English version of XP x64 the file I was > trying to send was named using Chinese characters, and the filesystem seemed to > recognize it just fine. > Sure, NTFS has no problem at all with any character in the unicode. What I meant was Mozilla's notion of the file system character encoding. Currently, we don't use Unicode APIs to access NTFS. Instead, we use 'ANSI' APIs that don't support Chinese on Enlgish Windows. We should switch to Unicode APIs, which is what bug 162361 is about.
Oh, thanks for the clarification.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: