我現在在Ubuntu 13.04和Python 2.7.4上,並試圖運行包含以下行的腳本:ascii編解碼器無法解碼位於Ubuntu/Python中的位置錯誤中的字節0xe3,但無法在OS X/Python上解碼
html = unicode(html, 'cp932').encode('utf-8')
html1, html2 = html.split(some_text) # this line spits out the error
但是,當我在Ubuntu 13.04上運行上述腳本時,它發現錯誤UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 106: ordinal not in range(128)
。但是,這個完全相同的腳本總是可以在OS X 10.8和Python 2.7.3上成功執行。所以我想知道爲什麼錯誤只發生在兩個平臺之一...
我首先想到的是,特別是在看完這篇文章後(UnicodeDecodeError: 'ascii' codec can't decode byte 0xef in position 1)是因爲我處於不同的LANG
環境,我在OS X上使用jp_JP.UTF-8
,但在Ubuntu上使用en_US.UTF-8
。所以我也試着在上面提到的腳本中再增加一行os.environ['LANG'] = 'jp_JP.UTF-8'
,但是仍然有同樣的錯誤。
另一個奇怪的現象是,當我嘗試從Ubuntu的IPython shell中運行腳本並在錯誤發生後立即進入調試模式,然後運行最初觸發錯誤的行時,我沒有錯誤更多...
那麼這裏發生了什麼?我錯過了什麼?
在此先感謝。
'some_text'中有什麼?我的猜測是它是一個「unicode」對象,而不是「str」。如果是這樣,該行將有效地調用'unicode(html).split(some_text)',而這種隱式轉換就是失敗的地方。你能記錄每個平臺上的類型和字節並看看嗎? – abarnert
另外,您鏈接的問題與您的問題無關。正如接受的答案所說,用戶的問題不是關於他的代碼中的編碼和解碼,而是關於當他向終端打印時發生的隱式編碼。你不會在任何地方(或者至少不在這條線上)這麼做,所以它不會影響你。 (並且,即使它的確如此,你的兩個語言環境都使用UTF-8,所以這不會成爲問題。) – abarnert
PS,你爲什麼使用'unicode(html,'cp932')。encode('utf -8' )'?混合和匹配兩種不同的轉換方式並不違法,但這絕對是奇怪的。爲什麼不'html.decode('cp932')。encode('utf-8')'? – abarnert