Python--Cmd窗口运行Python时提示Fatal Python error: Py_Initialize: can't initialize sys standard streams Loo

源地址链接：

http://www.tuicool.com/articles/ryuaUze

 

最近，我在把一个 Python 2 的视频下载工具 youku-lixian 改写成 Python 3，并添加了本身须要的 YouTube 支持。

在 Linux 下，事情进行得很顺利：全部的东西都用 UTF-8 进行编码。Python 3 里的 str 类型从 2.x 版本的 ASCII 字符串变成了 Unicode 字符串；我移除了原来代码里关于本地编码类型的判断处理部分。程序从抓取的页面上解析出视频标题部分的 Unicode 字符串，直接 print ()显示到标准输出，一切看起来很和谐。

假定我抓取的这个视频标题是中文，叫作“你好，世界”。众所周知，得益于 Python 良好的 Unicode 支持，输出它只须要简单的一句：

print ('你好，世界')

在 天杀的 Windows 7 下测试这个程序时，麻烦就出现了。若是你想知道我为何这么说，请继续看下去。

我所不了解的 Windows

去年从学校拿到这台 Dell 笔记本时，Windows 7 天然是预装在上面的。

系统语言已经设置成了英语。很快，我对瑞典语键盘的布局感到极其不适应：它的标点符号位置与英语键盘布局有很大区别，分号、冒号、单引号双引号、斜杠反斜杠这些程序员司空见惯的符号，和美式英语键盘彻底不一样。因而，我把键盘布局换回了习惯的英语键盘，顺便把控制面板的“区域”选项也一律从瑞典换到了英语/美国。

在很长一段时间里，除了界面是英文之外，它看起来和以往用的中文系统没什么区别：有默认的中文字体，输入法能够添加中文的。我平时用它作的，只有：上网，挂迅雷，拿 IE 登网银，玩 Mirror's Edge，几件事而已。

文件系统是 Unicode 编码的，Web 浏览器是支持 Unicode 的，偶尔用的文本编辑器也是一概设置成 UTF-8 的。并且咱们知道，从 Windows 2000 起，Windows 的内码实现是使用 UTF-16LE 的。几乎让人快要忘了还有代码页这么一回事。

但是，若是要在英文 Windows 系统的命令提示符里执行这个简单的输出 Unicode 文本的程序：

#!/usr/bin/env python
# -*- coding: utf-8 -*- if __name__ == '__main__': print ('你好，世界')

Python 就会跳出来一段错误：

File "c:\Python32\lib\encodings\cp437.py", line 19, in encode return codecs.charmap_encode (input,self.errors,encoding_map)[0] UnicodeEncodeError: 'charmap' codec can't encode characters in position 0-1: character maps to <undefined>

难道 Python 3 不是支持 Unicode 的吗？难道它不是跨平台的吗？

第一个问题，基本上是对的，Python 3 确实支持 Unicode，这种支持体如今它把全部的 str 字符串都做为 Unicode 处理这件事情上。

第二个问题，不彻底，跨平台的可移植性是有条件的。Python 自己是支持 Unicode，可是若是赶上了非 Unicode 的古董环境，那就一点办法也没有。

什么叫“非 Unicode 的古董环境”呢……不，我说的不是 DOS。这个东西，居然就是 Windows 上的 cmd.exe ，每一个人或多或少都用过的命令行环境。

cmd.exe ，从 MinGW 到 Python，基本上每一个 Windows 下须要接触命令行的开发人员都躲不过去的东西，微软怎么就不能把它作好些？窗口大小不能为所欲为改也就算了，不能全屏显示也就算了，字体大小屏幕缓冲设置各类限制也就算了，鼠标拖拽不方便也就算了，命令行补全补不全也就算了，你好歹能把默认编码改为用 Unicode 吧？一个破窗口从二十年前的 3.x 时代沿用到今天的 Windows 7，从依赖 DOS 的command.com 到独立的 cmd.exe ，尼玛这么多年了，也没见功能上有什么实质的改进，是否是在微软眼里全部的程序员都在拿个白花花的 IDE“作你的 code”、不须要命令行了？

（在 Windows 已经彻底使用 UTF-16 做为内码实现的今天， cmd.exe 仍然在使用系统默认的代码页，我所能想到的惟一理由就是为了保持和之前的 non-Unicode 程序兼容——不过这理由也太弱了吧）

微软有功夫把 Windows 8 的界面作得花里胡哨，不过看样子他们是压根不打算把cmd.exe 这个东西作得更好用些。不继续喷下去了，说处理问题的通过：

前面 Python 的错误信息里提到了个文件 cp437.py 。既然是 cp437 什么的，那就必定是 Python 在试图把 Unicode 字符串转换成用于输出的 437 代码页（英语/美国）时出了错。

为何 Python 要把一个好端端的 Unicode 字符串转换成 cp437 呢？这很容易想通，由于程序是在 cmd.exe 这个终端环境下执行的。在个人英文系统上，它的活动代码页是 437（英语/美国）。从代码中的 Unicode 字符串到输出 cp437 的这一步转换，是由 Python 解释器来实现的，因此会由 Python 抛出一个错误，而不是直接在控制台输出一堆乱码。

首先想到的解决方案，天然是改变当前 cmd.exe 的活动代码页到 UTF-8 Unicode：

chcp.com 65001

不幸的是，这致使 Python 解释器直接崩溃了：

Fatal Python error: Py_Initialize: can't initialize sys standard streams LookupError: unknown encoding: cp65001 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. LookupError: unknown encoding: cp65001

搜了一下才发现，Python 3.2 目前并不支持 Windows 上面的 cp65001。话说 65001 代码页不就是 UTF-8 嘛（囧囧囧囧囧）

与其说是不支持，不如说是 bug 更合适些。由于执行以后 Windows 就跳出一个警告框说“ python.exe 已经中止响应”了……

因而，试着改变代码页到 GBK：

chcp.com 936

结果倒是：

Invalid code page

Windows 声称这是一个无效的代码页。为何？

编码是什么

好了，暂且忘记 cmd.exe 诸如此类使人不愉快的东西，在 IDLE 上试一试。

我不知道有多少 Linux 程序员写 Python 的时候会用到 IDLE。对于这些习惯了终端+文本编辑器的用户来讲，IDLE 看起来是个可有可无的附属品，也许它的定位只是用来帮助初学者入门的一个开发环境？

不过，容易被人们忽略的一点是：IDLE 自己是个跨平台的环境，这意味着它能够无条件支持 Unicode（只要系统上有相应的字体），用它来解释执行程序没必要受制于特定终端环境的拘束。这一点在 Windows 上很重要，由于 cmd.exe 这玩意实在是太差劲了，因此估计不少人在 Windows 下交互执行 Python 的时候仍是会选择 IDLE 的。

进入 IDLE。咱们可能要关心一下这个 Windows 系统下面的默认编码方式是什么，Python 3 里面有两个函数：

>>> sys.stdout.encoding; locale.getpreferredencoding ()
'cp1252' 'cp1252'

第一个sys.stdout.encoding是指标准输出的编码，第二个locale.getpreferredencoding则是系统本地化设置的编码。二者是有区别的。如今咱们看到，它们在当前环境下是相同的，都是默认的cp1252，也就是传说中的“ANSI”代码页。

恩，咱们已经知道 IDLE 是一个彻底跨平台的环境，因此在 IDLE 上输出 Unicode 字符能够获得和 Linux 环境下一样和谐的结果：

>>> print ('你好，世界')你好，世界

顺便看看“你好，世界”的 UTF-8 编码和 GBK 是什么，若是强制用其余编码方式来解码又会获得怎样的结果（后面也许会用到）。能够看到，5 个全角字符在 UTF-8 编码下是 15 个字节，每一个字符占 3 bytes；在 GBK 编码下是 10 个字节，每一个字符占 2 bytes。

虽然没有什么实际的意义，不过仍是能够注意到：UTF-8 编码的字符是没法用 GBK 解码的，哪怕是乱码有时候也不行，由于可能会出现奇数字节长度，这在 GBK 下不合法；反之 GBK 编码字符亦没法用 UTF-8 解码，由于有无效字符值的存在。

借助 IDLE 看到了“你好，世界”各类编码的详细状况。如今咱们能够回到 cmd.exe里面看一看下面这段程序的运行结果了：

#!/usr/bin/env python # -*- coding: utf-8 -*- import sys, locale if __name__ == '__main__': print(sys.stdout.encoding, locale.getpreferredencoding ()) try: print('你好，世界') except Exception as err: print(str (err))

首先经过 chcp 确认， cmd.exe 的当前活动代码页是 437（英语/美国），而非 IDLE 里的 1252（ANSI）。这是因为个人 Windows 里对 non-Unicode 程序的区域设置是“英语/美国”的缘故。

程序运行的结果是：

cp437 cp1252
'charmap' codec can't encode characters in position 0-4:  character maps to <undefined>

能够看到 sys.stdout.encoding 实际上就是当前环境下活动代码页的值。locale.getpreferredencoding () 没变，仍然是系统默认的 cp1252。

以后抛出的异常是在咱们预料之中的，正如此前同样，Python 尝试把 Unicode 字符串转换成 cmd 终端下的 cp437 代码页编码。而中文字符原本就是没有对应的 cp437 编码的，因此 Python 报错。

Google 一下 'charmap' codec can't encode characters in position 0-4: character maps to <undefined> 这个错误。在 Stack Overflow 上，有人提到了解决的方法：设置一个叫作 PYTHONIOENCODING 的环境变量。

PYTHONIOENCODING 环境变量

所谓的 PYTHONIOENCODING ，既能够做为环境变量存在，也能够做为 Python 的命令行参数传递。它用于指定 Python 程序标准输入输出（stdin/stdout/stderr）的编码。（注意这个编码不是指源代码的编码，和 Python 程序开头常见的 # -*- coding: utf-8 -*- 是两码事）

在没有这个环境变量时

如前面所述，Python 会试图把内部 Unicode 编码的字符串转化成当前执行程序的终端环境下所使用的编码方式（ sys.stdout.encoding ）后输出。对于当前代码页 437 的 cmd.exe 来讲，把只含有英文数字的字符串转成 cp437 编码没有任何问题；可是一旦赶上了中文字符，英语/美国的 437 代码页里必然是找不到对应的编码的，因而 Python 就会报错。

若是当前代码页设成 65001，Python 3.2 会崩溃，这是自己实现上的 问题 。在最新的 Python 3.3 beta 中已经 增长了对 cp65001 的支持 。

在设置了这个环境变量时

经过

set PYTHONIOENCODING=utf-8

或（PowerShell 下）

$env:PYTHONIOENCODING = "utf-8"

PYTHONIOENCODING 指定的编码方式会覆盖原来的 sys.stdout.encoding 。若是将 PYTHONIOENCODING 设置为 utf-8，那么 Python 在输出 Unicode 字符串的时候就会以 UTF-8 输出，至关于什么也不转换。

再次执行该 Python 程序，这一次 Python 再也不尝试自动转换 Unicode 的中文字符到 cp437 中的对应字符，程序成功运行， sys.stdout.encoding 变成了 utf-8，字符串输出则是乱码：

utf-8 cp1252你好，世界

这与咱们以前在 IDLE 中将 UTF-8 编码的文本强制用 cp437 解码获得的结果是彻底相同的：

>>> print(bytes ('你好，世界', 'utf-8') .decode ('cp437')) Σ╜áσÑ╜∩╝îΣ╕ûτòî

Python 直接把 UTF-8 编码的字符串输出到了 cp437 代码页的终端，至关于强制用 cp437 来解码 UTF-8 文本，产生了无心义的乱码。

用文本编辑器写一个内容是“你好，世界”的文件，以 UTF-8 编码保存。在 cmd.exe下经过 type 显示，结果和上面是相同的。

cmd.exe 和 PowerShell ISE 的微妙之处对比

在当前区域设置（英语/美国）下，二者执行 chcp.com 显示的当前活动代码页都是 437。

只有 cmd 下 Python 的 sys.stdout.encoding 默认是 cp437（与活动代码页相同）；PowerShell ISE 下 sys.stdout.encoding 则是 cp1252（ANSI）。

locale.getpreferredencoding 永远是系统自己默认的 cp1252，这是一个系统全局值。

cmd 没法输入中文，不能正确显示文件系统中的中文文件名；PowerShell ISE 可以输入中文，能显示中文文件名。

在缺乏 936 代码页的状况下，二者都不可以经过执行脚本或 type 文件内容正确显示中文字符（不管是 GBK 仍是 UTF-8），会产生乱码。

为何 Windows 会缺乏 GBK 代码页？

回到最初的那个问题上来，为何执行 chcp.com 936 不能切换到 GBK 代码页？为何 cmd.exe 和 PowerShell 里不能正常显示中文？

这个问题让我百思不得其解。花了几个小时找到了缘由，简而言之：由于 Windows 的“区域和语言”设置不对。

“Language for non-Unicode programs”这个选项不是简体中文，因此就不能用 GBK，手动 chcp.com 也会告诉你该代码页无效。因此必需要在控制面板里设置成简体中文，重启后才能生效。

好吧，问题来了，为何这里只能单选？若是我既想使用 936（GBK）编码的应用程序，又想使用 932（日语）编码的应用程序，难道每次都要在这里改完后再重启吗？为何他们不能给一个详细的代码页列表让用户多选、须要时能够动态加载？

Windows 设计的龌龊之处就在这里。若是你不去设置 system locale 为中文并重启，全部 non-Unicode 程序里的中文字符集都是不会出现的，只能显示成一个方框，好比cmd.exe 里：

还有 Vim 里（ set fileencodings=utf-8,gbk ），GBK 编码的文本和 UTF-8 编码的文本都同样没法显示。（按理说 Vim 应该不能算 non-Unicode 程序吧……谁知道呢？！）

改过"Language for non-Unicode programs”为中文而且重启系统以后，Vim 当即显示正常：

再进 cmd.exe ，默认活动代码页 936。这段 Python 程序终于也能正确输出了：

也许 Windows 这种蛋疼的设计是由于考虑到英文用户通常不会须要多余的 Unicode 和代码页字符集，这么作能够节省系统启动时间？谁知道呢，Windows 用户不是最喜欢拿所谓的“启动时间快”做为衡量系统性能的指标了吗……

切换到 cp65001（UTF-8 Unicode）， PYTHONIOENCODING 设置成 utf-8，按理来讲这种方式不该该出问题，可是这输出怎么看都不像是正常（以下图所示）。不想深究到底为何了，总之 Windows 下面东西的复杂程度以我这种智商是永远都不可以理解的……

Python 除了标准输入输出，还有……

文件名

open ('文件名测试'， 'w')

Python 中对文件系统的操做基本上是不受默认编码影响的，只要sys.getfilesystemencoding () 的结果是 utf-8（现代 Linux）或者 mbcs（现代 Windows NT 系统上）。二者本质上都是 Unicode 编码。

文件输入输出

文件读写不属于标准I/O，所以和环境变量 PYTHONIOENCODING 无关。

for c in ['utf-8', 'gbk']: with open ('test_%s.txt' % c, 'w', encoding=c) as output: try: output.write ('你好，世界\n') except Exception as err: print('\nWriting to file using %s:\n' % c, str (err))

因为在 open ()中显式指定了中文编码方式（encoding='utf-8'或encoding='gbk'），输出“你好，世界”这样的中文文本在任何平台上都应该可以获得正确的结果。

然而对于：

with open ('test_default.txt', 'w') as output: try: output.write ('你好，世界\n') except Exception as err: print('\nWriting to file using default encoding:\n', str (err))

因为没有指定编码方式，Python 会自动使用系统默认的编码方式来进行输出。若是系统默认编码是 cp437 或 cp1252，因为中文字符在这些代码页中显然不存在对应值，Python 会抛出一个熟悉的错误：

File "c:\Python32\lib\encodings\cp437.py", line 19, in encode return codecs.charmap_encode (input,self.errors,encoding_map)[0] UnicodeEncodeError: 'charmap' codec can't encode characters in position 0-1: character maps to <undefined>

固然，当系统默认编码为 cp936（GBK）时，不管

output.write ('你好，世界')

仍是

print ('你好，世界')

均可以正常工做。由于“你好，世界”这个 Unicode 字符串是能够被彻底转换成 GBK 中的对应编码的。

一些总结和思考

虽然 Python 3 使用 Unicode 编码的字符串，可是在跨平台的程序中依然要取得系统的默认编码用于后续处理，由于并非全部的终端环境都支持所有的 Unicode 字符集：

if sys.stdout.isatty ()
    default_encoding = sys.stdout.encoding
else default_encoding = locale.getpreferredencoding ()

不管什么时候，不要为所欲为地用 print ()向 stdout 输出 Unicode 字符串。若是某个要输出的 Unicode 字符（好比，中文字）在系统默认编码的字符集（好比，代码页 437）上没有，Python 这时就会抛出一个错误。这其实在大部分时候并非咱们想看到的局面，咱们总但愿即便有时会输出一些无心义的乱码，程序总体上也能正确运行。拿视频下载工具的例子来讲，即便因为终端的关系有时没法正确显示视频名称，这问题并不太严重，由于程序老是能够把抓取的视频内容写入正确的文件的。

在程序中获取了系统默认的 default_encoding ，咱们就能够强制用它来对 Unicode 字符串进行编码，至少避免了 Python 在自动转码过程当中可能会抛出的错误——虽然结果可能只是获得一堆乱码。另一种处理方式是对于这样的字符串，咱们决定根本不去输出它们。

咱们比较愿意看到的状况是：若是程序会输出且只会输出中文，而你假想中的 Windows 用户群所使用的代码页是 936（GBK）——尽管在程序中使用 Unicode 字符串吧，这样作不会带来任何问题。

可是，若是不能肯定要处理的 Unicode 文本会限定在哪一个代码页字符集的范围当中：中文？梵文？希伯来文？阿拉伯文？仍是……火星文？这个时候就必须考虑到世界上还有“编码方式差别”这回事了。固然，最好的解决方式也许是：告诉用户，去他的代码页，去他的什么 43七、500、93六、1252……这堆诡异的数字，去他的 Bush hid the facts ，扔掉设计上如此糟糕、编码方式如此混乱和不一致的 Windows，转投一个让生活更简单的操做系统 吧。