該樓層疑似違規已被系統折疊?隱藏此樓查看此樓

3 樓的可以用 sys.getfilesystemencoding 檢測，但由於文件系統的差異，文件名 100% 無損轉還是不太可，比如很多 *nix 的文件系統支持除 / 和 \0 外的所有字符，而 win 下不可能

4 樓的可以看 log，當然最好的情況是設 logger，設好以后是一勞永逸的，看 request 和所用的 template 之類的，可以使用 django debug toolbar

1, 5 樓是典型的 encoding 問題

文件名先撇開不說，就說字符編碼，只要理清邏輯，那麼類似的 ascii 無法 encode 的錯誤你就知道怎麼避免

先說編碼，ascii 屬於 7bit，就算加上最高位，也只能編碼 256 個字符，不說 cjk，就光光所有歐洲語系都不夠用，於是就出現各種編碼方案，特別是 cjk 的，如早期的 gb2312 和 big5

嗯，扯遠了，先拉回來

簡單的說，目前常見的 cpython2 打包，估計編譯時多設了內部使用 ucs2 編碼，部分可能用 ucs4，簡單的說就是 cpython 內部處理

嗯，這個角度還是太遠

這麼說吧，就是當你在外部輸入字符串的時候，如果有非 ascii 字符，那麼是一定帶有特定的編碼方案的，即所謂的 encoding，比如你常用的 linux 下很可能是 utf-8，那麼如果你要轉換成其他編碼方案，比如 gtk，需要先 decode，然后再 encode

比如：

在 utf-8 下的終端中的 repl

>>> s = '中文' #

>>> u = s.decode('utf-8') #

>>> s_gbk = u.encode('gbk') #

只要理清了這個，那麼上面的文件就知道怎麼處理了，因為通常是概念沒理清，不知道什麼時候該用 encode，什麼時候該用 decode 造成的。

然后是文件名的編碼問題了，一開頭說的可以找出本地文件系統默認編碼，但是，各種方案對 unicode 全字符集的支持不一，比如 gb2312 支持的就少，早期 window 用的 cp932(這個數字具體記不清楚) 也少，直接轉 utf-8 通常還會出現問題，必須過濾掉非法字符，但這樣又可能出現額外的重名，現代的 windows 文件系統名字編碼應該沒問題了，但是我太久沒用過，無法驗證。

這幾天事情很多，目前只能先草草說一下，太亂了將就一些

總結

以上是生活随笔為你收集整理的python处理文件名_[请教]python的中文文件名处理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。