Question

6.0 新版功能。

在 Click6.0 之前，在 Windows 控制台上使用 Click 有各种错误和限制。最值得注意的是，命令行参数的解码是在 python 2 上使用错误的编码执行的，在所有版本的 python 上都不可能输出 unicode 字符。从 click 6.0 开始，我们现在模拟 Windows 上的输出流，通过单独的 API 支持 Unicode 到 Windows 控制台，并执行不同的参数解码。

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

Unicode 参数

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

例如，路径在 python 2 上保留为字节，除非您明确地告诉它其他的情况。

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

这意味着在 Windows 下的 python 2 上，处理的参数将 最可能 具有 Unicode 性质，而不是字节。这是以前没有真正发生的事情，除非您显式地传递 Unicode 参数，所以您的自定义类型需要知道这一点。

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

Unicode 输出和输入

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

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

这个黑客在 python 2 和 python 3 上都使用，因为 python 的两个版本都不支持带有 unicode 字符的 cmd.exe。您需要注意一些限制：

• 此 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 控制台的默认字体不支持很多字符，这意味着您主要只支持国际字母，而不支持表情符号或特殊字符。