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.echo，click.prompt以及click.get_text_stream.取决于是否传递了Unicode值或字节字符串，控制流在内部的位置完全不同，如果数据部分被缓冲，则可能会有一些奇怪的工件。Click尝试通过手动始终刷新来防止这种情况发生，但如果要将不同的字符串类型混合并匹配到
stdout或stderr您需要手动冲洗。原始输出流设置为二进制模式，这是Windows上的全局操作，因此
print呼叫将受到影响。喜欢click.echo结束print.在Windows7及以下版本中，有一个限制，即在一次二进制模式调用中最多可以写入64K个字符。在这种情况下，
sys.stdout和sys.stderr替换为围绕限制。
另一个需要注意的重要事项是，Windows控制台的默认字体不支持很多字符，这意味着您主要只支持国际字母，而不支持表情符号或特殊字符。
