Windows控制台说明

Changelog

6.0 新版功能.

Click在Windows上模拟输出流,通过单独的api支持unicode到Windows控制台,我们执行不同的参数解码。

下面是一个简单的概述,它是如何工作的以及它对您意味着什么。

Unicode参数

内部Click通常基于这样一个概念:任何参数都可以作为字节字符串或Unicode字符串输入,并尽可能晚地执行到类型预期值的转换。这有一些优点,因为它允许我们以最适合操作系统和Python版本的形式接受数据。

这在Windows上造成了一些问题,最初使用了错误的编码,垃圾最终进入了输入数据中。我们不仅修复了编码部分,而且现在还从 sys.argv .

还有另一个限制:如果 sys.argv 在调用click处理程序之前进行了修改,我们必须返回常规字节输入,在这种情况下,不是所有的Unicode值都可用,而是仅用于参数的代码页的一个子集。

Unicode输出和输入

Windows上的Unicode输出和输入是通过调度文本流的概念实现的。这意味着,当click first需要Windows上的文本输出(或输入)流时,它会进行一些检查,以确定Windows控制台是否已连接。如果不存在Windows控制台,则返回文本输出流,并将该流的编码设置为 utf-8 就像在所有平台上一样。

但是,如果连接了控制台,则将模拟流,并使用cmd.exe unicode API输出文本信息。在这种情况下,流还将使用 utf-16-le 作为内部编码。然而,仍有一些黑客认为底层的原始IO缓冲区仍然可以绕过Unicode API,并且通过间接寻址进行字节输出仍然是可能的。

  • 此Unicode支持仅限于 click.echoclick.prompt 以及 click.get_text_stream .

  • 取决于是否传递了Unicode值或字节字符串,控制流在内部的位置完全不同,如果数据部分被缓冲,则可能会有一些奇怪的工件。Click尝试通过手动始终刷新来防止这种情况发生,但如果要将不同的字符串类型混合并匹配到 stdoutstderr 您需要手动冲洗。

  • 原始输出流设置为二进制模式,这是Windows上的全局操作,因此 print 呼叫将受到影响。喜欢 click.echo 结束 print .

  • 在Windows7及以下版本中,有一个限制,即在一次二进制模式调用中最多可以写入64K个字符。在这种情况下, sys.stdoutsys.stderr 替换为围绕限制。

另一个需要注意的重要事项是,Windows控制台的默认字体不支持很多字符,这意味着您主要只支持国际字母,而不支持表情符号或特殊字符。