为什么脚本语言不将Unicode输出到Windows控制台？

Question

Windows控制台至少有十年的Unicode意识，甚至可以追溯到windowsnt。然而，由于某些原因，主要的跨平台脚本语言（包括Perl和Python）只输出各种8位编码，这需要大量的麻烦来解决。Perl给出一个“宽字符打印”警告，Python给出charmap错误并退出。究竟为什么这么多年后，他们不只是简单地调用输出UTF-16unicode的Win32-wapi，而不是强迫一切通过ANSI/代码页瓶颈？在

只是跨平台的性能是低优先级的吗？是不是这些语言在内部使用了UTF-8，并且发现输出UTF-16太麻烦了？或者-wapi本身就已经损坏到不能按原样使用的程度了吗？在

更新

看来，责任可能需要各方共同承担。我想象脚本语言可以在Windows上调用wprintf，让操作系统/运行时担心诸如重定向之类的事情。但事实证明even wprintf on Windows converts wide characters to ANSI and back before printing to the console！在

请让我知道这是否已经修复，因为错误报告链接似乎断开，但我的visualc测试代码wprintf仍然失败，writesolew仍然成功。在

更新2

实际上，您可以使用wprintf将UTF-16从C打印到控制台，但前提是首先要这样做。在

从C语言可以将UTF-8打印到一个控制台，控制台的代码页被设置为代码页65001，但是Perl、Python、PHP和Ruby都有阻止这一点的bug。Perl和PHP通过在至少包含一个宽字符的行后面添加额外的空行来破坏输出。Ruby的损坏输出略有不同。Python崩溃。在

更新3

在节点.js是第一种没有这个问题的脚本语言。在

自从2016年Python团队发现了一个巨大的漏洞，开发团队慢慢地意识到了这个问题。在

Answer 1

我正在运行捷克本地化的WindowsXP，几乎所有地方都使用CP1250代码页。控制台的有趣之处在于它仍然使用旧的DOS852代码页。在

我能够制作非常简单的perl脚本，使用以下命令将utf8编码的数据打印到控制台：

binmode STDOUT, ":utf8:encoding(cp852)";

尝试了各种选项（包括utf16le），但只有上面的设置正确地打印了重音的捷克字符。在

编辑：我对这个问题进行了更多的研究，发现了Win32::Unicode。模块导出函数printW，该函数在输出和重定向时都能正常工作：

^{pr2}$