[FileSystem] Internationalization woes on windows
I know this has been discussed a fair bit but I'd just like to get confirmation of what I believe to be the case re: boost::filesystem and internationalization on windows. I've been using boost::filesystem::directory_iterator to (amongst other things) recurse across a directory hierarchy, and on each item asking boost::filesystem::is_directory. When a file or directory is encountered containing characters not representable using the ANSI char set (alright the MS ANSI charset) an exception is thrown. For example: "boost::filesystem::is_directory: "Scratch561\ABCDE<internationized chars>MNOP": The filename, directory name, or volume label syntax is incorrect." This is presumably because the windows ANSI API calls are being used (the <API function>A variants). Am I missing something, or is this a pretty severe limitation for windows? (I appreciate unix's don't suffer in this based on their api typically using UTF-8 encoding). Thanks in advance for setting me straight/confirming my fears. Mark
filesystem is being revamped to support wide-char names, this was
discussed a while ago.
On Mon, 14 Mar 2005 09:52:03 -0000, Mark Holloway
I know this has been discussed a fair bit but I'd just like to get confirmation of what I believe to be the case re: boost::filesystem and internationalization on windows.
I've been using boost::filesystem::directory_iterator to (amongst other things) recurse across a directory hierarchy, and on each item asking boost::filesystem::is_directory.
When a file or directory is encountered containing characters not representable using the ANSI char set (alright the MS ANSI charset) an exception is thrown. For example:
"boost::filesystem::is_directory: "Scratch561\ABCDE<internationized chars>MNOP": The filename, directory name, or volume label syntax is incorrect."
This is presumably because the windows ANSI API calls are being used (the <API function>A variants).
Am I missing something, or is this a pretty severe limitation for windows? (I appreciate unix's don't suffer in this based on their api typically using UTF-8 encoding).
Thanks in advance for setting me straight/confirming my fears. Mark
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Cory Nelson http://www.int64.org
participants (2)
-
Cory Nelson
-
Mark Holloway