html 等頁面防止中文出現亂碼的終極解決方案


網頁UTF-8中文亂碼問題解決方法

網頁UTF-8中文亂碼問題解決方法只有經過多方面測試的東西才有質量的保證和說服力,之前一直都是在本地做開發,經過本地測試也是通過的,但一發布到遠程服務器上就問題百出了,比較頭疼的就是中文亂碼的問題.

如果把網頁都設成charset=gb2312的話,顯示中文沒什么問題,但是用ajax返回來的卻是亂碼,上網搜了一下解決方法,說是在返回的信息流前加上一句header("Content-Type:text/html;charset=GB2312");就行了,這個辦法也確實行得通,然后我也沒深究了.

但一放到國外的免費空間一測試,頁面還是顯示中文,但ajax返回的卻是亂碼,搞了好久都不行,然后還是繼續上網搜解決方案,看到有的說把全站都設為UTF-8編碼就行了。那就試試唄,結果還是不行,連普通的頁面都顯示亂碼了,shit,我再看看人家yahoo的網頁,不也設成utf-8嗎,為何人家就能老老實實的顯示中文而我的就不行呢????

后來終於被我找到了原因,盡管我確實是給網頁加上了charset=utf-8,但我保存的時候沒有注意到這個文件是用非utf-8編碼來保存的,所以就會出現這種情況,改用utf-8編碼保存后,問題就解決了。

有許多朋友問過我,為什么在ASP里指定了codepage為65001還經常顯示亂碼.墨動在這里將這個問題詳細解釋一下,以免很多朋友再走彎路,甚至排斥UTF-8.如果你還不知道UTF-8是什么東東,那才子建議你先去搜索一下UTF-8的相關資料吧.UTF-8編碼之所以被越來越多的人接受甚至喜歡,肯定是有道理的,在WEB2.0盛行的今天,在大談多瀏覽器兼容的同時,不得不想到字符編碼不同所造成的亂碼現象同樣需要得到很好的處理.....在N年以前,IE6以下的所有版本,只要沒有安裝相應的字庫,訪問相關的頁面都是會亂碼的,例如,我是IE5 (Windows2000默認) 的版本,在沒有安裝IE繁體字庫的情況下,訪問任何繁體頁面的網站都是會亂碼的,當然前提是該頁面采用了BIG5的Charset,而UTF-8作為一種國際編碼就能很好的處理該問題,只要將頁面存為UTF-8編碼格式,再在頁面上將codepage及charset全部定義為utf-8就可以在任何客戶端瀏覽器中顯示出完全正確的內容,完全不會亂碼......

好了,墨動這里以ASP頁面為例,以一個實例來看具體操作吧:

在這墨動推薦用Editplus來寫代碼,墨動也專門寫過一篇Editplus的使用教程,有興趣的朋友可以 點擊這里 去看看.

打開新建一個ASP頁面,相信玩ASP的朋友都會留意到,許多下載的源碼里,頁面最上方一般都有一句:

〈%@LANGUAGE="VBSCRIPT" CODEPAGE="936"%>前面的language應該不用多說了,vbscript就是ASP默認的腳本語言,其實完全可以不用寫,寫了好像還會影響頁面執行效率,在這里我們先不討論這個問題.

后面的codepage就是關鍵了,目的就是告訴瀏覽器,此頁面是何種編碼,936代表是簡體中文,

而950代表繁體中文,65001就是我們今天說的UTF-8編碼了.我們將936改成65001,整句如下:〈%@LANGUAGE="VBSCRIPT" CODEPAGE="65001"%>再加上輸出幾個中文字看看能不能正確顯示吧.〈%Response.Write "第一次測試UTF-8頁面"%>OK,直接點擊"保存",執行這個頁面看看,如果不出意外,大家可能看到顯示出的是 "一尾UTF-8頁" 這幾個字,中文有亂碼的現象,什么原因呢?OK,請大家再點擊最上面的 "文件" 菜單,選擇"另存為",最下面一行有個編碼,默認應該是ANSI的,請大家點下拉框,選擇UTF-8,再點保存,再執行試試看,如果不出意外,亂得更厲害了,呵呵,暈了吧.別急,想想原因,因為我們做的頁面是HTML返回的,

以前我們寫HTML時,看到body前面,也就是head里都有一句meta,應該是這樣的:〈meta http-equiv="Content-Type" content="text/html; charset=gb2312">也就是指定頁面以gb2312編碼返回結果,一定要寫在有返回結果輸出的前面.

大家都知道gb2312是簡體中文吧,我們今天說的是UTF-8編碼,我們就將gb2312改成UTF-8吧,全部代碼如下:〈%@LANGUAGE="VBSCRIPT" CODEPAGE="65001"%>〈meta http-equiv="Content-Type" content="text/html; charset=utf-8">〈%Response.Write "第一次測試UTF-8頁面"%> 再執行看看,嗯,這次正常顯示了吧.......

結論:采用UTF-8編碼,除了要將文件另存為UTF-8格式之外,還需要同時指定codepage及charset.

一般在頁面中 明確寫明 utf-8 編碼外, 還是出現亂碼的, 通常是由於 文件保存時 采用的是非 "UTF-8"編碼, 特別是一些 "輕量級"的文字編輯器, 如notepad , editplus等等. 所以, 必須在 保存的時候必須保存為 utf-8 , 因為一般編輯器 默認保存的編碼都是 ANSI ....

=====================================================================
為什么國內幾個網站用GB2312反而更多些呢。

  我也對這個疑問進行了思考,我覺得。應該有3種原因:

  1. 國內這些網站本身歷史也比較長,開始使用的就是 GB2312編碼,現在改成 UTF-8(以前的網頁)轉換的難度和風險太大。

  2. UTF-8編碼的文件比GB2312更占空間一些,雖然目前的硬件環境下可以忽略,但是這些門戶網站為了減少服務器負載基本上所有的頁面都生成了靜態頁,UTF-8保存起來文件會比較大,對於門戶級別的網站每天生成的文件量還是非常巨大,帶來的存儲成本相應提高。

  3. 由於UTF-8的編碼比GB2312解碼的網絡傳輸數據量要大,對於門戶級別的網站來說。這個無形之間就要增大帶寬,用GB2312對網絡流量無疑是最好的優化。

  所以在新做站的情況下,建議還是選擇UTF-8比較好。因為沒有上面那些原因,兼容為上策

codepage是服務器端的,charset是瀏覽器端的。兩者必須匹配,才能避免亂碼問題. 一般服務器端默認的 codepage都是UTF-8!!!

打賞

免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號  © 2018-2021 CODEPRJ.COM