计算机字符编码问题总析(基于Python)

时间:2023-01-10 22:31:55

本篇文章是一篇转载文章,阅读后使我对文本编码问题有了更清晰的认识,特征收藏分享之,感谢原作者。

转自:http://www.iteye.com/topic/560229

 

编程综合

 

http://blog.minidx.com/2008/10/22/1570.html

http://blog.minidx.com/2008/11/06/1607.html

http://blog.minidx.com/2008/12/06/1689.html

http://blog.minidx.com/2008/12/09/1700.html

 

 

摘录1:

 

 

GBK范围:
1st byte | 2nd byte
0×81~0xfe | 0×40~0×7e and 0×80~0xfe
BIG5范围:
1st byte | 2nd byte
0×81~0xfe | 0×40~0×7e and 0xa1~0xfe
下面是来自libiconv的关于GBK(cp936)和BIG5(cp950)的两段代码,相信还是相当有用的。

 

摘录2:

 

 

一 预备知识
1,字符:字符是抽象的最小文本单位。它没有固定的形状(可能是一个字形),而且没有值。“A”是一个字符,“€”(德国、法国和许多其他欧洲国家通用货币的标志)也是一个字符。“中”“国”这是两个汉字字符。字符仅仅代表一个符号,没有任何实际值的意义。
2,字符集:字符集是字符的集合。例如,汉字字符是中国人最先发明的字符,在中文、日文、韩文和越南文的书写中使用。这也说明了字符和字符集之间的关系,字符组成字符集(iso8859-1,GB2312/GBK,unicode)。
3,代码点:字符集中的每个字符都被分配到一个“代码点”。每个代码点都有一个特定的唯一数值,称为标值。该标量值通常用十六进制表示。
4,代码单元: 在每种编码形式中,代码点被映射到一个或多个代码单元。“代码单元”是各个编码方式中的单个单元。代码单元的大小等效于特定编码方式的位数:
UTF-8 :UTF-8 中的代码单元由 8 位组成;在 UTF-8 中,因为代码单元较小的缘故,每个代码点常常被映射到多个代码单元。代码点将被映射到一个、两个、三个或四个代码单元;
UTF-16 :UTF-16 中的代码单元由 16 位组成;UTF-16 的代码单元大小是 8 位代码单元的两倍。所以,标量值小于 U+10000 的代码点被编码到单个代码单元中;
UTF-32:UTF-32  中的代码单元由 32 位组成; UTF-32 中使用的 32 位代码单元足够大,每个代码点都可编码为单个代码单元;
GB18030:GB18030  中的代码单元由 8 位组成;在 GB18030 中,因为代码单元较小的缘故,每个代码点常常被映射到多个代码单元。代码点将被映射到一个、两个或四个代码单元。
5,举例:

“中国北京香蕉是个大笨蛋”这是我定义的aka字符集;各字符对应代码点为:
北 00000001
京 00000010
香 10000001
蕉 10000010
是 10000100
个 10001000
大 10010000
笨 10100000
蛋 11000000
中 00000100
国 00001000
下面是我定义的 zixia 编码方案(8位),可以看到它的编码中表示了aka字符集的所有字符对应的 代码单元;
北 10000001
京 10000010
香 00000001
蕉 00000010
是 00000100
个 00001000
大 00010000
笨 00100000
蛋 01000000
中 10000100
国 10001000
所谓文本文件 就是我们按一定编码方式将二进制数据表示为对应的文本如 00000001000000100000010000001000000100000010000001000000这样的文件。我用一个支持 zixia编码和aka字符集的记事本打开,它就按照编码方案显示为  “香蕉是个大笨蛋 ”
如果我把这些字符按照GBK另存一个文件,那么则肯定不是这个,而是
1100111111100011 1011110110110110 1100101011000111 1011100011110110 1011010011110011 1011000110111111 1011010110110000 110100001010

二,字符集
1, 常用字符集分类
ASCII及其扩展字符集
作用:表语英语及西欧语言。
位数:ASCII是用7位表示的,能表示128个字符;其扩展使用8位表示,表示256个字符。
范围:ASCII从00到7F,扩展从00到FF。
ISO-8859-1字符集
作用:扩展ASCII,表示西欧、希腊语等。
位数:8位,
范围:从00到FF,兼容ASCII字符集。
GB2312字符集
作用:国家简体中文字符集,兼容ASCII。
位数:使用2个字节表示,能表示7445个符号,包括6763个汉字,几乎覆盖所有高频率汉字。
范围:高字节从A1到F7, 低字节从A1到FE。将高字节和低字节分别加上0XA0即可得到编码。
BIG5字符集
作用:统一繁体字编码。
位数:使用2个字节表示,表示13053个汉字。
范围:高字节从A1到F9,低字节从40到7E,A1到FE。
GBK字符集
作用:它是GB2312的扩展,加入对繁体字的支持,兼容GB2312。
位数:使用2个字节表示,可表示21886个字符。
范围:高字节从81到FE,低字节从40到FE。
GB18030字符集
作用:它解决了中文、日文、朝鲜语等的编码,兼容GBK。
位数:它采用变字节表示(1 ASCII,2,4字节)。可表示27484个文字。
范围:1字节从00到7F; 2字节高字节从81到FE,低字节从40到7E和80到FE;4字节第一三字节从81到FE,第二四字节从30到39。
UCS字符集
作用:国际标准 ISO 10646 定义了通用字符集 (Universal Character Set)。它是与UNICODE同类的组织,UCS-2和UNICODE兼容。
位数:它有UCS-2和UCS-4两种格式,分别是2字节和4字节。
范围:目前,UCS-4只是在UCS-2前面加了0×0000。
UNICODE字符集
作用:为世界650种语言进行统一编码,兼容ISO-8859-1。
位数:UNICODE字符集有多个编码方式,分别是UTF-8,UTF-16和UTF-32。
2 ,按所表示的文字分类
语言                                 字符集                                     正式名称
英语、西欧语                     ASCII,ISO-8859-1                MBCS 多字节
简体中文                             GB2312                                    MBCS 多字节
繁体中文                             BIG5                                         MBCS 多字节
简繁中文                             GBK                                         MBCS 多字节
中文、日文及朝鲜语         GB18030                                  MBCS 多字节
各国语言                             UNICODE,UCS                    DBCS 宽字节

三,编码
UTF-8:采用变长字节 (1 ASCII, 2 希腊字母, 3 汉字, 4 平面符号) 表示,网络传输, 即使错了一个字节,不影响其他字节,而双字节只要一个错了,其他也错了,具体如下:
如果只有一个字节则其最高二进制位为0;如果是多字节,其第一个字节从最高位开始,连续的二进制位值为1的个数决定了其编码的字节数,其余各字节均以10开头。UTF-8最多可用到6个字节。

UTF-16:采用2字节,Unicode中不同部分的字符都同样基于现有的标准。这是为了便于转换。从 0×0000到0×007F是ASCII字符,从0×0080到0×00FF是ISO-8859-1对ASCII的扩展。希腊字母表使用从0×0370到 0×03FF 的代码,斯拉夫语使用从0×0400到0×04FF的代码,美国使用从0×0530到0×058F的代码,希伯来语使用从0×0590到0×05FF的代 码。中国、日本和韩国的象形文字(总称为CJK)占用了从0×3000到0×9FFF的代码;由于0×00在c语言及操作系统文件名等中有特殊意义,故很 多情况下需要UTF-8编码保存文本,去掉这个0×00。举例如下:
UTF-16: 0×0080  = 0000 0000 1000 0000
UTF-8:   0xC280 = 1100 0010 1000 0000
UTF-32:采用4字节。
优缺点
UTF-8、UTF-16和UTF-32都可以表示有效编码空间 (U+000000-U+10FFFF) 内的所有Unicode字符。
使用UTF-8编码时ASCII字符只占1个字节,存储效率比较高,适用于拉丁字符较多的场合以节省空间。
对于大多数非拉丁字符(如中文和日文)来说,UTF-16所需存储空间最小,每个字符只占2个字节。
Windows NT内核是Unicode(UTF-16),采用UTF-16编码在调用系统API时无需转换,处理速度也比较快。
采用UTF-16和UTF-32会有Big Endian和Little Endian之分,而UTF-8则没有字节顺序问题,所以UTF-8适合传输和通信。
UTF-32采用4字节编码,一方面处理速度比较快,但另一方面也浪费了大量空间,影响传输速度,因而很少使用。

四,如何判断字符集
1,字节序
首先说一下字节序对编码的影响,字节序分为Big Endian字节序和Little Endian字节序。不同的处理器可能不一样。所以,传输时需要告诉处理器当时的编码字节序。对于前者而言,高位字节存在低地址,低字节存于高地址;后者相反。例如,0X03AB,
Big Endian字节序
0000: 0 3
0001: AB
Little Endian字节序是
0000: AB
0001: 0 3
2,编码识别
UNICODE,根据前几个字节可以判断UNICODE字符集的各种编码,叫做Byte Order Mask方法BOM:
UTF-8: EFBBBF (符合UTF-8格式,请看上面。但没有含义在UCS即UNICODE中)
UTF-16 Big Endian:FEFF (没有含义在UCS-2中)
UTF-16 Little Endian:FFFE (没有含义在UCS-2中)
UTF-32 Big Endian:0000FEFF (没有含义在UCS-4中)
UTF-32 Little Endian:FFFE0000 (没有含义在UCS-4中)

GB2312:高字节和低字节的第1位都是1。

BIG5,GBK&GB18030:高字节的第1位为1。操作系统有默认的编码,常为GBK,可以下载别的并升级。通过判断高字节的第1位从而知道是ASCII或者汉字编码。

 

python与字符编码:

ASCII 是一种字符集,包括大小写的英文字母、数字、控制字符等,它用一个字节表示,范围是 0-127

Unicode分为UTF-8和UTF-16。UTF-8变长度的,最多 6 个字节,小于 127 的字符用一个字节表示,与 ASCII 字符集的结果一样,ASCII 编码下的英语文本不需要修改就可以当作 UTF-8 编码进行处理。

Python 从 2.2 开始支持 Unicode ,函数 decode( char_set )可以实现 其它编码到 Unicode 的转换函数 encode( char_set )实现 Unicode 到其它编码方式的转换

比如 ("你好").decode( "GB2312") 将得到 u'\u4f60\u597d',即 "你"和“好"的 Unicode 码分别是 0x4f60 和 0x597d
再用 (u'\u4f60\u597d').encode("UTF-8") 将得到 '\xe4\xbd\xa0\xe5\xa5\xbd',它是  “你好”的UTF-8编码结果。


python中使用 unicode的关键:unicode是一个类,函数unicode(str,"utf8")从utf8编码(当然也可以是别的编码)的字符串str生成 unicode类的对象,而函数unc.encode("utf8")将unicode类的对象unc转换为(编码为)utf8编码(当然也可以是别的编码)的字符串。于是,编写unicode相关程序,需要做的事情是

    * 获取数据(字符串)时,用unicode(str, "utf8")生成unicode对象
    * 在程序中仅使用unicode对象,对程序中出现的字符串常量都以u"字符串"的形式书写
    * 输出时,可将unicode对象转换为任意编码输出,使用str.encode("some_encoding")

>>> unicode("你好", "utf8")
u'\u4f60\u597d'
>>> x = _
>>> type(x)
<type 'unicode'>
>>> type("你好")
<type 'str'>
>>> x.encode("utf8")
'\xe4\xbd\xa0\xe5\xa5\xbd'
>>> x.encode("gbk")
'\xc4\xe3\xba\xc3'
>>> x.encode("gb2312")
'\xc4\xe3\xba\xc3'
>>> print x
你好
>>> print x.encode("utf8")
你好
>>> print x.encode("gbk")
???

 

python里面基本上要考虑三种编码格式

1 源文件编码
在文件头部使用coding声明。告诉python解释器该代码文件所使用的字符集。
#/usr/bin/python
#coding: utf8

2 内部编码
代码文件中的字符串,经过decode以后,被转换为统一的unicode格式的内部数据,类似于u'*'。unicode数据可以使用encode函数,再*转换为其他格式的数据,相当于一个统一的平台。

直接输入unicode数据
>>> u'你好'
u'\u4f60\u597d'

将unicode数据转换为gb2312格式
>>> u'你好'.encode('gb2312')
'\xc4\xe3\xba\xc3'

将输入的gb2312格式的数据解码为unicode
>>> '你好'.decode('gb2312')
u'\u4f60\u597d'
输入数据的格式取决于所用shell终端的编码设置,本例中为zh_CN
[root@chenzheng python]# echo $LANG
zh_CN

解码同时转换为utf8
>>> '你好'.decode('gb2312').encode('utf8')
'\xe4\xbd\xa0\xe5\xa5\xbd'

3 外部输入的编码
其实这个和在python交互shell中输入的字符串,所遇到的情况基本一样。但程序中常常用到从网络,文件读取的数据,故此单独列出,需要特别注意其编码格式是否于系统要求相符。

下面是baidu中文本周金曲榜的链接,返回一个xml文件,编码格式为gb2312
http://box.zhangmen.baidu.com/x?op=4&listid=1

由于xml.etree.EelementTree.parse()不识别gb2312编码,在解析的时候,需要将其转换utf8格式才可以,可以使用下面的函数
def read_page(url):
"""读取gb2312编码的xml文件,转换为utf8格式"""
import urllib
udata = urllib.urlopen(url).read().decode('gb2312')
u8data = udata.encode('utf8')
return u8data.replace('gb2312', 'utf-8') #简单替换xml文件第一行的encoding属性值

另外,可以使用一个小函数来判断数据的编码格式:
def encoding(s):
cl = ['utf8', 'gb2312']
for a in cl:
try:
s.decode(a)
return a
except UnicodeEncodeError:
pass
return 'unknown' 

 

被广泛转载的“Python中使用中文

我也转载一下:

 

 

1. 在Python中使用中文
Python中有两种默认的字符串:str和unicode。在Python中一定要注意区分“Unicode字符串”和“unicode对象”的区别。后面所有的“unicode字符串”指的都是python里的“unicode对象”。
事实上在Python中并没有“Unicode字符串”这样的东西,只有“unicode”对象。一个传统意义上的unicode字符串完全可以用str对象表示。只是这时候它仅仅是一个字节流,除非解码为unicode对象,没有任何实际的意义。
我们用“哈哈”在多个平台上测试,其中“哈”对应的不同编码是:
1. UNICODE (UTF8-16), C854;
2. UTF-8, E59388;
3. GBK, B9FE。
1.1 Windows控制台
下面是在windows控制台的运行结果:
计算机字符编码问题总析(基于Python)
可以看出在控制台,中文字符的编码是GBK而不是UTF-16。将字符串s(GBK编码)使用decode进行解码后,可以得到同等的unicode对象。
注意:可以在控制台打印ss并不代表它可以直接被序列化,比如:
计算机字符编码问题总析(基于Python)
向文件直接输出ss会抛出同样的异常。在处理unicode中文字符串的时候,必须首先对它调用encode函数,转换成其它编码输出。这一点对各个环境都一样。
总结:在Python中,“str”对象就是一个字节数组,至于里面的内容是不是一个合法的字符串,以及这个字符串采用什么编码(gbk, utf-8,unicode)都不重要。这些内容需要用户自己记录和判断。这些的限制也同样适用于“unicode”对象。要记住“unicode”对象中的内容可绝对不一定就是合法的unicode字符串,我们很快就会看到这种情况。
总结:在windows的控制台上,支持gbk编码的str对象和unicode编码unicode对象。
1.2 Windows IDLE(在Shell上运行)
在windows下的IDLE中,运行效果和windows控制台不完全一致:
可以看出,对于不使用“u”作标识的字符串,IDLE把其中的中文字符进行GBK编码。但是对于使用“u”的unicode字符串,IDLE居然一样是用了GBK编码,不同的是,这时候每一个字符都是unicode(对象)字符!!此时len(ss) = 4。
这样产生了一个神奇的问题,现在的ss无法在IDLE中正常显示。而且我也没有办法把ss转换成正常的编码!比如采用下面的方法:
这有可能是因为IDLE本地化做得不够好,对中文的支持有问题。建议在IDLE的SHELL中,不要使用u“中文”这种方式,因为这样得到的并不是你想要的东西。
这同时说明IDLE的Shell支持两种格式的中文字符串:GBK编码的“str”对象,和UNICODE编码unicode对象。
1.3 在IDLE上运行代码
在IDLE的SHELL上运行文件,得到的又是不同的结果。文件的内容是:
直接运行的结果是:
毫无瑕疵,相当令人满意。我没有试过其它编码的文件是否能正常运行,但想来应该是不错的。
同样的代码在windows的控制台试演过,也没有任何问题。
1.4 Windows Eclipse
在Eclipse中处理中文更加困难,因为在Eclipse中,编写代码和运行代码属于不同的窗口,而且他们可以有不同的默认编码。对于如下代码:

代码: #!/usr/bin/python
# -*- coding: utf-8 -*-
 
s = "哈哈"
ss = u'哈哈'
 
print repr(s)
print repr(ss)
 
print s.decode('utf-8').encode('gbk')
print ss.encode('gbk')
 
print s.decode('utf-8')
print ss



前四个print运行正常,最后两个print都会抛出异常:

代码: '\xe5\x93\x88\xe5\x93\x88'
u'\u54c8\u54c8'
哈哈
哈哈
Traceback (most recent call last):
 File "E:\Workspace\Eclipse\TestPython\Test\test_encoding_2.py", line 13in <module>
    print s.decode('utf-8')
UnicodeEncodeError'ascii' codec can't encode characters in position 0-1: ordinal not in range(128)


也就是说,GBK编码的str对象可以正常打印,但是不能打印UNICODE编码unicode对象。在源文件上点击“Run as”“Run”,然后在弹出对话框中选择“Common”:
计算机字符编码问题总析(基于Python)
可以看出Eclipse控制台的缺省编码方式是GBK;所以不支持UNICODE也在情理之中。如果把文件中的coding修改成GBK,则可以直接打印GBK编码的str对象,比如s。
如果把源文件的
编码设置成“UTF-8”,把控制台的编码也设置成“UTF-8”,按道理说打印的时候应该没有问题。但是实验表明,在打印UTF-8编码的str对象时,中文的最后一个字符会显示成乱码,无法正常阅读。不过我已经很满足了,至少人家没有抛异常不是:)
BTW: 使用的Eclipse版本是3.2.1。
1.5 从文件读取中文
在window下面用记事本编辑文件的时候,如果保存为
UNICODEUTF-8,分别会在文件的开头加上两个字节“\xFF\xFE”和三个字节“\xEF\xBB\xBF”。在读取的时候就可能会遇到问题,但是不同的环境对这几个多于字符的处理也不一样。
以windows下的控制台为例,用记事本保存三个不同版本的“哈哈”。
计算机字符编码问题总析(基于Python)
打开utf-8格式的文件并读取utf-8字符串后,解码变成unicode对象。但是会把附加的三个字符同样进行转换,变成一个unicode字符,字符的数据值为“\xFF\xFE”。这个字符不能被打印。编码的时候需要跳过这个字符。
计算机字符编码问题总析(基于Python)
打开unicode格式的文件后,得到的字符串正确。这时候适用utf-16解码,能得到正确的unicdoe对象,可以直接使用。多余的那个填充字符在进行转换时会被过滤掉。
计算机字符编码问题总析(基于Python)
打开ansi格式的文件后,没有填充字符,可以直接使用。
结论:读写使用python生成的文件没有任何问题,但是在处理由notepad生成的文本文件时,如果该文件可能是非ansi编码,需要考虑如何处理填充字符。
1.6 在数据库中使用中文
刚刚接触Python,我用的数据库是mysql。在执行插入、查找等操作时,如果运行环境使用的字符编码和mysql不一致,就可能导致运行时的错误。当然,和上面看到的情况一样,运行环境并不是关键因素,关键是查询语句的编码方式。如果在每次执行查询操作时都把查询字符串做一次编码转换,转变成mysql的默认字符编码,一样不会遇到问题。但是这样写代码也太痛苦了吧。
使用如下代码连接数据库:
self.conn = MySQLdb.connect(use_unicode = 1, charset='utf8', **server)
我不能理解的是既然数据库用的默认编码UTF-8,我连接的时候也用的是UTF-8,为什么查询得到的文本内容却是UNICODE编码unicode对象)?这是MySQLdb库的设置么?
1.7 在XML中使用中文
使用xml.dom.minidom和MySQLdb类似,对生成的dom对象调用toxml方法得到的是unicode对象。如果希望输出utf-8文本,有两种方法:
1.使用系统函数
在输出xml文档的时候进行编码,这是我觉得最好的方法。

代码: xmldoc.toxml(encoding=’utf-8)
xmldoc.writexml(outfile, encoding = ‘utf-8)


2.自己编码生成
在使用toxml之后可以调用encode方法对文档进行编码。但这种方法无法得到合适的xml declaration(xml文档第一行中的encoding部分)。
不要尝试通过xmldoc.createProcessingInstruction来创建一个processing instraction:
<?xml version=’1.0’ encoding=’utf-8’?>
xml declaration虽然看起来像是,但是事实上并不是一个processing instraction。可以通下面的方法得到一个满意的xml文件:

代码: print >> outfile, “<?xml version=’1.0’ encoding=’utf-8?>
print >> outfile, xmldoc.toxml().encode(utf-8)[22:]


其中第二行需要过滤掉在调用xmldoc.toxml时生成的“<?xml version=’1.0’ ?>”,它的长度是22。

相面是两种方法的用法比较:
计算机字符编码问题总析(基于Python)
另外,在IDLE的shell中,不要用 u’中文’ 对属性进行赋值。上面讨论过,这样得到的unicode字符串不正确。