对于2.7、3.5，您显示的命令行用cp437-IBMPC或DOS编码来响应。Windows控制台的输出仅限于基本多语言平面(BMP)Unicode字符的子集。在

对于3.6，Python对Windows控制台的处理得到了极大的改进，可以使用utf-8，并且可以打印任何unicode字符，这取决于字体的可用性。在

对于所有当前版本，IDLE还报告了cp1252(拉丁语1)。既然有人试图得到系统编码，我不知道为什么会有区别。但它几乎没有任何区别，因为它是一个伪值或假值。对我来说，这是有欺骗性的，因为非拉丁字符不能用拉丁1编码，而所有的BMP字符都可以在空闲状态下打印。所以我想换一个。在

写入(unicode)字符串时系统标准输出(通常使用print)，string对象在用户进程中被pickle为字节，通过socket(实现细节可能会更改)发送到空闲进程，然后取消pickle返回到string对象。其效果就好像字符串是用一种无损的utf编码进行编码和解码的。UTF-32可能是最接近酸洗的。在

空闲进程调用tkinter文本.插入(index，string)，它要求tk在小部件中插入字符串。但这只适用于BMP字符。最终的效果就像输出编码是ucs-2，不过我相信tk在内部使用了截断的utf-8。在

类似地，在shell或编辑器中输入的任何BMP字符在显示后都可以发送到用户进程stdin。在

不管怎样，改变伪文件.编码没有效果，这就是issue 9290的补丁的这一部分使其成为只读的原因- self.encoding = encoding

+ self._encoding = encoding

+

+ @property

+ def encoding(self):

+ return self._encoding

初始下划线意味着∗编码是一个私有的(不是隐藏的)实现细节，用户应该忽略它。在