在Ubuntu上運(yùn)行的Python 2.7中，此代碼：f = open("testfile.txt", "w")f.write("Line one".encode("utf-16"))f.write(u"\r\n".encode("utf-16"))f.write("Line two".encode("utf-16"))在Gedit中讀取時，在兩行文本之間產(chǎn)生所需的換行符：Line one??Line two但是，在Windows 7中執(zhí)行并在記事本中讀取的相同代碼在“第一行”之后產(chǎn)生難以理解的字符，但記事本無法識別換行符。如何在Windows中為UTF-16編寫正確的換行符，以匹配我在Ubuntu中獲得的輸出？我正在為僅讀取Unicode UTF-16的Windows應(yīng)用程序編寫輸出。我已經(jīng)花了數(shù)小時嘗試各種技巧，但記事本似乎無濟(jì)于事。值得一提的是，我可以在記事本中成功地將文本文件轉(zhuǎn)換為UTF-16，但是我希望腳本首先正確地保存編碼。
1 回答
函數(shù)式編程
TA貢獻(xiàn)1807條經(jīng)驗(yàn) 獲得超9個贊
問題在于您正在以文本模式打開文件，但是試圖將其用作二進(jìn)制文件。
這個：
u"\r\n".encode("utf-16")
…編碼為'\r\0\n\0'。
然后這樣：
f.write('\r\0\n\0')
…將Unix換行符轉(zhuǎn)換為Windows換行符，給出'\r\0\r\n\0'。
而且，這當(dāng)然會破壞您的UTF-16編碼。除了這兩個\r\n字節(jié)將解碼為有效但未分配的代碼點(diǎn)U + 0A0D的事實(shí)之外，這是一個奇數(shù)個字節(jié)，這意味著您還有一個余數(shù)\0。因此，它不是L\0的下一個字符，而是\0L，aka?等。
最重要的是，您可能正在為每個編碼字符串編寫一個新的UTF-16 BOM。大多數(shù)Windows應(yīng)用程序?qū)嶋H上會透明地處理該問題并忽略它們，因此您實(shí)際上所做的只是浪費(fèi)兩個字節(jié)/行，但這實(shí)際上是不正確的。
解決第一個問題的快速方法是以二進(jìn)制模式打開文件：
f = open("testfile.txt", "wb")
這不能解決多物料清單問題，但可以解決損壞的\n問題。如果要解決BOM表問題，則可以使用有狀態(tài)編碼，或者為除首次寫入外的所有寫入明確指定'utf-16-le'（或'utf-16-be'）。
但是，解決這兩個問題的簡單方法是使用模塊（對于舊的Python 2.x，則使用該模塊）為您完成所有艱苦的工作：iocodecs
f = io.open("testfile.txt", "w", encoding="utf-8")
f.write("Line one")
f.write(u"\r\n")
f.write("Line two")
添加回答
舉報(bào)
0/150
提交
取消