Re: locale and file functions
Re: locale and file functions
- Subject: Re: locale and file functions
- From: Mike Mackovitch <email@hidden>
- Date: Wed, 1 Oct 2008 11:39:16 -0700
On Wed, Oct 01, 2008 at 09:53:22AM -0700, Kevin Van Vechten wrote:
>
> On Oct 1, 2008, at 1:43 AM, Jonas Maebe wrote:
>
>> What is the extent of the interaction between the current locale
>> setting (as in the LANG, LC_TYPE, etc environment variables) and the
>> encoding expected/returned by posix functions such as open(), stat()
>> etc? Are they always to be encoded using the current LC_TYPE, always
>> using UTF-8, or yet something else?
>>
>> I also recently discovered
>> http://developer.apple.com/documentation/CoreFoundation/Reference/CFStringRef/Reference/reference.html#//apple_ref/c/func/CFStringGetFileSystemRepresentation
>> (CFStringGetFileSystemRepresentation). It's perfectly usable when
>> passing stuff to the posix api's, but when getting something back you
>> still have to know what the used encoding was if you want to operate
>> further on it.
>
> Mac OS X's posix filesystem API (open(2), stat(2), etc.) always expect
> path names to be UTF-8 encoded (the system will normalize them to be
> decomposed), and return path names which are UTF-8 encoded (decomposed).
With the exception of some file systems which have no way of
knowing/enforcing character encoding standards... like NFS, as
noted in:
> http://developer.apple.com/qa/qa2001/qa1173.html
Also, strictly speaking, the VFS layer does no normalization.
Any normalization happens in the the file system implementation
or in system frameworks.
I was hopeful that NFSv4 would at least be bringing NFS to UTF-8.
But some implementations (Linux) have expressed that they have no
intention of enforcing/implementing that part of the NFSv4 spec. :-(
HTH
--macko
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden