Python源代码文件的文本编码
2012-07-22 01:46
295 查看
源代码的编码问题对于任何语言的源文件都是存在的,只不过对于脚本语言,这个问题更突出一些。
有的人可能会说,既然源代码在文本编辑器中可以正常显示,说明编码没有问题,编辑器可以识别它,为什么Python还要求声明源代码的编码呢?
这是因为,明确地声明编码可以简化Python解释器的实现,免得它去猜测源文件的编码,这样既会增加解释器的复杂性,也会减慢程序的执行速度(毕竟是解释执行)。况且,程序运行必须是精确的,不能靠猜测。
从Python 2.3开始,可以在Python源文件中明确地声明字符编码,默认是7-bit ASCII编码。
字符编码声明是以在源文件第一行或者第二行出现的一个魔法注释来实现的:
# coding=<encoding name>
至于为什么必须是第一行或者第二行,这个很好解释:既然要解释一个文件,必须在最开始的时候就知道字符编码,但是在Unix/Linux平台上,第一行可能留给了Python解释器声明,#!/usr/bin/python,这也是一个魔法注释。
如果声明的编码Python解释器不认识,那么在编译阶段(对于CPython,这就是指将py文件转换成pyc文件)就会报错。
如果声明的编码与实际不符(就是说,文件实际上是以另外的编码保存的),出错的可能性很大,但是并非一定会出错,毕竟编码之间可能有一定的重叠。
如果没有声明源文件的编码,但是却使用了7-bit ASCII之外的字符,那么在编译(对于CPython,这就是指将py文件转换成pyc文件)的时候会出错,并且显示SyntaxError。
非7-bit ASCII字符大部分出现在字符串字面常量中,一些人会认为使用unicode字符串字面常量会解决编码的问题,但这完全是另一个层面上的问题,如果源文件的编码没有弄对,根本还到不了讨论unicode字符串那一步。
对于Windows平台而言,如果源文件是以utf-8格式存储的,它会在文件的开头加上BOM(Byte Order Mark),对于utf-8,这就是\xef\xbb\xbf,此时,无需对文件编码进行声明,如果要声明的话,也必须是utf-8,否则编译出错。
交互式输入窗口是有源文件编码的,允许输入中文,显然不是ascii。
Windows和Unix/Linux的换行符序列不相同,有的时候这也可能导致问题。
总之,如果编码有问题,编译时就会出错,如果运行时输出乱码,那应该是没有使用unicode字符串或者输出窗口不支持的缘故。
参考文档:
http://www.python.org/dev/peps/pep-0263/
http://bugs.python.org/issue526840
这两个文档描述了一些实现相关的细节,值得一看。
有的人可能会说,既然源代码在文本编辑器中可以正常显示,说明编码没有问题,编辑器可以识别它,为什么Python还要求声明源代码的编码呢?
这是因为,明确地声明编码可以简化Python解释器的实现,免得它去猜测源文件的编码,这样既会增加解释器的复杂性,也会减慢程序的执行速度(毕竟是解释执行)。况且,程序运行必须是精确的,不能靠猜测。
从Python 2.3开始,可以在Python源文件中明确地声明字符编码,默认是7-bit ASCII编码。
字符编码声明是以在源文件第一行或者第二行出现的一个魔法注释来实现的:
# coding=<encoding name>
至于为什么必须是第一行或者第二行,这个很好解释:既然要解释一个文件,必须在最开始的时候就知道字符编码,但是在Unix/Linux平台上,第一行可能留给了Python解释器声明,#!/usr/bin/python,这也是一个魔法注释。
如果声明的编码Python解释器不认识,那么在编译阶段(对于CPython,这就是指将py文件转换成pyc文件)就会报错。
如果声明的编码与实际不符(就是说,文件实际上是以另外的编码保存的),出错的可能性很大,但是并非一定会出错,毕竟编码之间可能有一定的重叠。
如果没有声明源文件的编码,但是却使用了7-bit ASCII之外的字符,那么在编译(对于CPython,这就是指将py文件转换成pyc文件)的时候会出错,并且显示SyntaxError。
非7-bit ASCII字符大部分出现在字符串字面常量中,一些人会认为使用unicode字符串字面常量会解决编码的问题,但这完全是另一个层面上的问题,如果源文件的编码没有弄对,根本还到不了讨论unicode字符串那一步。
对于Windows平台而言,如果源文件是以utf-8格式存储的,它会在文件的开头加上BOM(Byte Order Mark),对于utf-8,这就是\xef\xbb\xbf,此时,无需对文件编码进行声明,如果要声明的话,也必须是utf-8,否则编译出错。
交互式输入窗口是有源文件编码的,允许输入中文,显然不是ascii。
Windows和Unix/Linux的换行符序列不相同,有的时候这也可能导致问题。
总之,如果编码有问题,编译时就会出错,如果运行时输出乱码,那应该是没有使用unicode字符串或者输出窗口不支持的缘故。
参考文档:
http://www.python.org/dev/peps/pep-0263/
http://bugs.python.org/issue526840
这两个文档描述了一些实现相关的细节,值得一看。
相关文章推荐
- Python源代码文件的文本编码
- python3-练习-爬取网站-中文编码-获取页面源代码-保存文件
- python中判断文件编码的chardet
- python open文件编码出错问题
- 利用nodepad++中的python script插件批量转换文件编码为utf-8
- Python文件编码不可以使用UTF16
- python 文件操作 中文编码
- python-读取目录中文件以及解决未知编码的中文乱码
- 采用python获得并修改文件编码(原创)
- python 文件中的中文编码解决方法
- 批量修改文本文件编码GB18030为UTF-8
- Non-ASCII character python文件中有中文编码出错 解决办法
- python实现批量转换文件编码(批转换编码示例)
- python中读写文件及中文编码处理方法【整理】
- python读取 .txt 文本内容以及将程序执行结果写入txt文件
- 今天在Mac机器上使用了Flex Builder编辑了一个源代码文件,保存后使用vim命令去打开时发现系统自动在每一行的结尾添加了^M符号,其实^M在Linux/Unix中是非常常见的,也就是我们在Win中见过的/r回车符号。由于编辑软件的编码问题,某些IDE的编辑器在编辑完文件之后会自动加上这个^M符号。看起来对我们的源代码没有任何影响,其实并不然,当我们把源代码文件Check In到svn之类
- Python处理unicode编码的txt文件(Python中文处理)——解决to_excel()和to_csv()导出文件内容为空的问题
- python 设置文件编码格式
- 【转载】关于Python脚本开头两行的:#!/usr/bin/python和# -*- coding: utf-8 -*-的作用 – 指定文件编码类型
- python实现文本文件转二进制文件(二进制序列化)