最近公司有一個(gè)日文項(xiàng)目，由于之前使用的是自己開發(fā)的中文CMS，并沒(méi)有將語(yǔ)言包分離，在網(wǎng)站建設(shè)調(diào)試過(guò)程中出現(xiàn)了令人頭疼的亂碼問(wèn)題。

亂碼出現(xiàn)的原因 

由于各個(gè)字符編碼的儲(chǔ)存空間不一樣，所以當(dāng)使用不同的字符讀取數(shù)據(jù)時(shí)，當(dāng)字符空間過(guò)小，就不能正常顯示了。

比如說(shuō)中文字符的字符集一般是gb2312，如果用utf-8強(qiáng)制讀取改變gb2312的字符，就有可能出現(xiàn)亂碼。因?yàn)閡tf-8的字符集儲(chǔ)存空間大于gb2312，當(dāng)使用utf-8讀取時(shí)，有些字符gb2312的編碼中是不存在的，不存在的字符自然會(huì)出現(xiàn)亂碼了。對(duì)于靜態(tài)文件來(lái)說(shuō)，如果文件的儲(chǔ)存編碼和網(wǎng)頁(yè)中編碼設(shè)置(charset)不一致的話，由于以上原因就會(huì)出現(xiàn)亂碼問(wèn)題。

以上是對(duì)于亂碼問(wèn)題的簡(jiǎn)單分析，在解決現(xiàn)有問(wèn)題時(shí)有涉及到了asp對(duì)國(guó)際化的支持。

涉及到三個(gè)函數(shù)： @CODEPAGE，Response.CodePage，Session.CodePage

下面是MSDN中的一段話。

Setting @CODEPAGE explicitly affects literal strings in a single response. Response.CodePage affects dynamic strings in a single response, and Session.CodePage affects dynamic strings in all responses in a session.

這三個(gè)函數(shù)都可以設(shè)置asp的編碼，其中 @CODEPAGE 相當(dāng)于php中的header，必須在文檔的開始發(fā)出。

在中文操作系統(tǒng)的IIS中，默認(rèn)的為gb2312，參數(shù)值是：”936″，而日文需要指定文檔CODEPAGE ：

<%@ CODEPAGE=932 %> 

我們使用這個(gè)函數(shù)來(lái)設(shè)置文檔編碼具體的使用方法可以參考：http://www.cloudward.net/techLife/article.asp?id=490

現(xiàn)在應(yīng)該沒(méi)有問(wèn)題了吧？哇，問(wèn)題仍然存在?？紤]到SEO公司的asp程序全部需要生成靜態(tài)頁(yè)面。而生成的頁(yè)面全部是windows默認(rèn)的ANSI，其中包含日文字符仍然會(huì)出現(xiàn)亂碼。這樣我們需要一個(gè)asp的函數(shù)，生成utf-8或者日文編碼的文件。 我們使用以下代碼完成：

Set objStream = Server.CreateObject(”ADODB.Stream”)
With objStream
.Open
.Charset = “utf-8″ //編碼，這里你可以改成任何編碼
.Position = objStream.Size
.WriteText=pencat //pencat 為寫入的數(shù)據(jù)
.SaveToFile server.mappath(”patch/flilename.html”),2 //生成文件路徑
.Close
End With
Set objStream = Nothing

經(jīng)測(cè)試后亂碼的問(wèn)題解決。

最新評(píng)論