Messages in this thread | | | Date | Tue, 17 Feb 2004 21:09:19 +0000 | From | Jamie Lokier <> | Subject | Re: UTF-8 practically vs. theoretically in the VFS API (was: Re: JFS default behavior) |
| |
Alex Belits wrote: > UTF-8 is dependent on Unicode, that is cumbersome, not user-expandable,
Ah, Alex, welcome back. :)
> This means, it's quite possible that this standard will be replaced > by something better in the future
You mean like Unicode 4 will be replaced by Unicode 5 or something? :)
Seriously, if there was another standard encompassing all languages and characters, why would they call it something different?
> and this is why poor design of Unicode is tolerated by users, and > this is also why many people use non-Unicode-based charsets.
You've said this many times before, without explanation.
As far as I know, Unicode is a superset of all pre-existing computer charsets used anywhere - but do feel free to correct me.
Unicode does have its problems - but what possible advantage does _any_ known non-Unicode charset have over Unicode, apart from space saving?
You mention that Unicode doesn't well support language identification. This is true - but the non-Unicode charsets (koi8-r etc.) don't support that either! Or do they?
> And this is perfectly fine. Displaying and editing multilingual text is > a user interface issue, that kernel should not be involved in.
Actually the kernel does have a line editor which needs to know a little.
> I can point at the example of this "solution" that happened years ago > when UCS-2 was all the rage, and it got hardcoded and enforced by NTFS > and everything that handles it. Who is laughing about that decision now?
We are all laughing ;)
-- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |