Closed Bug 85836 Opened 24 years ago Closed 23 years ago

nsILocalFile for windows doesn't support unicode filesystems

Categories

(Core :: Internationalization, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

VERIFIED DUPLICATE of bug 58866
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).
Blocks: 84384
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
Please talk to dougt about your change. I think he is the owner of nsILocalFile.
Switching QA contact to jonrubin.
QA Contact: andreasb → jonrubin
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.
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.
I tried CP_ACP, CP_OEMCP, and CP_UTF8.
I meant how do you get a proper code page, sorry about the confusion.
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.
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.
move to future
Target Milestone: mozilla0.9.3 → Future
Reassign to yokoyama.
Assignee: nhotta → yokoyama
Blocks: 88292
Accepting
Status: NEW → ASSIGNED
mass change, switching qa contact from jonrubin to ruixu.
QA Contact: jonrubin → ruixu
Depends on: 108000
No longer depends on: 108000
Blocks: 108000
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
Target Milestone: mozilla1.2alpha → mozilla1.2beta
marking as dup *** This bug has been marked as a duplicate of 58866 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Verified as dup.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.