擅长:python、mysql、java
<p>主要问题似乎是,在Windows上不可能只使用标准C库而不使用依赖于平台或第三方的扩展来使用Unicode。您提到的语言源于Unix平台,Unix平台实现Unicode的方法与C语言很好地融合在一起(它们使用普通的<code>char*</code>字符串、C语言环境函数和UTF-8)。如果你想在C语言中使用Unicode,你或多或少要写两遍:一次使用非标准的Microsoft扩展,一次使用所有其他操作系统的标准C API函数。虽然这是可以做到的,但它通常没有高优先级,因为它很麻烦,而且大多数脚本语言开发人员要么讨厌要么忽略Windows。在</p>
<p>在技术层面上,我认为大多数标准库设计人员的基本假设是,所有I/O流本质上都是基于操作系统级别的字节,这对于所有操作系统上的文件和类Unix系统上的所有流都是如此,只有Windows控制台是唯一的例外。因此,要想集成Windows控制台I/O,就必须对许多类库和编程语言标准进行很大程度的修改</p>
<p>另一个更主观的观点是,微软在推广Unicode的使用方面还不够。第一个支持Unicode的Windows操作系统是WindowsNT3.1,它在1993年发布,比Linux和OSX对Unicode的支持要早得多。不过,在这些操作系统中,向Unicode的过渡已经变得更加无缝和无问题了。微软再次听取销售人员的意见,而不是工程师的意见,并将技术上过时的Windows9x保留到2001年;他们没有强迫开发人员使用干净的Unicode接口,而是仍然提供损坏的、现在不必要的8位API接口,并邀请程序员使用它(看看最近关于堆栈溢出的一些windowsapi问题,大多数新手仍然使用可怕的旧API!)。在</p>
<p>当Unicode问世时,许多人意识到它很有用。Unicode最初是纯16位编码,所以使用16位代码单元是很自然的。微软随后显然说“好吧,我们有16位编码,所以我们必须创建一个16位API”,并没有意识到没有人会使用它。然而,Unix的杰出人士认为“我们如何才能以一种高效且向后兼容的方式将其集成到当前系统中,以便人们能够真正地使用它?”后来又发明了UTF-8,这是一项杰出的工程。就像创建Unix时一样,Unix的人想得更多,需要的时间更长一些,财务上的成功较少,但最终还是做对了。在</p>
<p>我不能评论Perl(但我认为Perl社区中讨厌Windows的人比Python社区中的要多),但是关于Python,我知道BDFL(他也不喜欢Windows)已经声明在所有平台上提供足够的Unicode支持是一个主要目标。在</p>