>>On the contrary, many designers would enthusiastically make that same >>"mistake" if designing a new system. The whole point of making filenames >>strings of bytes is that it lets the filesystem be character-set-neutral. >But it didn't work. You can't use EBCDIC or UTF-16 with a Unix filesystem. >In fact, a new Unicode format had to be created for Unix filesystems, because >the Unix filesystem made assumptions about what 0x0 and 0x2F mean.
The encoding is not going to change from UTF-8. Things that may change include: local-normal form, legal/deprecated characters, new combining characters, etc. Do you really want all that stuff built in to everything at a low level? What if a kernel normalizer gets out of sync with a user-land text normalizer, does half the filesystem became inaccesible? Also, imagine the extra load on your system if when you do: cat bigfiles | b | c | d | less and the text is being normalized back and forth at every step of the pipeline. -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
