Closed
Bug 85836
Opened 24 years ago
Closed 23 years ago
nsILocalFile for windows doesn't support unicode filesystems
Categories
(Core :: Internationalization, defect)
Tracking
()
mozilla1.2beta
People
(Reporter: caustin, Assigned: tetsuroy)
References
Details
(Keywords: intl)
nsILocalFile for Windows doesn't support wide-character filesystems, even if the
OS supports them. For example, NT and 2K (English) let me make a directory and
a file with Japanese characters, but I can't create a profile in them (in the
directory case) or open them with File | Open (in the file case).
Reporter | ||
Comment 1•24 years ago
|
||
intl keyword
target: 0.9.3
I'm going to try to fix this in the next couple of days (I'm getting faster!)
Keywords: intl
Target Milestone: --- → mozilla0.9.3
Comment 2•24 years ago
|
||
Please talk to dougt about your change. I think he is the owner of nsILocalFile.
Reporter | ||
Comment 4•24 years ago
|
||
Okay, I've talked to dougt and wtc about this... Basically, NSPR would probably
have to change to support either UTF-8 or UCS-2. The other possible solution
would be some modifications to the nsILocalFile interface, but that's about as
daunting as changing NSPR. ;)
markh suggested simply passing MBCS strings out of nsFilePicker. In theory,
they would eventually travel down to the underlying OS functions and Do The
Right Thing. Once I got the UCS-2 filename from the OS, I used
WideCharToMultiByte to convert it to an MBCS string. The ANSI or OEM codepages
converted the Japanese characters in the path to ?. UTF-8 worked fine, but the
rest of Mozilla didn't seem to understand it.
So, uhhh, I'm done rambling now. Eventually we're going to want NSPR to support
UTF-8 or UCS-2.
Comment 5•24 years ago
|
||
When you get UCS-2 filename from OS (by using W_API) what code page do you use
for WideCharToMultiByte? If you use ACP then the result would be the same as non
W_API.
Reporter | ||
Comment 6•24 years ago
|
||
I tried CP_ACP, CP_OEMCP, and CP_UTF8.
Comment 7•24 years ago
|
||
I meant how do you get a proper code page, sorry about the confusion.
Comment 8•24 years ago
|
||
I think the underlying point is that there is no way to identify the
originating code page for these files.
Using the narrow APIs and/or using ACP to perform the conversion should work,
but only for files _created_ using the current codepage (ie, created on the
current system).
So I believe that for a Japanese user, using the narrow APIs would _generally_
work fine. The "generally" is the show-stopper though - it means that files
created under one code page can not be used by users using a different code
page. Thus, files on network shares etc could potentially have problems.
So we have two possibilities - use ACP to perform the conversions, and at least
we will work in more situations than we work now. The second is to provide
Unicode versions (or UTF-8 awareness) of the nspr file IO functions.
These need not be mutually exclusive. If the change to nspr looks like
dragging on forever, then an interim fix could possibly be to try and fake it
using ACP (with the understanding that it is not a complete solution).
Support for Unicode/utf-8 in nspr is the "correct" solution though.
Comment 9•24 years ago
|
||
Thank you for the explanation. ACP support is currently done, so the remaining
issue is UCS2/UTF-8 support.
I think the network file sharing issue is more OS issue than mozilla issue.
Comment 13•23 years ago
|
||
mass change, switching qa contact from jonrubin to ruixu.
QA Contact: jonrubin → ruixu
Assignee | ||
Comment 14•23 years ago
|
||
Changing the milestone.
I think we seriously give a try on this.
(ie. UCS2/UTF-8 support in NSPR)
There are bunch of unicode file i/o related bugs
and I need to resolve them in near future.
Blocks: 58866
Target Milestone: Future → mozilla1.2alpha
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla1.2alpha → mozilla1.2beta
Assignee | ||
Comment 15•23 years ago
|
||
marking as dup
*** This bug has been marked as a duplicate of 58866 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•