Roland Schwingel schrieb: > Imagine you call [NSProcessInfo initializeWithArguments: (char**)argv > count: (int)argc environment: (char**)env]; > on either Linux or Windows. In both Operatingsystems you ensure that > argv[x] and/or env[x] contains utf8 encoded > strings. What do you think what happens? The strings are trashed...
Hello Roland, How can you reliably insure that argv/env contain UTF-8 in the common case? Are you using wrapper scripts to manipulate the environment? On POSIX systems the environment variables LANG/LC_* associated with the locale are the indicators of what character set (NSStringEncoding) to expect for any external source. Now I can very well imagine that GNUstep's current machinery may need to take extra steps in determining the correct locale under windows and I'm not sure if/how we can use libiconv on mingw. But wrapping the executable in scripts or other executables that manipulate the character set of the environment variables and doesn't set the corresponding locale seems like the wrong approach. > It can happen that your application runs in an environment where ut8 is > uncommon/not set or not the external encoding > (like on Windows), then NSString would fallback to ISOLatin1 (as far as I > remeber) and that would break > the utf8. Determining the character set has well defined methods (at least for POSIX systems and I'm sure windows also has some way). Also all UTF-8 character sequences are also valid ISOLatin1 and what makes ISOLatin1 more special than ISOLatin2 or even ISOLatin9 if you want the euro sign? > I wrote because I exactly have these problems frequently. I need to work > with files (eg. on my german windows), > that reside on drives with pathes containing unicode characters. Even I > might not be able to display the > pathes in explorer correctly at any time, I am able to open the files, > copy them or whatever I like to do > when working unicode save, and utf-8 is (mostly) the best way to handle > everything between the worlds. > > It might also happen that my app (containing ALL libraries) is in an > unicode path, so I wrote especially because of that, > because than the NSProcessInfo thingy comes to live for me... OK, so we have a bug. Let's figure out the correct way to determine the locale on windows and except the the environment variables to be in that encoding. Now I believe the that file accessing API already uses the mingw API which I believe expects UTF16 (close, but not really Unicode so there might be some issues) character set so once you have the correct NSString in the application you should be able to access the files already. Could some windows guru weigh in on this? Cheers, David _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
