我注意到,在没有源代码编码声明的情况下,Python 2解释器假定源代码使用 脚本 和 标准输入 以ASCII编码:
$ python test.py # where test.py holds the line: print u'é' File "test.py", line 1 SyntaxError: Non-ASCII character '\xc3' in file test.py on line 1, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details $ echo "print u'é'" | python File "/dev/fd/63", line 1 SyntaxError: Non-ASCII character '\xc3' in file /dev/fd/63 on line 1, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details
并使用-m 模块 和-c 命令 标志在ISO-8859-1中进行了编码:
-m
-c
$ python -m test # where test.py holds the line: print u'é' é $ python -c "print u'é'" é
它在哪里记录?
与此相反,Python 3始终假定源代码是用UTF-8编码的,因此可以é在四种情况下打印。
é
注意。 –我在控制台编码设置为UTF-8的macOS 10.13和Ubuntu Linux 17.10上的CPython 2.7.14上进行了测试。
的-c和-m开关,最终(*)运行与所提供的代码exec语句或compile()功能,这两者取Latin-1的源代码:
exec
compile()
第一个表达式的计算结果应为Unicode字符串, Latin-1 编码的字符串,打开的文件对象,代码对象或元组。
这没有记录,它是一个实现细节,可能会或可能不会将其视为错误。
我认为这不值得解决,而Latin-1是ASCII的超集,因此损失很少。Python 3中已经清理了如何处理代码-c以及如何-m处理代码,并且在此更加一致。随同传递的代码将 -c使用当前语言环境进行解码,并且-m像往常一样,使用该开关加载的模块默认为UTF-8。
(*)如果您想知道使用的确切实现,请从中的Py_Main()函数Modules/main.c开始,该函数同时处理-c和-m:
Py_Main()
Modules/main.c
if (command) { sts = PyRun_SimpleStringFlags(command, &cf) != 0; free(command); } else if (module) { sts = RunModule(module, 1); free(module); }
PyRun_SimpleStringFlags()
PyRun_StringFlags()
RunModule()
_run_module_as_main()
runpy
pkgutil.get_loader()
loader.get_code()