On Tue, Dec 05, 2006 at 05:11:38PM +0100, Georg Baum wrote: > And I have something for the windows users: One of the next steps in making > non-ascii filenames work will be to actually implement > FileName::toFilesystemEncoding(). I know what to do on linux, but not on > windows, so it would be nice if somebody could find out the following: > > What encoding is used for filenames on windows? I know that > boost::filesystem has wstring support for filenames on windows, and that > probably uses ucs2/utf16. What I do want to know is whether it is also > possible to use non-ascii filenames with the std::fstream and narrow > strings, or do we need to use the streams of boost::filesystem? Any > pointers to some documentation are welcome.
I can only speak for Cygwin. I don't know for Windows in general, but I think that it is also dependent on the filesystem (FAT32 or NTFS). As regards Cygwin, it does not use wide characters internally for filenames/pathnames, nor does it support any locale other than C/POSIX. However, this last one is only half-true, as Cygwin works with the default codepage when the Windows locale settings are set correctly. Locales cannot be programmatically switched from within Cygwin, but it can handle the full 8-bit charset just fine. However, I think that the way LyX deals with locales should be rethought, maybe. I recently discovered that the EILSEQ errors I was seeing on Solaris were due to my locale settings. If the LC_* variables are set to xx_XX.ISO8859-1 then those errors are triggered. They disappear when using xx_XX.UTF-8, though. Moreover, towupper and company doesn't seem to work with ISO8859-1. For example, this is what I get when running the attached test program: $ env LC_ALL=it_IT.ISO8859-1 ./test-wctype towupper(0xe8) = 0xe8 toupper(0xe8) = 0xc8 $ env LC_ALL=it_IT.UTF-8 ./test-wctype towupper(0xe8) = 0xc8 toupper(0xe8) = 0xc8 However, I don't know if this is a Solaris bug, though, as the test program seems to work on Linux in both cases. -- Enrico
