Subject: Re: Unicode support in iso9660.
To: None <tech-kern@netbsd.org>
From: Pavel Cahyna <pcah8322@artax.karlin.mff.cuni.cz>
List: tech-kern
Date: 11/22/2004 17:19:02
> On Mon, Nov 22, 2004 at 02:41:03PM +0100, Pavel Cahyna wrote:
> > The GTK applications do need to display the filenames using X11. How to do
> > that without assuming that filenames are encoded character sequences?
> 
> The user needs to be able to read and write meaningful filenames.
> So the encoding / decoding has to happen somewhere.  The question
> is, where?
> 
> Currently, the filesystem is agnostic.  As long as paths are
> separated by '/' and end with a NUL character, the kernel doesn't
> really care what the encoding is.  I think der Mouse's point is
> that this is the way it should be--why should the kernel care what
> the encoding is when it's essentially the province of userland to
> make sense of the data.

I agree with this.

> In any event, a given piece of media will have filenames encoded
> in some fashion, be it ASCII, UTF-8, or "other".  I don't see how
> having the kernel know anything about the actual encoding would be
> particularly practical.
> 
> The question is, how do you determine the encoding?  And where do
> you want that knowledge to be?  My inclination is that it would be

The GTK+ solution is simple: everything is (assumed) UTF-8 and if you
really need, you can override it with the environment variables.

This sound like a good solution to me, but I must admit zero experience in
that area, since I hate non-ASCII filenames, so I always transliterate the
filenames to ASCII. Of course my language uses an alphabet which is a
superset of Latin alphabet, and for other alphabets it is not that simple.

Bye	Pavel