该楼层疑似违规已被系统折叠 隐藏此楼查看此楼
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 文件系统名字编码应该没问题了，但是我太久没用过，无法验证。
这几天事情很多，目前只能先草草说一下，太乱了将就一些
)
