On 26 Apr 2006, at 15:36, Roland Schwingel wrote:
Hi Richard....
> I think not ...
>
> The argument/environment strings are, (by definition since they are
> coming from outside the program), in the external character
encoding.
> The initWithCString: method initialises a string with data in the
> external character encoding. The current code should therefore be
> correct whatever the external encoding is.
>
> If you changed the code to use initWithUTF8String: it would be wrong
> on any system where UTF8 is not used as the external character
coding.
>
> NB. NSString determines the external character encoding from
standard
> environment variables, and those variable names and values are by
> definition ASCII, and are accessed via plain C functions and should
> therefore work irrespective of the external character encoding in
use.
>
Well...
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...
Any utf8 strings should only be 'trashed' if your environment does
not provide the correct encoding information (eg your environment
encodes data as utf8 but tells the application it's using latin2).
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.
Really no ... if the environment says it's using latin1, and then
passes utf8, it's the environment which is at fault and needs
fixing. The application can't know that external data is being
passed to it in the wrong encoding. Changing NSProcessInfo to always
use utf8 would just break applications in any environment where the
external encoding is not utf8.
On windows the story is a bit different ... NSProcessInfo should get
stuff via the wide (UTF16) APIs anyway, and any issues of character
coding conversion are therefore dealt with within the windows
libraries/operating-system.
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.
If you are using utf8 for everything, I would expect your locale
environment settings to say that it is a utf8 environment.
You can always set the GNUSTEP_STRING_ENCODING environment variable
to 'UTF-8' to override any default system locale info.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev