拓荒者的跋涉

工作生活

编码格式

这几天研究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进制形式:&#x5316;&#x516d;&#x4e2a;&#x7ED3;&#x8bba;
Unicode10进制形式:&#21270;&#20845;&#20010;&#32467;&#35770;

下面是我推测出来的编码转换的过程:
客户端:输入法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还是很简单的。
=============================================
案例完全是我按照理论推导出来了,未经证实。
有类似经历的欢迎批评指正。

以下为一些朋友的跟贴及回复,一同贴上了来,方便理解:

跟贴内容一:

好文! 我对编码也是糊糊涂涂的
支持小雨
UTF-8是趋势,我也准备改用UTF-8来做页子
PS:
我想起
response.charset="gb2312"

<META http-equiv="Content-Type" content="text/html; charset=gb2312">
页面显示的,这两个似乎是不一样的

一个respons.redirect("aaa.asp")的页面
如果aaa.asp有 response.charset="gb2312"
ie就可以正确识别 gb2312 页面汉字也不会乱码
但没有 respons.redirect("aaa.asp") 即使 aaa.asp页面有
<META http-equiv="Content-Type" content="text/html; charset=gb2312">
也会将头替换成西文字符,另存为页面上的 gb2312就没有了

response.charset :
Charset Appends the name of the character set to the content-type header.

但实际对页面的控制与 <meta 直接设置的有区别

什么原因也不知道 以前做的asp页 使用redirect 跳转 的asp页必须加 response.charset="gb2312"
否则是不会认<meta 的 gb2312的

而 meta refresh 和 js的 location.href 设置的则正常
redirect()就会丢弃<meta 的charset
..
所以 保证ie 自动准确显示页面
response.charset= charset
也是必须的

跟贴内容2:

不错,我也把我之前遇到的一起发上来/

1,普通HTML页面,并声明此HTML文件是采用gb2312字符集

保存为文件名:utf1.html,编码采用ANSI


<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=gb2312">
<meta name="author" content="CN-Bruce www.cnbruce.com">;
<title>utf-8</title>
</head>
<body>
调试utf-8代码
</body>
</html>


IE中浏览,字符显示正常。若选择浏览器菜单“查看”——“编码”——“除简体中文以外”,页面出现乱码。

2,依然是普通HTML页面,并声明此HTML文件是采用gb2312字符集

保存为文件名:utf2.html,但编码采用UTF-8


<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=gb2312">
<meta name="author" content="CN-Bruce www.cnbruce.com">;
<title>utf-8</title>
</head>
<body>
调试utf-8代码
</body>
</html>


IE中浏览,字符显示正常。再选择浏览器菜单“查看”——“编码”——“始终显示Unicode(UTF-8)”,页面不出现任何乱码。

3,同样是普通HTML页面,但声明此HTML文件是采用UTF-8字符集

保存为文件名:utf3.html,但编码采用ANSI


<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<meta name="author" content="CN-Bruce www.cnbruce.com">;
<title>utf-8</title>
</head>
<body>
调试utf-8代码
</body>
</html>


IE中浏览,字符显示直接是乱码。再选择浏览器菜单“查看”——“编码”——“简体中文”,页面方才正常。

4,继续是普通HTML页面,声明此HTML文件是采用UTF-8字符集

保存为文件名:utf4.html,并且编码还是采用UTF-8


<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<meta name="author" content="CN-Bruce www.cnbruce.com">;
<title>utf-8</title>
</head>
<body>
调试utf-8代码
</body>
</html>


IE中浏览,字符显示正常。再选择浏览器菜单“查看”——“编码”——“始终显示Unicode(UTF-8)”,页面不出现任何乱码。

那么现在,个人总结得出:从utf2.html和utf4.html比较得,页面显示的和文件所采用的字符集并无直接关系,其只是一个声明作用。真正的主体还是该文件保存时的编码格式:ANSI or UTF-8

以下是一篇文章参考: www.linuxforum.net/books/UTF-8-Unicode.html

p.s.归档精华时不小心转移了下

跟贴内容3:

文件保存编码和codepage之间的关系

结论:

codepage指定了IIS按什么编码读取源文件。如果codepage和源文件的实际编码相同,则读取正确,否则就会乱码。有时还会报编译错误,大概意思是无效字符吧。

题外话:
1.一个文件保存格式为GB2312,那么你在编辑的时候,不论是用输入法输入的,还是copy粘贴的,所有的字都会转为GB2312编码。
2.象Mid,Left,Chr,Instr等函数都是面向Unicode形式变量的,他们的入口和出口参数都是unicode形式的,也就是说,进入时从Unicode转为对应编码,出来时转回Unicode。

试验过程:
假设文件a.asp,保存编码格式为GB2312,输入:帳票マッ(日文输入法输入),自动变为GB2312编码的,但因为GB2312字库中有日文,所以显示正常。
上面四个字如果按日文Shift-JIS编码查看,则是: click for full size(图片,否则后面三个是空白)。

--A--
.asp中有代码:
---------------------
<%@codepage=936%>
aa="帳票マッ"
response.write aa
-------------------------
输出结果,按charset=GB2312查看为:帳票マッ
按charset=Shift-JIS查看为: click for full size
如果codepage=932,输出按charset=GB2312查看为:帳票マッ
按charset=Shift-JIS查看为: click for full size

过程分析: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相同,那么就会正常显示。

阅读更多
个人分类: DotNet
想对作者说点什么? 我来说一句

PPM信号编码格式

2018年04月17日 518KB 下载

红外遥控SC50462格式

2010年05月11日 310KB 下载

与短消息相关的pdu的编码格式

2009年04月12日 4KB 下载

servlet过滤器解决乱码问题

2011年03月31日 1KB 下载

编码检测软件

2015年01月21日 1.98MB 下载

视频格式讲义 Ntsc Pal

2010年11月28日 1.64MB 下载

编码格式文档

2013年01月10日 22KB 下载

红外遥控编码格式

2016年04月10日 492KB 下载

没有更多推荐了,返回首页

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭