這幾天研究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)輸入法---CharsetUnicode----指定字元集的映射
2)Charset----表單編碼串串簡單編碼
3)表單解碼上步的逆過程，兩步抵消了。
4)串串à按codepage讀取串串沒變，這步驟有可能「誤會讀取」
5)轉為對應的Unicode Codepage指定字元集----Unicode映射
6)中間處理，進資料庫無變化，直接以Unicode形式進入
7)按codepage讀取資料庫Unicode----codepage指定字元集的映射
8)顯示，按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的函數，轉為繁體中文，然後寫回數據庫，應該行了吧？
兩個案例完全是我按照理論推導出來了，未經證實。
有類似經驗的歡迎批評指正。