歡迎光臨
每天分享高質量文章

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

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


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

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


但眾多問題也隨之而來。


例如,將帶有智慧引號的“播客”標題轉為以ASCII編碼會引致python錯誤,導致gPodder一款開源的播客接收器,採用PythonPyGTK開發,可幫助管理播客RSS供稿,並自動下載所需要的播客資料經常通過回溯退出。接著pexpect文件會告訴你用logfile = sys.stdout 來顯示與虛擬終端的交互。就是這個在這些天引發了一個錯誤


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


我最近正在處理mtree生成的資料,它使用八進制轉義來處理檔案名中的特殊字符。我認為這對於Python會很容易。結果

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

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


第二個鏈接提到了一個未記錄的函式—— codecs.escape_decode ,可正確解決這一問題。我最終不得不這樣做:

而且,無論做什麼,不要輕易寫 if filetype=="file" ——這總被求值為False,因為 "file" 在邏輯運算時不同於 b"file" 。呃好吧,我承認,自己一開始沒註意到,踩過這坑…

因此,如果希望在Python中正確處理Unix檔案名,你必須:

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

  • 使用 sys.{stdin,stdout}.buffer 而不是簡單的 sys.stdin/stdout 

  • 必須將檔案名以位元組形式提供給各種函式。詳情請參閱 PEP 0471:“與os模塊中的其他函式一樣,scandir() 接受一個bytesstr類作為路徑引數,並傳回與路徑型別相同的 DirEntry.name 和 DirEntry.path 屬性。但是,強烈建議使用str型別,因為這樣可以確保Unicode編碼的檔案名得到跨平臺支持(在Windows上,Python 3.3開始,就已經不支持bytes編碼的檔案名了)。所以,如果你想跨平臺,那就更糟了,因為不能在Unix上使用str也不能在Windows上使用bytes

 

更新:你想在命令列上接收檔案名嗎?我會把這個爛攤子交給你的。環境呢? 甚至都不清楚呢!

小編說兩句:這事兒真不怪Python,題主這種“處理了20年前當UTF-8還未成為檔案名標準時的資料”的任務,平時誰會碰到,這種任務當然需要題主對編碼系統足夠瞭解才能完成了……題主發發牢騷,別怨Python……


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

來源:Python程式員

《Linux雲計算及運維架構師高薪實戰班》2018年11月26日即將開課中,120天衝擊Linux運維年薪30萬,改變速約~~~~

    *宣告:推送內容及圖片來源於網絡,部分內容會有所改動,版權歸原作者所有,如來源信息有誤或侵犯權益,請聯繫我們刪除或授權事宜。

    – END –


    赞(0)

    分享創造快樂