程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> 網頁編程 >> ASP編程 >> ASP入門教程 >> asp網站開發防止中文亂碼:codepage的重要小結

asp網站開發防止中文亂碼:codepage的重要小結

編輯:ASP入門教程

這幾天研究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的函數,轉為繁體中文,然後寫回數據庫,應該行了吧?

兩個案例完全是我按照理論推導出來了,未經證實。
有類似經歷的歡迎批評指正。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved