gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSProcessInfo.m: Unicode compliance of _gnu_process_args()


From: Richard Frith-Macdonald
Subject: Re: NSProcessInfo.m: Unicode compliance of _gnu_process_args()
Date: Thu, 27 Apr 2006 20:12:46 +0100


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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]