字符串在Python內(nèi)部的表示是unicode編碼，因此，在做編碼轉(zhuǎn)換時(shí)，通常需要以u(píng)nicode作為中間編碼，即先將其他編碼的字符串解碼（decode）成unicode，再?gòu)膗nicode編碼（encode）成另一種編碼。

decode的作用是將其他編碼的字符串轉(zhuǎn)換成unicode編碼，如str1.decode('gb2312')，表示將gb2312編碼的字符串str1轉(zhuǎn)換成unicode編碼。

encode的作用是將unicode編碼轉(zhuǎn)換成其他編碼的字符串，如str2.encode('gb2312')，表示將unicode編碼的字符串str2轉(zhuǎn)換成gb2312編碼。

代碼中字符串的默認(rèn)編碼與代碼文件本身的編碼一致。

如：s='中文'

如果是在utf8的文件中，該字符串就是utf8編碼，如果是在gb2312的文件中，則其編碼為gb2312。這種情況下，要進(jìn)行編碼轉(zhuǎn)換，都需要先用decode方法將其轉(zhuǎn)換成unicode編碼，再使用encode方法將其轉(zhuǎn)換成其他編碼。

如果字符串是這樣定義：s=u'中文'

則該字符串的編碼就被指定為unicode了，即python的內(nèi)部編碼，而與代碼文件本身的編碼無(wú)關(guān)。因此，對(duì)于這種情況做編碼轉(zhuǎn)換，只需要直接使用encode方法將其轉(zhuǎn)換成指定編碼即可。

如果一個(gè)字符串已經(jīng)是unicode了，再進(jìn)行解碼則將出錯(cuò)，因此通常要對(duì)其編碼方式是否為unicode進(jìn)行判斷：

isinstance(s, unicode) #用來(lái)判斷是否為unicode

用非unicode編碼形式的str來(lái)encode會(huì)報(bào)錯(cuò)

如何獲得系統(tǒng)的默認(rèn)編碼？

#!/usr/bin/env python
#coding=utf-8
import sys
print sys.getdefaultencoding()

該段程序在英文WindowsXP上輸出為：ascii

在某些IDE中，字符串的輸出總是出現(xiàn)亂碼，甚至錯(cuò)誤，其實(shí)是由于IDE的結(jié)果輸出控制臺(tái)自身不能顯示字符串的編碼，而不是程序本身的問(wèn)題。

如在UliPad中運(yùn)行如下代碼：

s=u"中文"
print s

會(huì)提示：UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordinal not in range(128)。這是因?yàn)閁liPad在英文WindowsXP上的控制臺(tái)信息輸出窗口是按照ascii編碼輸出的（英文系統(tǒng)的默認(rèn)編碼是ascii），而上面代碼中的字符串是Unicode編碼的，所以輸出時(shí)產(chǎn)生了錯(cuò)誤。

將最后一句改為：print s.encode('gb2312')

則能正確輸出“中文”兩個(gè)字。

若最后一句改為：print s.encode('utf8')

則輸出：\xe4\xb8\xad\xe6\x96\x87，這是控制臺(tái)信息輸出窗口按照ascii編碼輸出utf8編碼的字符串的結(jié)果。

unicode(str,'gb2312')與str.decode('gb2312')是一樣的，都是將gb2312編碼的str轉(zhuǎn)為unicode編碼

使用str.__class__可以查看str的編碼形式

如果將Unicode作為dict的key或者value，在print key時(shí)能看到正確的字符，但print dict則是原始的Unicode字節(jié)數(shù)據(jù)。

? ?name = u'喬治克魯尼'

? ? sex = u'男'

? ? my_dict = {}

? ? my_dict[name] = sex

? ? for key in my_dict:

? ? ? ? print key

? ? print my_dict

輸出：

? ? ? ? 喬治克魯尼

? ? ? ? {u'\u4e54\u6cbb\u514b\u9c81\u5c3c': u'\u7537'}

1.????????在Python中使用中文

python中默認(rèn)的encoding是ASCII.它有兩種字符串分別是str(每字符用一個(gè)字節(jié))和Unicode字符串(每字符用一個(gè)或多個(gè)字節(jié)表示,本質(zhì)上為Unicode對(duì)象)，它們可以互相轉(zhuǎn)換。對(duì)于一個(gè)Unicode字符串用str對(duì)象表示時(shí)，就是一個(gè)字節(jié)流，除非解碼為Unicode對(duì)象，否則沒(méi)有任何意義。
在Python中有兩種默認(rèn)的字符串：str和unicode。在Python中一定要注意區(qū)分“Unicode字符串”和“unicode對(duì)象”的區(qū)別。后面所有的“unicode字符串”指的都是python里的“unicode對(duì)象”。事實(shí)上在Python中并沒(méi)有“Unicode字符串”這樣的東西，只有“unicode”對(duì)象。一個(gè)傳統(tǒng)意義上的unicode字符串完全可以用str對(duì)象表示。只是這時(shí)候它僅僅是一個(gè)字節(jié)流，除非解碼為unicode對(duì)象，沒(méi)有任何實(shí)際的意義。我們用“哈哈”在多個(gè)平臺(tái)上測(cè)試，其中“哈”對(duì)應(yīng)的不同編碼是：1．??????????????UNICODE (UTF8-16)，????? C854；2．??????????????UTF-8，??????????????????? E59388；3．??????????????GBK，?????????????? B9FE。1.1?????Windows控制臺(tái)下面是在windows控制臺(tái)的運(yùn)行結(jié)果：可以看出在控制臺(tái)，中文字符的編碼是GBK而不是UTF-16。將字符串s（GBK編碼）使用decode進(jìn)行解碼后，可以得到同等的unicode對(duì)象。注意：可以在控制臺(tái)打印ss并不代表它可以直接被序列化，比如：向文件直接輸出ss會(huì)拋出同樣的異常。在處理unicode中文字符串的時(shí)候，必須首先對(duì)它調(diào)用encode函數(shù)，轉(zhuǎn)換成其它編碼輸出。這一點(diǎn)對(duì)各個(gè)環(huán)境都一樣。總結(jié)：在Python中，“str”對(duì)象就是一個(gè)字節(jié)數(shù)組，至于里面的內(nèi)容是不是一個(gè)合法的字符串，以及這個(gè)字符串采用什么編碼（gbk, utf-8, unicode）都不重要。這些內(nèi)容需要用戶自己記錄和判斷。這些的限制也同樣適用于“unicode”對(duì)象。要記住“unicode”對(duì)象中的內(nèi)容可絕對(duì)不一定就是合法的unicode字符串，我們很快就會(huì)看到這種情況。總結(jié)：在windows的控制臺(tái)上，支持gbk編碼的str對(duì)象和unicode編碼的unicode對(duì)象。1.2?????Windows IDLE（在Shell上運(yùn)行）在windows下的IDLE中，運(yùn)行效果和windows控制臺(tái)不完全一致：可以看出，對(duì)于不使用“u”作標(biāo)識(shí)的字符串，IDLE把其中的中文字符進(jìn)行GBK編碼。但是對(duì)于使用“u”的unicode字符串，IDLE居然一樣是用了GBK編碼，不同的是，這時(shí)候每一個(gè)字符都是unicode（對(duì)象）字符！！此時(shí)len(ss) = 4。這樣產(chǎn)生了一個(gè)神奇的問(wèn)題，現(xiàn)在的ss無(wú)法在IDLE中正常顯示。而且我也沒(méi)有辦法把ss轉(zhuǎn)換成正常的編碼！比如采用下面的方法：這有可能是因?yàn)镮DLE本地化做得不夠好，對(duì)中文的支持有問(wèn)題。建議在IDLE的SHELL中，不要使用u“中文”這種方式，因?yàn)檫@樣得到的并不是你想要的東西。這同時(shí)說(shuō)明IDLE的Shell支持兩種格式的中文字符串：GBK編碼的“str”對(duì)象，和UNICODE編碼的unicode對(duì)象。1.3?????在IDLE上運(yùn)行代碼在IDLE的SHELL上運(yùn)行文件，得到的又是不同的結(jié)果。文件的內(nèi)容是：直接運(yùn)行的結(jié)果是：毫無(wú)瑕疵，相當(dāng)令人滿意。我沒(méi)有試過(guò)其它編碼的文件是否能正常運(yùn)行，但想來(lái)應(yīng)該是不錯(cuò)的。同樣的代碼在windows的控制臺(tái)試演過(guò)，也沒(méi)有任何問(wèn)題。1.4?????Windows Eclipse在Eclipse中處理中文更加困難，因?yàn)樵贓clipse中，編寫(xiě)代碼和運(yùn)行代碼屬于不同的窗口，而且他們可以有不同的默認(rèn)編碼。對(duì)于如下代碼：#!/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?前四個(gè)print運(yùn)行正常，最后兩個(gè)print都會(huì)拋出異常：'\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 13, in <module>??? print s.decode('utf-8')UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordinal not in range(128)也就是說(shuō)，GBK編碼的str對(duì)象可以正常打印，但是不能打印UNICODE編碼的unicode對(duì)象。在源文件上點(diǎn)擊“Run as”“Run”，然后在彈出對(duì)話框中選擇“Common”：可以看出Eclipse控制臺(tái)的缺省編碼方式是GBK；所以不支持UNICODE也在情理之中。如果把文件中的coding修改成GBK，則可以直接打印GBK編碼的str對(duì)象，比如s。如果把源文件的編碼設(shè)置成“UTF-8”，把控制臺(tái)的編碼也設(shè)置成“UTF-8”，按道理說(shuō)打印的時(shí)候應(yīng)該沒(méi)有問(wèn)題。但是實(shí)驗(yàn)表明，在打印UTF-8編碼的str對(duì)象時(shí)，中文的最后一個(gè)字符會(huì)顯示成亂碼，無(wú)法正常閱讀。不過(guò)我已經(jīng)很滿足了，至少人家沒(méi)有拋異常不是:)BTW: 使用的Eclipse版本是3.2.1。1.5?????從文件讀取中文在window下面用記事本編輯文件的時(shí)候，如果保存為UNICODE或UTF-8，分別會(huì)在文件的開(kāi)頭加上兩個(gè)字節(jié)“\xFF\xFE”和三個(gè)字節(jié)“\xEF\xBB\xBF”。在讀取的時(shí)候就可能會(huì)遇到問(wèn)題，但是不同的環(huán)境對(duì)這幾個(gè)多于字符的處理也不一樣。以windows下的控制臺(tái)為例，用記事本保存三個(gè)不同版本的“哈哈”。?

打開(kāi)utf-8格式的文件并讀取utf-8字符串后，解碼變成unicode對(duì)象。但是會(huì)把附加的三個(gè)字符同樣進(jìn)行轉(zhuǎn)換，變成一個(gè)unicode字符，字符的數(shù)據(jù)值為“\xFF\xFE”。這個(gè)字符不能被打印。編碼的時(shí)候需要跳過(guò)這個(gè)字符。

打開(kāi)unicode格式的文件后，得到的字符串正確。這時(shí)候適用utf-16解碼，能得到正確的unicdoe對(duì)象，可以直接使用。多余的那個(gè)填充字符在進(jìn)行轉(zhuǎn)換時(shí)會(huì)被過(guò)濾掉。?打開(kāi)ansi格式的文件后，沒(méi)有填充字符，可以直接使用。結(jié)論：讀寫(xiě)使用python生成的文件沒(méi)有任何問(wèn)題，但是在處理由notepad生成的文本文件時(shí)，如果該文件可能是非ansi編碼，需要考慮如何處理填充字符。1.6?????在數(shù)據(jù)庫(kù)中使用中文剛剛接觸Python，我用的數(shù)據(jù)庫(kù)是mysql。在執(zhí)行插入、查找等操作時(shí)，如果運(yùn)行環(huán)境使用的字符編碼和mysql不一致，就可能導(dǎo)致運(yùn)行時(shí)的錯(cuò)誤。當(dāng)然，和上面看到的情況一樣，運(yùn)行環(huán)境并不是關(guān)鍵因素，關(guān)鍵是查詢語(yǔ)句的編碼方式。如果在每次執(zhí)行查詢操作時(shí)都把查詢字符串做一次編碼轉(zhuǎn)換，轉(zhuǎn)變成mysql的默認(rèn)字符編碼，一樣不會(huì)遇到問(wèn)題。但是這樣寫(xiě)代碼也太痛苦了吧。使用如下代碼連接數(shù)據(jù)庫(kù)：self.conn = MySQLdb.connect(use_unicode =?1, charset='utf8', **server)我不能理解的是既然數(shù)據(jù)庫(kù)用的默認(rèn)編碼是UTF-8，我連接的時(shí)候也用的是UTF-8，為什么查詢得到的文本內(nèi)容卻是UNICODE編碼（unicode對(duì)象）？這是MySQLdb庫(kù)的設(shè)置么？1.7?????在XML中使用中文使用xml.dom.minidom和MySQLdb類(lèi)似，對(duì)生成的dom對(duì)象調(diào)用toxml方法得到的是unicode對(duì)象。如果希望輸出utf-8文本，有兩種方法：1．使用系統(tǒng)函數(shù)在輸出xml文檔的時(shí)候進(jìn)行編碼，這是我覺(jué)得最好的方法。xmldoc.toxml(encoding=’utf-8’)xmldoc.writexml(outfile, encoding = ‘utf-8’)2．自己編碼生成在使用toxml之后可以調(diào)用encode方法對(duì)文檔進(jìn)行編碼。但這種方法無(wú)法得到合適的xml declaration（xml文檔第一行中的encoding部分）。不要嘗試通過(guò)xmldoc.createProcessingInstruction來(lái)創(chuàng)建一個(gè)processing instraction：<?xml version=’1.0’ encoding=’utf-8’?>xml declaration雖然看起來(lái)像是，但是事實(shí)上并不是一個(gè)processing instraction。可以通下面的方法得到一個(gè)滿意的xml文件：print >> outfile,?“<?xml version=’1.0’ encoding=’utf-8’?>”
print >> outfile, xmldoc.toxml().encode(‘utf-8’)[22:]
其中第二行需要過(guò)濾掉在調(diào)用xmldoc.toxml時(shí)生成的“<?xml version=’1.0’ ?>”，它的長(zhǎng)度是22。?相面是兩種方法的用法比較：?另外，在IDLE的shell中，不要用 u’中文’ 對(duì)屬性進(jìn)行賦值。上面討論過(guò)，這樣得到的unicode字符串不正確。

轉(zhuǎn)載于:https://www.cnblogs.com/aquar/archive/2010/05/01/3451436.html

總結(jié)

以上是生活随笔為你收集整理的Python中文处理(转)的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。