寫python腳本的時(shí)候發(fā)現(xiàn)這樣一個(gè)問題：從xls文件導(dǎo)出到txt時(shí)，無法直接轉(zhuǎn)換為int型數(shù)據(jù)，輸出查看發(fā)現(xiàn)和文件編碼方式產(chǎn)生的附加信息有關(guān)用一個(gè)簡單的文件舉例

90905

90907

90908

90909

90939

90940

90946

90959

90961

90965

當(dāng)文件分別用ascii，utf8，utf8 bom作為編碼格式時(shí)，顯示輸出結(jié)果如下：

使用ascii編碼的輸出：

['90905\r\n', '90907\r\n', '90908\r\n', '90909\r\n', '90939\r\n', '90940\r\n', '90946\r\n', '90959\r\n', '90961\r\n', '90965']

使用utf8編碼的輸出：

['90905\r\n', '90907\r\n', '90908\r\n', '90909\r\n', '90939\r\n', '90940\r\n', '90946\r\n', '90959\r\n', '90961\r\n', '90965']

使用bom編碼的輸出：

['\xef\xbb\xbf90905\r\n', '90907\r\n', '90908\r\n', '90909\r\n', '90939\r\n', '90940\r\n', '90946\r\n', '90959\r\n', '90961\r\n', '90965']

原來utf8 bom不能直接轉(zhuǎn)換int的原因在這里，它在文件頭插入了一個(gè)表示文件編碼的信息\xef\xbb\xbf，那么UTF-8(無BOM）和UTF－8這兩個(gè)有什么區(qū)別呢？BOM是什么呢？

什么是BOM？

BOM: Byte Order Mark

UTF-8 BOM又叫UTF-8 簽名,其實(shí)UTF-8 的BOM對(duì)UFT-8沒有作用,是為了支持UTF-16,UTF-32才加上的

BOM,BOM簽名的意思就是告訴編輯器當(dāng)前文件采用何種編碼,方便編輯器識(shí)別,但是BOM雖然在編輯器中不顯示,但是會(huì)產(chǎn)生輸出,就像多了一個(gè)空行。

Byte Order Marks are special characters at the beginning of a Unicode file to indicate whether it is big or little endian, in other words does the high or low order byte come first. These codes also tell whether the encoding is 8, 16 or 32 bit. You can recognise Unicode files by their starting byte order marks, and by the way Unicode-16 files are half zeroes and Unicode-32 files are three-quarters zeros. Unicode Endian Markers

Byte-order mark Description
EF BB BF UTF-8
FF FE UTF-16 aka UCS-2, little endian
FE FF UTF-16 aka UCS-2, big endian
00 00 FF FE UTF-32 aka UCS-4, little endian.
00 00 FE FF UTF-32 aka UCS-4, big-endian.

UTF的字節(jié)序和BOM

UTF-8以字節(jié)為編碼單元，沒有字節(jié)序的問題。UTF-16以兩個(gè)字節(jié)為編碼單元，在解釋一個(gè)UTF-16文本前，首先要弄清楚每個(gè)編碼單元的字節(jié)序。例如收到一個(gè)“奎”的Unicode編碼是594E，“乙”的Unicode編碼是4E59。如果我們收到UTF-16字節(jié)流“594E”，那么這是“奎”還是“乙”？

Unicode規(guī)范中推薦的標(biāo)記字節(jié)順序的方法是BOM。BOM不是“Bill Of Material”的BOM表，而是Byte Order Mark。BOM是一個(gè)有點(diǎn)小聰明的想法：

在UCS編碼中有一個(gè)叫做'ZERO WIDTH NO-BREAK SPACE'的字符，它的編碼是FEFF。而FFFE在UCS中是不存在的字符，所以不應(yīng)該出現(xiàn)在實(shí)際傳輸中。UCS規(guī)范建議我們?cè)趥鬏斪止?jié)流前，先傳輸字符'ZERO WIDTH NO-BREAK SPACE'。

這樣如果接收者收到FEFF，就表明這個(gè)字節(jié)流是Big-Endian的；如果收到FFFE，就表明這個(gè)字節(jié)流是Little-Endian的。因此字符'ZERO WIDTH NO-BREAK SPACE'又被稱作BOM。

UTF-8不需要BOM來表明字節(jié)順序，但可以用BOM來表明編碼方式。字符'ZERO WIDTH NO-BREAK SPACE'的UTF-8編碼是EF BB BF。所以如果接收者收到以EF BB BF開頭的字節(jié)流，就知道這是UTF-8編碼了。

Windows就是使用BOM來標(biāo)記文本文件的編碼方式的。

原來BOM是在文件的開始加了幾個(gè)字節(jié)作為標(biāo)記。有了這個(gè)標(biāo)記，一些協(xié)議和系統(tǒng)才能識(shí)別。

ok,說了這么多背景，那么如何解決這個(gè)問題呢？

如何使用BOM頭

BOM頭的刪除

對(duì)UTF-16, Python將BOM解碼為空字串。然而對(duì)UTF-8, BOM被解碼為一個(gè)字符，如例：

簡單的做法是在文件讀入時(shí)使用

即可，具體可以參見[http://docs./library/codecs.html#module-encodings.utf_8_sig|http://docs./library/codecs.html#module-encodings.utf_8_sig]

或者：

BOM頭的添加

詳細(xì)的過程解釋可以參見[http:///jgloss/encoding.html|http:///jgloss/encoding.html]

參考資料：

[http://blog.sina.com.cn/s/blog_3e9d2b350100as0b.html|http://blog.sina.com.cn/s/blog_3e9d2b350100as0b.html]

[http://4nail./blog/840612|http://4nail./blog/840612]