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)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 162361
People
(Reporter: EliteBadger, Assigned: mscott)
Details
Attachments
(1 file)
(deleted),
image/png
|
Details |
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.
Comment 3•19 years ago
|
||
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
Comment 4•19 years ago
|
||
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 → ---
Comment 5•19 years ago
|
||
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 ago → 19 years ago
Resolution: --- → DUPLICATE
Updated•19 years ago
|
OS: other → Windows 2000
Comment 6•19 years ago
|
||
Apologies for the resolving as duplicate.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Comment 7•19 years ago
|
||
Grrr, collisions.
Sorry for the bugspam
*** This bug has been marked as a duplicate of 162361 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago → 19 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.
Comment 9•19 years ago
|
||
(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.
Reporter | ||
Comment 10•19 years ago
|
||
Oh, thanks for the clarification.
You need to log in
before you can comment on or make changes to this bug.
Description
•