简体转换繁体的郁闷话题，问题终于解决了

比例:
2

如繁体：發財頭髮
3

如果在C#程序中的head部分直接<meta http-equiv=”Content-Type” content=”text/html; charset=big5″ />
4

这样一句，到网页中，编码不是选中繁体中文，而是选择Unicode.
5

但是文字是可以正常显示的。
7

如果想网页在加载中编码为繁体中文，必须加上CodePage=”950″
9

<%@ Page Language=“C#“ CodePage=“950“%>
10

文字也是可以正常显示的。
12

想知道为什么我们来看看一篇技术文章，就知道？
13

《大家看得容易，我真是找的辛苦啊，我为了这个问题，已经搞了几天了。哎，为人打工真是苦啊》

这几天研究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。

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形式进入

8) 按codepage读取数据库 Unicode—-codepage指定字符集的映射

9) 显示，按Charset指定字符集读取串串没变。

——————————————————————————-

以例一说明：

例二：

=============================================

晕了。现在来用用知识。

案例1。

简体中文系统下跑的好好的代码，放到国外空间上，数据库里乱码，原有的数据也乱码。

分析：因为大多数人平时用的都是简体中文系统，默认的codepage=936，所以平时大家不写也没有关系。

但到了国外空间问题就出来了。从数据库里的Unicode转换到英文编码去了，所以数据库原有的简体中文转换到英文后，按GB显示自然乱码。

如图，新输入的文字显示正常，但数据库里保存的是英文的Unicode的。

解决方法：全部加上<%

@codepage=936即可%>。

全程只有简体中文与对应Unicode间的转换。

案例二：

简体中文的代码和数据，想转为完全的繁体版，该怎么办？

分析：1。代码文件编码全部改为Big5的，文件本身保存编码选繁体。

2．<%

@ codepage=950 %>

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″

和

页面显示的，这两个似乎是不一样的

一个respons.redirect(“aaa.asp”)的页面

如果aaa.asp有 response.charset=”gb2312″

ie就可以正确识别 gb2312 页面汉字也不会乱码

但没有 respons.redirect(“aaa.asp”) 即使 aaa.asp页面有

也会将头替换成西文字符，另存为页面上的 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

也是必须的

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

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

保存为文件名：utf1.html，编码采用ANSI。

<html>

<head>

</head>

<body>

调试utf-8代码

</body>

</html>

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

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

保存为文件名：utf2.html，但编码采用UTF-8。

<html>

<head>

</head>

<body>

调试utf-8代码

</body>

</html>

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

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

保存为文件名：utf3.html，但编码采用ANSI。

<html>

<head>

</head>

<body>

调试utf-8代码

</body>

</html>

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

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

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

<html>

<head>

</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.归档精华时不小心转移了下

文件保存编码和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相同，那么就会正常显示。

本文链接：https://www.cnblogs.com/ruilei/articles/492897.html

简体转换繁体的郁闷话题，问题终于解决了

简体转换繁体的郁闷话题，问题终于解决了的更多相关文章

随机推荐

热门专题

目录导航