实际运用中,处理Unicode可如下操作:
1. 程序中出现字符串时一定要加个前缀u.
2. 不要使用str()函数, 用unicode() 代替
3. 不要用过时的string模块 ---- 如果传给它的是ASCII字符, 它会搞砸一切。
4. 不到必要时不要在你的程序中编码Unicode字符,只在你要写入文件或数据库或者网络时,才调用Unicode()函数;相应地,只在你需要把数据读回来时才调用decode()函数。
从现实中得到的教训
失误#1: 如果你需要在一个有限的时间内写出一个大型的应用, 而且需要其他语言的支持,但是你没有考虑到这一点,直到项目快要结束...... 这时候再添加Unicode的支持几乎不太可能,不是吗 ?
结果#1: 没能预测到最终用户对其他语言界面的需求, 在集成他们用的面向其他语种的应用时又没有使用Unicode支持,更新整个系统既让人觉得枯燥,又浪费时间。
失误#2: 在源码中到处使用string模块或者str()和chr()函数。
结果#2: 通过全局的查找替换把str()和chr()替换成unicode()和unichr(),但是这样一来很可能就不能再用pickle模块,要用的话,只能把所有要pickle处理的数据存成二进制形式,这样一来就必须修改数据库的结构,而修改数据库结构就意味着全部推倒重来。
失误#3: 不能确定所有的辅助系统都完全地支持Unicode。
结果#3: 不得不去为那些系统打补丁,而其中有些系统可能你根本就没有就没有源码。修复对Unicode支持的bug可能会降低代码的可靠性,而且非常可能引入新的Bug.
总结: 使 应用程序完全支持Unicode, 兼容其他的语言本身就是一个工程。它需要详细的考虑,计划,所有涉及的软件,系统都需要检查,包括Python的标准库和其他将要用到的第三方扩展模块。你甚至有可能需要组建一个经验丰富的团队来专门负责国际化(I18N)问题。
常见Unicode编码表 | |
编码 | 描述 |
Utf-8 | 变量长度为8的编码(默认编码) |
Utf-16 | 变量长度为16的编码(大/小端) |
utf-16-le | 小端UTF-16编码 |
utf-16-be | 大端UTF-16编码 |
ascii7 | 7位ASCII码表 |
Iso-8859-1 | ISO 8859-1 (Latin-1) 码表 |
Unicode-escape | (定义见PythonUnicode构造器) |
Raw-Unicode-escape | (定义见PythonUnicode构造器) |
Native | Python用的内部格式 |
unichar()/ord()/unicode()/encode()/decode()/codecs