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