Car*_*arl 11 unix linux encoding
我知道这是习惯,但为什么呢？是否存在真正的技术原因,为什么任何其他方式都是一个非常糟糕的想法,还是仅仅基于编码和向后兼容的历史？另外,不使用的危险是什么UTF-8,还有其他一些编码(最值得注意的是UTF-16)？
编辑:通过互动,我主要是指shell和libc.
Jon*_*ler 15
部分原因是文件系统期望NUL('\ 0')字节终止文件名,因此UTF-16不能很好地工作.您必须修改大量代码才能进行更改.
正如jonathan-leffler所提到的,主要问题是ASCII空字符.传统上,C期望字符串为空终止.因此,标准C字符串函数将阻塞任何包含等于ASCII null(0x00)的字节的UTF-16字符.虽然您当然可以使用广泛的字符支持进行编程,但UTF-16在文件名,文本文件,环境变量中不适合使用Unicode的外部编码.
此外,UTF-16和UTF-32具有大端和小端方向.要解决此问题,您需要外部元数据,如MIME类型或字节方向标记.它注意到,
在8位环境中透明地使用UTF-8的地方,使用BOM会干扰任何在开头需要特定ASCII字符的协议或文件格式,例如使用"#!" 在Unix shell脚本的开头.
UTF-16的前身,称为UCS-2,不支持代理对,也有同样的问题.应避免使用UCS-2.