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譯者：盈韜
閱讀更多 Python部落 的文章
