1比例:
2如繁體：發財頭髮
3如果在C#程序中的head部分直接<metahttp-equiv="Content-Type"content="text/html;charset=big5"/>
4這樣一句，到網頁中，編碼不是選中繁體中文，而是選擇Unicode.
5
6但是文字是可以正常顯示的。
7
8如果想網頁在加載中編碼為繁體中文，必須加上CodePage="950"
9<%@PageLanguage="C#"CodePage="950"%>
10
11文字也是可以正常顯示的。
12想知道為什么我們來看看一篇技術文章，就知道？
13《大家看得容易，我真是找的辛苦啊，我為了這個問題，已經搞了幾天了。哎，為人打工真是苦啊》
這幾天研究UTF-8編碼，太暈了，把我的看法和各位討論討論。
歡迎來批啊。以下都是我的想法，哪里有不對的請不吝賜教，幫忙指出來。
==========================================================
相關的題外話：
一、操作系統
window系統內部都是unicode的。文件夾名，文件名等都是unicode的，任何語言系統下都能正常顯示。
二、輸入法：
微軟拼音輸出的是Unicode的，智能ABC輸出是簡體中文的（所以智能ABC在非簡體中文系統根本不能用，只能打英文）。
三、網頁的textarea
網頁的textarea是用unicode顯示的。所以往里打什么字都能顯示。而一些flash做的輸入框就不行了。
四、Access2000
access里面保存的數據是unicode的，在任何語言系統下都能顯示。
如果數據視圖查看有些字符不正常，那是因為顯示所用的字體不是Unicode字體，
換用ArialUnicodeMS字體就能全部顯示了。（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。
<METAhttp-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)輸入法---CharsetUnicode----指定字符集的映射
2)Charset----表單編碼串串簡單編碼
3)表單解碼上步的逆過程，兩步抵消了。
4)串串à按codepage讀取串串沒變，這步有可能“誤會讀取”
5)轉為對應的UnicodeCodepage指定字符集----Unicode映射
6)中間處理，進數據庫無變化，直接以Unicode形式進入
7)
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"
和
<METAhttp-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頁面有
<METAhttp-equiv="Content-Type"content="text/html;charset=gb2312">
也會將頭替換成西文字符，另存為頁面上的gb2312就沒有了

response.charset:
CharsetAppendsthenameofthecharactersettothecontent-typeheader.

但實際對頁面的控制與<meta直接設置的有區別

什么原因也不知道以前做的asp頁使用redirect跳轉的asp頁必須加response.charset="gb2312"
否則是不會認<meta的gb2312的

而metarefresh和js的location.href設置的則正常
redirect()就會丟棄<meta的charset
..
所以保證ie自動準確顯示頁面
response.charset=charset
也是必須的



不錯，我也把我之前遇到的一起發上來/

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

保存為文件名：utf1.html，編碼采用ANSI。


<html>
<head>
<metahttp-equiv="content-type"content="text/html;charset=gb2312">
<metaname="author"content="CN-Brucewww.cnbruce.com">;
<title>utf-8</title>
</head>
<body>
調試utf-8代碼
</body>
</html>


IE中瀏覽，字符顯示正常。若選擇瀏覽器菜單“查看”——“編碼”——“除簡體中文以外”，頁面出現亂碼。

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

保存為文件名：utf2.html，但編碼采用UTF-8。


<html>
<head>
<metahttp-equiv="content-type"content="text/html;charset=gb2312">
<metaname="author"content="CN-Brucewww.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>
<metahttp-equiv="content-type"content="text/html;charset=UTF-8">
<metaname="author"content="CN-Brucewww.cnbruce.com">;
<title>utf-8</title>
</head>
<body>
調試utf-8代碼
</body>
</html>


IE中瀏覽，字符顯示直接是亂碼。再選擇瀏覽器菜單“查看”——“編碼”——“簡體中文”，頁面方才正常。

4，繼續是普通HTML頁面，聲明此HTML文件是采用UTF-8字符集。

保存為文件名：utf4.html，并且編碼還是采用UTF-8。


<html>
<head>
<metahttp-equiv="content-type"content="text/html;charset=UTF-8">
<metaname="author"content="CN-Brucewww.cnbruce.com">;
<title>utf-8</title>
</head>
<body>
調試utf-8代碼
</body>
</html>


IE中瀏覽，字符顯示正常。再選擇瀏覽器菜單“查看”——“編碼”——“始終顯示Unicode(UTF-8)”，頁面不出現任何亂碼。

那么現在，個人總結得出：從utf2.html和utf4.html比較得，頁面顯示的和文件所采用的字符集并無直接關系，其只是一個聲明作用。真正的主體還是該文件保存時的編碼格式：ANSIOrUTF-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.writeaa
-------------------------
輸出結果，按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相同，那么就會正常顯示。

總結

以上是生活随笔為你收集整理的简体转换繁体的郁闷话题，问题终于解决了的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。