Closed Bug 285073 Opened 20 years ago Closed 19 years ago

Attaching a file with its name containing a multibyte character whose trailing byte is backslash doesn't work

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: nomura, Assigned: jshin1987)

References

Details

(Whiteboard: intl) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050228
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050228

When attaching a Japanese UTF-8 named attachement, it can't be displaied correctly.

Reproducible: Always

Steps to Reproduce:
1.open composer window
2.choose any Japanese UTF-8 named files
3.

Actual Results:  
Show invalid characters

Expected Results:  
Show Japanese characters correctly

Is it related to bug #263797 ?
Related to Bug 274264? (Or to Bug 215949??)
Assignee: composer → sspitzer
Component: Composer → MailNews: Composition
Product: Mozilla Application Suite → Core
Version: unspecified → Trunk
The description of this bug is pretty poor -- but I suspect this is bug 234681.
Tomoo Nomura, please mark this bug as a duplicate if that bug's symptom is what 
you're seeing.
(In reply to comment #1)
> Related to Bug 274264?

Possibly -- that's a suite analog for bug 273109, which is a compose-window 
issue, and different than bug 234681.  But that bug talks about a filesystem in 
Shift-JIS, this bug talks about a "UTF-8 named attachment" which is different.
I don't know how encodings are supposed to work in filesystems... I see the 
symptom from 234681 on my Win2K (english) system.


> (Or to Bug 215949??)

Not likely -- that's a message display issue, not message compose.
(In reply to comment #2)
> I suspect this is bug 234681.

No, I'm wrong -- that's a bug about *saving* attachments, altho the symptom of 
underscore (_) being used is what I see when I attach a file.
I have searched several times for duplicates of the symptom I am seeing, and 
cannot find it.  This is:
1) Start a new message composition
2) Attach a file with a Unicode name by dragging from Explorer to attachment 
panel.
3) Attach a file with a Unicode name by clicking the Attach toolbutton.
4) Send the file

Actual results:
2) filename in panel shows ???? instead of proper name
3) filename in panel shows ____ instead of proper name
4) Error:
  Sending of message failed.
  Unable to open the temporary file [[<path>\_____.ext]]. ...

Expected results
2) and 3): filename shown as seen in the Explorer or File Open windows.
4) Transmission without a problem.

I'm seeing this with TB 1.0+0407 and Moz 1.8b2-0305.  I am running an English 
installation of Windows 2000.  I see the same results whether the compose window 
has the (default) ISO-8859-1 charset or the UTF-8 or UTF-16LE charset.


Tomoo-san, it would be helpful if you could comment in this bug, since I don't 
know if I'm seeing the same symptom you are.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → Windows 2000
Summary: Can't display Japanese attachment name correctly → Attaching file with Japanese/Unicode name: name is mangled (intl chars converted to '_' or '?')
Whiteboard: intl
The symptom is different. 
1. Make a file named "申込み" or "表題" on a filesystem which uses UTF-8 name.
2. Open new compose window and click attachment area.
3. Choose the file "申込み" or "表題" to be attached.
4. You will see "・5C込み" or "・5C題" as those file names.
It could be resolved as a dupe of bug 162361, but let's just make this depend on it.
Assignee: sspitzer → jshin1987
Depends on: 162361
Summary: Attaching file with Japanese/Unicode name: name is mangled (intl chars converted to '_' or '?') → Attaching a file with its name in characters not covered by the default codepage (e.g. Japanese on English OS): name is mangled (intl chars converted to '_' or '?')

(In reply to comment #7)
> It could be resolved as a dupe of bug 162361, but let's just make this depend
> on it.

I realized that the original report is not about characters outside the default system code page. Well, I can't tell from comment #0, but comment #6 made it clear what this bug is about. My comment #7 is entirely off the mark.


> The symptom is different. 
> 1. Make a file named "申込み" or "表題" on a filesystem which uses UTF-8 name.

On Windows, you cannot control the file system charset (there's no such thing as 'UTF-8' filename on Windows). It's always UTF-16LE internally. For applications that use 'ANSI' APIs (mozilla's nsFileSpec does while nsILocalFile doesn't any more thanks to bug 162361), it's your default system codepage (on Japanese window, it's Shift_JIS unless you changed it from the default factory setting). 

> 2. Open new compose window and click attachment area.
> 3. Choose the file "申込み" or "表題" to be attached.
> 4. You will see "・5C込み" or "・5C題" as those file names.

Your problem ('back slash' in the trailing byte of a multibyte character is mishandled in nsFileSpec) might have been fixed by Masayuki's fix of nsFileSpec (bug 180849), but might not. Aha... it's more likely to have been fixed by his patch for bug 274264. 

Can you try a recent nightly and see if this problem has been fixed.


Mike, the problem described in your comment #5 is basically the same as bug 234681, isn't it? Drag&drop and file opening go through two different codepaths, which is why you have different behaviors ('?' vs '_').
No longer depends on: 162361
Summary: Attaching a file with its name in characters not covered by the default codepage (e.g. Japanese on English OS): name is mangled (intl chars converted to '_' or '?') → Attaching a file with its name containing a multibyte character whose trailing byte is backslash doesn't work
(In reply to comment #8)


> Mike, the problem described in your comment #5 is basically the same as bug
> 234681, isn't it? 

Ooops. bug 234681 is about saving an attachment whose name contains characters outside the system default codepage (for ANSI APIs). So the symptoms in comment #5 (attaching a file to an outgoing mail) are different from bug 234681 although   case 3 has the same cause as bug 234681 (nsFileSpec dependence of mailnews : bug  33451)

> Drag&drop and file opening go through two different
> codepaths, which is why you have different behaviors ('?' vs '_').  

As for drag&drop, it should be related to (if not a dupe of) bug 194067. 
You may file one or two new bugs (unless they're filed already) on 'drag&drop' issue and 'file opening for attachment' issue as you wrote off-line to me. Make sure that the former is made depend on bug 194067. As I wrote above, the latter might have the same root cause as bug 234681, but it may be filed separately initially.
I'm not sure whether it depends on bug 194067 or bug 234681, but I think it might depens on something related to Shift_JIS code. As I mentioned in #8, the second byte of the invalid file name is "5C", 0x5C means backslash code. Some Shift_JIS character have "0x5C" on its second byte and often cause a trouble, because backslash means to escape the next character's functional meaning.
Anyway, under SeaMonkey 1.5a Gecko/20060316 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1 ), the symptom seems to have been cleared.
I suppose it might be marked as "FIXED".
(In reply to comment #10)
> I'm not sure whether it depends on bug 194067 or bug 234681, but I think it

It's bug 274264. 

> might depens on something related to Shift_JIS code. As I mentioned in #8, the
> second byte of the invalid file name is "5C", 0x5C means backslash code. Some

That's exactly what the summary of this bug means and what's dealt with in bug 274264. It's not only SJIS but also other CJK codepages that are not compliant to ISO 2022 (Big5, UHC, GB18030, etc)
Status: NEW → RESOLVED
Closed: 19 years ago
Depends on: 274264
Resolution: --- → FIXED
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.