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).

intl keyword target: 0.9.3 I'm going to try to fix this in the next couple of days (I'm getting faster!)

Please talk to dougt about your change. I think he is the owner of nsILocalFile.

Switching QA contact to 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

Reassign to yokoyama.

Accepting

mass change, switching qa contact from jonrubin to ruixu.

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.

marking as dup *** This bug has been marked as a duplicate of 58866 ***

Verified as dup.