Markus Kuhn wrote:
> Let's focus here on how to get things running smoothly under UTF-8
> locales. That's a simple and achievable cause. Anyone interested in more
> is free to set up the [EMAIL PROTECTED] mailing list
> where you can discuss the nightmares of fopen(..., "r/ISO2022-JP").
You missed the point here: In order to be able to switch to UTF-8, we have to
solve the problems that people doing the switch will run into. Otherwise the
switch to UTF-8 will not happen.
After switching to UTF-8, non-UTF-8 file names will still be found on
networked filesystems, floppies, tapes, tar files, etc. These have the be
dealt with.
It's a basic rule that when you are pushing a new format to be used, you have
to solve the problems involved. Otherwise people need to find only one
problem to use as a reason not to use the new format.
I don't think anyone suggested to actually add an argument to fopen() for the
encoding. It was only sketched as part of the complete picture. It's a
complex problem, some areas need to be investigated and marked as "bad
solution" to be able to find the right solution.
The table gives a nice overview. One problem I noticed is that it mentions
"locale", without making a difference between the locale of the current user,
locale at the time the file was given a name or the locale of the system.
--
hundred-and-one symptoms of being an internet addict:
141. You'd rather go to http://www.weather.com/ than look out your window.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.moolenaar.net \\\
((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
\\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/lists/
