On 9 Jun 2001, H. Peter Anvin wrote:
> There is no reason not to. There is no difference if you don't assign
> code points in that space, and there is no aliasing. Furthermore, it
> makes you future-proof if/when someone realizes just how bad an idea
> UTF-16 and 20.1 really is.
I won't get into that. My main concern is autodetection. A tighter
definition makes autodetection more reliable. In the migration to UTF-8,
somewhere we need to tell people that they should check the file with
UTF-8's tight syntax first, and if it fitted, it's UTF-8. Stop.
Wider syntax means more files will be considered UTF-8 while they're not.
--roozbeh
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
