i'm a bit of an I18N novice, but doesn't it all just magically work if you use UTF-8 encoding everywhere?
UTF-8 deliberately avoids using \0 and / in the encodings. plain ascii works unmodified. unix filesystems generally support UTF-8 directly (because of the \0 and / avoidance). this allows you to have a single API which understands unicode on all platforms -- you don't need to have _u versions which take unicode strings. give this page a perusal: http://www.cl.cam.ac.uk/~mgk25/unicode.html -dean On Sat, 24 Feb 2001, Greg Stein wrote: > On Sat, Feb 24, 2001 at 11:31:49AM -0600, William A. Rowe, Jr. wrote: > > From: "Greg Stein" <[EMAIL PROTECTED]> > > Sent: Saturday, February 24, 2001 3:44 AM > >... > > > In a similar vein, when you added all that Unicode stuff, it just kind of > > > dropped into the code. No big deal as it was all Win32 specific (i.e. it > > > didn't affect my playground), but it was an awfully big change. Especially > > > in the semantics. We still haven't refactored the API into two sets of > > > functions (one for Unicode chars, one for 8-bit native). > > > > I'm absolutely positively near certain we won't. Please let me explain. > > > > ... lot of stuff about why Unicode filenames are Goodness ... > > I don't disagree with wanting Unicode filenames. I completely disagree with > APIs that change their semantics based on the platform they are compiled on. > > If I have an application that I desire to be portable, then I'm going to use > APR to do it. In my app, I call apr_file_open(some_8bit_name). That should > work on all platforms. With the current single API, it will break on NT when > compiled with the Unicode stuff. > > None of the APIs change their semantics. They exist or they don't, but they > don't change. > > The answer is to have apr_file_open_u() for opening with Unicode filenames, > not changing the encoding of the existing apr_file_open. You completely > break all possibility of writing portable apps when you do that. And APR is > *about* writing portable apps. > > Cheers, > -g > > -- > Greg Stein, http://www.lyra.org/ >
