Python Unicode編碼混亂：來自大洋彼岸的怨念

Unicode已經解決了很多問題。知曉ISO-8859-*和CP437帶來的混亂（當然對於非西方語言來說更糟糕）的人都可以證明這一點。當然，這些天他們正在做一項有的益工作——編碼表情符號。

除表情符號之外，一切並不那麼順暢。今日Python 3帶來的痛苦更是一言難盡。

Python決定將Unicode完全集成到語言中。聽起來很不錯吧？

但眾多問題也隨之而來。

例如，將帶有智能引號的「播客」標題轉為以ASCII編碼會引致python錯誤，導致gPodder（一款開源的播客接收器，採用Python和PyGTK開發，可幫助管理播客RSS供稿，並自動下載所需要的播客資料）經常通過回溯退出。接著pexpect文檔會告訴你用

文件名的處理可謂糟糕透頂。我最近處理了20年前當UTF-8還未成為文件名標準時的數據。這些文件名在UNIX上仍然有效，可以用tar命令進行壓縮或解壓。但當你試圖將文件名以字元串的形式存儲，編碼錯誤便接踵而至。要想讓Python程序正確地支持所有有效的Unix文件名，必須使用「bytes」而不是字元串，這可真夠煩人的。所有Python程序正確的幾率又能達到多少呢？我敢打賭，不會高的。

我最近正在處理mtree生成的數據，它使用八進位轉義來處理文件名中的特殊字元。我認為這對於Python會很容易。結果…

• 許多錯誤的解答 ——對於某些值，你會得到一個編碼錯誤。甚至那個頁面上的正則表達式解決方案也不起作用。

• 甚至存在更多錯誤的解答

第二個鏈接提到了一個未記錄的函數——

而且，無論做什麼，不要輕易寫

因此，如果希望在Python中正確處理Unix文件名，你必須：

• 有一個完全避免Python字元串的處理路徑。

• 使用

• 必須將文件名以位元組形式提供給各種函數。詳情請參閱 PEP 0471：「與os模塊中的其他函數一樣，

更新：你想在命令行上接收文件名嗎？我會把這個爛攤子交給你的。環境呢？ 甚至都不清楚呢!

小編說兩句：這事兒真不怪Python，題主這種「處理了20年前當UTF-8還未成為文件名標準時的數據」的任務，平時誰會碰到，這種任務當然需要題主對編碼系統足夠了解才能完成了......題主發發牢騷，別怨Python......

英文原文：http://changelog.complete.org/archives/9938-the-python-unicode-mess
譯者：盈韜

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！