Closed
Bug 5887
Opened 25 years ago
Closed 24 years ago
File System in Sidebar does not display upper ascii directory names
Categories
(Core Graveyard :: RDF, defect, P3)
Tracking
(Not tracked)
VERIFIED
INVALID
People
(Reporter: msanz, Assigned: waterson)
References
Details
(Whiteboard: DEPEND - Intl)
File system in Sidebar does not display directory names that are upper ascii (nor double-byte). Create a directory named "téstíñg" Click on File System on Sidebar and choose the drive where the directory is. Note that the directory name is now "testing"
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M6
Assignee | ||
Updated•25 years ago
|
Assignee: waterson → mcmullen
Status: ASSIGNED → NEW
Target Milestone: M6 → M15
Assignee | ||
Comment 1•25 years ago
|
||
I am using nsFileSpec, which only has a single-byte interface to get the file names. Reassigning to John: if you make this double-byte, then I can display int'l chars. FWIW, I believe that the file system data source is "out", so I'm going to change the target milestone on this to something WAY in the future.
OK, so it's academic. But I'd like some pointers on exactly what's required. Is calling nsString::GetUnicodeString() (or whatever it's called) enough? If so, you can do it outside of nsFileSpec. I note that all the viewer clients of nsFileSpec do this extra step themselves (see, for example, nsBrowserWindow.cpp).
Updated•25 years ago
|
Whiteboard: DEPEND - Intl
Filenames used by the OS' filesystem are encoded in charset encodings specific to each localized OS. On Mac: most European filenames are in MacRoman, Japanese filenames in Shift-JIS. On Win9x: Euro filename are in MS-Latin1, Japanese filenames are in Shift-JIS. On Unix: Euro filenames are in ISO-Latin1, most Japanese filenames are in EUC-JP. So we need to determine which encoding is being used by the file system, so the proper to/from Unicode conversion can be performed before reading or writing filenames. nsString are 2-byte Unicode (w/a special case to allow 1-byte (7-bit) ASCII). So if nsFileSpec returns nsString, then it will need to do the proper conversion and not the caller of nsFileSpec. This will also hide the platform dependency of the filesystem encodings.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Adding lyecies@netscape.com to cc list.
Updated•25 years ago
|
Assignee: warren → dougt
Status: ASSIGNED → NEW
Comment 5•25 years ago
|
||
Dougt should own this now.
Updated•25 years ago
|
QA Contact: phillip → paulmac
Comment 6•25 years ago
|
||
No, you need to convert char* to PRUnichar* by using Unicode Converter. Find the nsIPlatformCharset service and ask for the charset of the FileName selector. Then ask Character Converter Manager for an nsIUnicodeDecoder for it. Then you convert it from char* to PRUnichar*. Naoki have change several code in widget to make the nsIFileWidget work. You may look at those code to see how he do that. He convert PRUnichar* to char* by using nsIUnicodeEncoder, and you just need the reverse one by using nsIUnicodeDecoder.
Comment 7•25 years ago
|
||
The side bar should be using nsIFile. If it does, strings returned by GetPath() are in UTF8.
Comment 8•25 years ago
|
||
Where is the code which convert the file system text into UTF8 in nsIFile ? rjc- yesterday you said you are dealing this this bug ?
Comment 9•25 years ago
|
||
Why the method GetPath() passing char* instead of PRUnichar* / nsString ? We should always passing PRUnichar* or nsString in the interface for any text which may contain non ASCII. The interface problem is bigger than the implementation problem. Once the interface is wrong, you need to spend triple time to fix the problem.
Comment 10•25 years ago
|
||
ftang: No, this isn't the bug I was referring to.
Comment 11•25 years ago
|
||
This bug should dup to BUG 6770. Probely, this bug will be fixed by BUG 6770's patch.
Comment 12•25 years ago
|
||
nsIFile return strings in utf8. If I create a file called téstíñg, and use an ls tool that uses nsIFile, I the path returned is téstíñg. This is not a nsIFile bug. I am reassiging to waterson. Need to use nsIFile. (if I am missing something, please let me know)
Assignee: dougt → waterson
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M15 → M20
Comment 13•25 years ago
|
||
>nsIFile return strings in utf8. If I create a file called téstíñg, and use
>an ls tool that uses nsIFile, I the path returned is téstíñg.
>This is not a nsIFile bug.
>I am reassiging to waterson. Need to use nsIFile.
This sound exactly like a nsIfile problem....
1. the file system does not use UTF8 as encoding for the file system, so you
should NOT return UTF8 unless you do explicit conversion between the file system
charset and UTF-8
2. the file: url historially use file system charset (not UTF-8 again) in
escaped form. To maintain the compatability with the old file: URL, we should
treate the %xx escape in file: url as file system charset instead of escaped
UTF-8. Therefore, the nsIFile better not use UTF-8 but file system charset.
Comment 14•25 years ago
|
||
As waterson's said "File System in Sidebar" is OUT now. I cannot find the way to show the file system in sidebar now.
Assignee | ||
Comment 16•24 years ago
|
||
there are like a million better ways to do this now.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Updated•6 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•