作者:萧萧小雨 文章来源:blueidea 点击数:
4938 更新时间:2005-4-20 |
这几天研究UTF-8编码,太晕了,把我的看法和各位讨论讨论。 欢迎来批啊。以下都是我的想法,哪里有不对的请不吝赐教,帮忙指出来。 ========================================================== 相关的题外话: 一、操作系统 window系统内部都是unicode的。文件夹名,文件名等都是unicode的,任何语言系统下都能正常显示。 二、输入法: 微软拼音输出的是Unicode的,智能ABC输出是简体中文的(所以智能ABC在非简体中文系统根本不能用,只能打英文)。 三、网页的textarea 网页的textarea是用unicode显示的。所以往里打什么字都能显示。而一些flash做的输入框就不行了。 四、Access2000 access里面保存的数据是unicode的,在任何语言系统下都能显示。 如果数据视图查看有些字符不正常,那是因为显示所用的字体不是Unicode字体, 换用Arial Unicode MS 字体就能全部显示了。(access帮助,搜索,输入unicode,有说明) 五、Word word里的繁简转换,简体转换到繁体后,内码仍是简体中文的,其实只是简体中的繁体字。 六、ASP内部是Unicode的,所有文本都是Unicode存储的。需要时转换到指定字符集。 ======================================================= 首先说下结论: <%@ codepage=936%>简体中文 <%@ codepage=950%>繁体中文 <%@ codepage=65001%>UTF-8
codepage指定了IIS按什么编码读取传递过来的串串(表单提交,地址栏传递等)。 也指定了所有文本变量从Unicode转换到的编码, 也就指定了从数据库取出的数据从Unicode转换到的编码。(注意这个,很重要。)
关键字: 读取:一个串串,按简体读取是一些字,按繁体读取是一些字,串串本身编码没有变。 转换:系统主动的转换,比如从Unicode的“化”字到Big5的“化”字,内码变成Big5的。如果Big5没有对应的字,保留Unicode形式(&#xxxx;)
简体中文:化六个结论 Unicode16进制形式:化六个结论 Unicode10进制形式:化六个结论
下面是我推测出来的编码转换的过程: 客户端:输入法Unicode--输入框unicode--从Unicode按charset转换到对应编码()--表单发送编码
服务器端:IIS解开表单编码--按codepage指定编码读取--转换到对应的Unicode--可以用request("")读取了--进行一些处理--以Unicode编码保存到数据库
服务器端:读取数据库的Unicode数据,转换到codepage指定编码---生成源代码--IE按charset读取显示。
下面举例说明: 例一: 假设有三个asp页面,典型的留言页面: 1. write.asp 简单的输入表单,提交到add.asp。 <META http-equiv="Content-Type" content="text/html; charset=big5"> 2. add.asp 接收留言,保存到数据库 <%@ codepage=936%> 3. read.asp 从数据库取得留言,显示。 <%@ codepage=936%> charset=GB2312 或 <%@ codepage=950%> charset=big5
大家可以猜一猜,我在write.asp里用微软拼音输入法输入“化六个讨论”。最后在read.asp里会显示什么样? 是不是晕了。让我们从头分析。
例二: 把例一的add.asp的<%@ codepage=936%>改为<%@ codepage=950%>,又会怎么样呢?
到这里发现了什么? 1.如果输入的文字和Charset对应的不同,一转换,就可能出现Unicode形式的字了。这里就是原因所在。以后整个过程都保留着。 2.Add.asp里codepage决定了保存到数据库的文字,用的是哪个语言对应的Unicode.如codepage=936, 那么数据库保存的就是简体中文的Unicode(数据库拿回简体中文系统,一切正常的), codepage=950保存的就是繁体中文的Unicode.(拿回简体中文系统,就不对了)。 3.注意一下串串的变化过程: -------------------------------------------------------------------- 1) 输入法---Charset Unicode----指定字符集的映射 2) Charset----表单编码 串串简单编码 3) 表单解码 上步的逆过程,两步抵消了。 4) 串串à按codepage读取 串串没变,这步有可能“误会读取” 5) 转为对应的Unicode Codepage指定字符集----Unicode映射 6) 中间处理,进数据库 无变化,直接以Unicode形式进入 7) 8) 按codepage读取数据库 Unicode----codepage指定字符集的映射 9) 显示,按Charset指定字符集读取 串串没变。 ------------------------------------------------------------------------------- 以例一说明:
例二:
============================================= 晕了。现在来用用知识。
案例1。 简体中文系统下跑的好好的代码,放到国外空间上,数据库里乱码,原有的数据也乱码。 分析:因为大多数人平时用的都是简体中文系统,默认的codepage=936,所以平时大家不写也没有关系。 但到了国外空间问题就出来了。从数据库里的Unicode转换到英文编码去了,所以数据库原有的简体中文转换到英文后,按GB显示自然乱码。 如图,新输入的文字显示正常,但数据库里保存的是英文的Unicode的。 解决方法:全部加上<%@codepage=936即可%>。 全程只有简体中文与对应Unicode间的转换。
案例二: 简体中文的代码和数据,想转为完全的繁体版,该怎么办? 分析:1。代码文件编码全部改为Big5的,文件本身保存编码选繁体。 2.<%@ codepage=936 %> 3.Charset=big5 4.access版本无所谓,因为access里的数据是Unicode的。 5.好了,代码可以在纯繁体系统下跑了。 6.遗留问题:原有的简体中文数据读出会有一些问号。效果同例一的950读取,big5显示。因为从简体中文的Unicode转换到繁体中文了,有些字繁体中没有,就会出问号。 7.解决:用一个临时asp页,codepage=65001,读出为简体中文的Unicode,用一个Unicode->Big5的函数,转为繁体中文,然后写回数据库,应该行了吧? 案例三: 简体中文的代码和数据库,想转为完全的UTF-8版,怎么办? 分析:1。代码文件编码全部改为UTF-8的,文件本身保存编码选UTF8。 2.<%@ codepage=65001 %> 3.Charset=UTF-8 4.access版本无所谓,因为access里的数据是Unicode的。 5.OK,没有任何遗留问题。原有的简体中文也会正常显示。因为数据库里是Unicode的,按Unicode读出没有任何转换。自然不会乱码。看来转到UTF-8还是很简单的。 ============================================= 案例完全是我按照理论推导出来了,未经证实。 有类似经历的欢迎批评指正。
文件保存编码和codepage之间的关系
结论: codepage指定了IIS按什么编码读取源文件。如果codepage和源文件的实际编码相同,则读取正确,否则就会乱码。有时还会报编译错误,大概意思是无效字符吧。
题外话: 1.一个文件保存格式为GB2312,那么你在编辑的时候,不论是用输入法输入的,还是copy粘贴的,所有的字都会转为GB2312编码。 2.象Mid,Left,Chr,Instr等函数都是面向Unicode形式变量的,他们的入口和出口参数都是unicode形式的,也就是说,进入时从Unicode转为对应编码,出来时转回Unicode。
试验过程: 假设文件a.asp,保存编码格式为GB2312,输入:帳票マッ(日文输入法输入),自动变为GB2312编码的,但因为GB2312字库中有日文,所以显示正常。 上面四个字如果按日文Shift-JIS编码查看,则是: (图片,否则后面三个是空白)。
--A-- .asp中有代码: --------------------- <%@codepage=936%> aa="帳票マッ" response.write aa ------------------------- 输出结果,按charset=GB2312查看为:帳票マッ 按charset=Shift-JIS查看为: 如果codepage=932,输出按charset=GB2312查看为:帳票マッ 按charset=Shift-JIS查看为:
过程分析:IIS编译器按936简体中文读取源文件,把“帳票マッ”转为对应的Unicode编码,赋值给变量aa,也就是说LenB(aa)=8。 Response.write输出的时候,从Unicode形式转换到对应的936简体中文编码,输出为html,发送给浏览器,浏览器按charset显示。
--B-- 如果把文件的保存编码换为Shift-JIS,注意四个文字要重新输入。保存的是Shift-JIS编码。 <% @codepage=936 %>输出结果, 按charset=GB2312查看为:挔昜儅僢 按shift-jis查看为:帳票マッ <% @codepage=932 %>输出结果, 按charset=GB2312查看为:挔昜儅僢 按shift-jis查看为:帳票マッ
总结: GB—按GB读取—对应的Unicode—转回GB—按GB2312查看,正常。 GB—按GB读取—对应的Unicode—转回GB—按Shift-JIS查看,不正常。 GB—按Shift-JIS读取—对应的Unicode—转回Shift-JIS—按GB2312查看,正常。 GB—按Shift-JIS读取—对应的Unicode—转回Shift-JIS—按Shift-JIS查看,不正常。
Shift-JIS---按GB读取—对应的Unicode---转回GB—按GB2312查看,不正常。 Shift-JIS---按GB读取—对应的Unicode---转回GB—按Shift-JIS查看,正常。 Shift-JIS---按Shift-JIS读取—对应的Unicode---转回Shift-JIS—按GB2312查看,不正常。 Shift-JIS---按Shift-JIS读取—对应的Unicode---转回Shift-JIS—按Shift-JIS查看,正常。
可以看出,ASP中的处理是对称的,所以对于直接输出和简单处理的文字,codepage设置为什么都没有影响,只要文件的编码和最终显示的charset相同,那么就会正常显示。
不会出现乱码。 因为简体中文字库>繁体字库,所以繁体转换到简体时,总是能找到对应的字, 程序接收的已经是简体Unicode的了,数据库里的数据都不会乱码,后面读取显示自然没有问题。 ============================== 而如果是繁体的代码,charset=big5的话,输入简体中文,就有出现乱码的可能。 因为简体-->繁体的转换,就可能没有字对应。 ======================================== 陈桥输出的繁体字是纯繁体内码的吧? 如果是,那么数据库里应该是对应的简体字的, 输入简体字检索应该可以检索到的。 ==================== 你先都加上codepage看看吧。 |