[EMAIL PROTECTED] (Ulrich Drepper) wrote on 01.02.01 in
<[EMAIL PROTECTED]>:
> Tomohiro KUBOTA <[EMAIL PROTECTED]> writes:
>
> > Thus, either of them should be taken:
> > 1. libc/kernel accepts only UTF-8 filenames.
> > 2. libc/kernel knows the locale.
>
> None of this. Neither the kernel nor libc will ever do anything about
> the encoding of filenames etc.
I believe the kernel already does convert filenames. It has to, for
example to use NTFS or VFAT (which use UTF-16 filenames - without
conversion, no can do), and of course there's a reason the kernel config
offers support for a dozen or so different character sets.
> There are these stupid Winblows
> exceptions of course but not for real filesystems.
IMAO, a *real* filesystem should use some encoding of ISO 10646 - UTF-8,
UTF-16, or UTF-32 are all viable options. The same should be true for the
kernel filename interfaces.
Anything else is just not long-term viable.
Of course, the best way to live in such an environment is to use UTF-8
locales - no libc filename translation necessary then. Fortunately, glibc
already seems to implement that.
So what we really need is:
(1) Find out which sofftware areas still have trouble with this model, and
fix those.
(2) Have a nice HOWTO explaining how to configure everything to work in
such an environment. Whatkernel config is needed? Mount options? How do we
configure the right locales? How to tell the console or X to do this
right? And so on.
(3) Another nice HOWTO explaining how to migrate legacy data. How to
locate non-ASCII filenames, how to change those names once we have figured
out the encoding used, possibly a script to automate that for people who
are certain they only have one encoding around, how (and when) to convert
file contents.
MfG Kai
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/lists/
