为什么在与UNIX/Linux环境交互时使用UTF-8编码？

我知道这是习惯,但为什么呢？是否存在真正的技术原因,为什么任何其他方式都是一个非常糟糕的想法,还是仅仅基于编码和向后兼容的历史？另外,不使用的危险是什么UTF-8,还有其他一些编码(最值得注意的是UTF-16)？

编辑:通过互动,我主要是指shell和libc.

1> Jonathan Lef..：

---

部分原因是文件系统期望NUL('\ 0')字节终止文件名,因此UTF-16不能很好地工作.您必须修改大量代码才能进行更改.

---

@ dan04鉴于NT早于UTF-8,使用UTF-8而不是UCS2编写NT会很困难.这需要非凡的远见.

---

实际上Windows通过这样做增加了对"UCS-2"的支持,然后当它发现16位还不够时它是"640k重新"...... ;-)

---

Windows通过制作整个Windows API的重复版本添加了对UTF-16的支持.添加对UTF-8的支持会简单得多.

2> Joseph Holst..：

---

正如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.