使用技巧
事实上, 只要遵守以下规则, 可以规避 90% 由于 Unicode 字符串处理引起的 bug, 剩下的 10% 通过 python 的库和模块能够解决.
程序中出现字符串时一定要加个前缀 u.
不要用 str() 函数, 用 unicode() 代替.
不要用过时的 string 模块 -- 如果传给它的是非 ASCII 字符, 它会把一切搞砸.
不到必须时不要在你的程序里面解码 unicode 字符. 只在你要写入文件或数据库或者网络时, 才调用 encode() 函数; 相应地, 只在你需要把数据读回来的时候才调用 decode() 函数.
从现实中得来的教训
失误 #1: 你必须在一个极有限的时间内写出一个大型的应用, 而且需要其他语言的支持, 但是产品经理并没有明确定义这一点. 你并没有考虑 Unicode 的兼容, 知道项目快要结束...... 这时候再添加 Unicode 的支持几乎不太可能, 不是吗?
结果 #1: 没能预测到最终用户对其他语言界面的需求, 在集成他们用的面向其他语种的应用时又没有使用 Unicode 支持. 更新整个系统即让人觉得枯燥, 又浪费时间.
失误 #2: 在源码中到处使用 string 模块或者 str() 和 chr() 函数.
结果 #2: 通过全局的查找替换把 str() 和 chr() 替换成 unicode() 和 unichr(), 但是这样一来很可能就不能再用 pickle 模块, 要用的话只能把所有要 pickle 处理的数据存成二进制形式, 这样一来就必须修改数据库的结构, 而修改数据库结构意味着全部推到重来.
失误 #3: 不能确定所有辅助系统都完全地支持 Unicode.
结果 #3: 不得不去为那些系统打补丁, 而其中有些系统可能你根本就没有源码. 修复对 Unicode 支持的 bug 可能会降低代码的可靠性, 而且非常有可能引入新的 bug.
总结: 使应用程序完全支持 Unicode, 兼容其它的语言本身就是一个工程. 它需要详细的考虑, 计划. 所有涉及的软件, 系统都需要检查, 包括 python 的标准库和其他将要用到的第三方扩展模块. 你甚至有可能需要组建一个经验丰富的团队来专门负责国际化 (I18N) 问题.
来源: http://www.bubuko.com/infodetail-2480141.html