Kaixo!
On Fri, Jun 22, 2001 at 12:50:52PM +0100, Markus Kuhn wrote:
> I think that this standard is yet another reasons, why under Linux no
> encodings other than ASCII or UTF-8 should ever be used in path names.
That would indeed be nice, but the problem is that the standard functions
to deal with file names don't interpret the encoding at all (eg: the encoding
is locale dependent). A nice transparent solution would be to have the libc
internally and transparently use iconv, if needed. So utf-8 is used to store
file names; but the user can still read and type names even if not using
an utf-8 locale.
Currently filename encoding is dealt at the Linux kernel level, which
is imho wrong (and ineficient there are too few encodings recognized (compared
to encodings used in locales) and it imposes a per-systemencoding, which
on a multi-user system is bad).
Would it be acceptable to change internals of functions like fopen() and
the like so that the passed file name is converted to utf-8 trough iconv() ?
that should be done only when needed, eg when user charset is different of
utf-8, and when the fs is mounted in utf-8 mode. So that imply GNU libc
and Linux kernel changes; however if that feature would be available it would
easy a lot the Big Switch to utf-8 (as it will allow coexistance of programs
using utf-8 and traditiona encoding. without that ability people will tend
to delay the switch untill all programs are utf-8 aware).
If the external interface of fopen() functions isn't changed it shouldn't
be a problem (after all, the C standards doesn't define how the filenames
are actually stored on disk); but I'm not a C standard specialist, so I
don't know.
It's just an idea.
--
Ki �a vos v�ye b�n,
Pablo Saratxaga
http://www.srtxg.easynet.be/ PGP Key available, key ID: 0x8F0E4975
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
