ajax頁面亂碼與get post亂碼的解決

來源:互聯網
上載者:User

ajax頁面亂碼與get post亂碼的解決
之前做ASP頁面各種亂碼,頁面重新整理就亂碼或者連結就亂碼,昨晚去問了下度娘,總結出一個解決辦,在所有ASP頁面之前加上 <% @ CODEPAGE = "65001" LANGUAGE = "VBSCRIPT" %> <% Response.CODEPAGE = 65001%> ,65001指的是UTF-8編碼格式 GB2312是936,原因就是你在進入UTF-8頁面的時候 其他程式沒有聲明Response.CodePage 而是 Session.CodePage立即被賦值了 (65001或936因版本不同賦值不一樣),接著進入另一頁的時候 另一頁的Response.CodePage立即被Session.CodePage賦值 於是如果那個頁得@ CODEPAGE = 936 的話 你這個頁的 Response.CodePage 被賦值成了 65001肯定會出亂碼的 所以 在頁面的開頭先統一寫好編碼 。

  然後昨晚後來又碰到一個問題是AJAX返回中文的時候顯示亂碼而 2個頁面的編碼都是一樣的UTF-8 為毛會出現亂碼 查了度娘是說在AJAX處理頁面加上 <% Response.Charset = "UTF-8"%> 結果頁面顯示不出內容 自己研究了下估計是資料庫教程的資料編碼問題,因為ACCESS資料編碼是根據你寫進去資料時的編碼我寫進去的時候是GB2312現在用UTF-8格式的編碼解碼肯定會亂碼 怎麼辦呢 把<% Response.Charset = "GB2312" %> 然後AJAX中文就返回正常了 . 這裡講下 Charset屬性在W3C的解釋是 向頁面的Response對象中content-type 頭部追加字元集名稱。

  添加 <% Response.Charset = "GB2312"%>

  頁面輸出顯示

  <%content-type:text/html; charset=GB2312%>

我估計是Charset將字元集改成了GB2312所以可以接受GB2312編碼的資料所以就不會亂碼了


看一下get,post亂碼的ajax解決辦法

資料出現亂碼從程式執行的過程來講分為兩種,一種是發送給背景程式的中文本身就是亂碼,因為xmlHTTP沿用的是網頁特效的文書處理機制,使用UTF-8編碼。但是後台頁面使用GB2312或者其它類型編碼的話,接收到的資料自然就是亂碼了。還有一種是接受到資料再返回的時候,出現字元亂碼。這也是因為後台頁面使用的編碼和Javascript編碼不同造成的。伺服器指令碼返回的字元預設會使用伺服器編碼例如GB2312。伺服器發回資料亂碼問題是很容易解決的,我們只要在伺服器發回資料的頁面加上一個定義編碼的檔案頭即可。
  定義檔案頭資訊的時候根據指令碼的不同,可以使用以下方式:
  PHP:header("Content-Type:text/html;charset=GB2312"); 
  ASP:Response.Charset("GB2312")
  JSP:response.setHeader("Charset","GB2312");
  (其它指令碼可以尋找其相關類庫,通常都有設定header資訊的函數或方法。)
  說完了發回資訊,我們在說一下發送資訊亂碼的問題。其實不關是怎樣的編碼,我們輸入的中文字元都會被正確的以UTF-8格式發送到伺服器端,只是在伺服器接收的時候沒有按照我們預期的方式去解碼,而是使用了伺服器預設的字元編碼方式,通常是GB2312來解碼資訊。那我們看到的字元自然就是錯誤的。
  我們都知道,XMLHTTP有兩種發送資料的方式,一種是GET,一種是POST。GET的亂碼解決起來比較簡單。只要加上一個定義編碼的Header資訊即可:setrequestheader("Content-Type","text/html; encoding=gb2312")。這樣GET方式發送出去的資料會被伺服器指令碼正確的理解為GB2312方式,從而進行解碼。
  比較難的部分是使用POST方法發送資料的時候,上面的方法就失效了,因為POST資料使用的Content-type使用的是:xmlObj.setrequestheader("Content-Type","application/x-www-form-urlencoded");沒有定義字元編碼的地方。我在這個問題的解決上遇到了很大的困難,但是目前已經找到兩種比較好的解決方案。首先是將中文字元在發送到伺服器端之前進行URL編碼。也就是使用:encodeURI()。
  但要注意的是,這個方法要用兩次,第一次是將字元加工成URL編碼。第二次是將編碼後的資料再次編碼。這樣做是因為,第一次編碼如果發送的話,伺服器端會自動對其進行解碼,如果這樣那我們就沒有辦法來控制我們希望的解碼方式了。所以要進行兩次encodeURL。這樣做的目的在於,我們在伺服器端獲得的資料是一個被encodeURL後的字串。然後我們再用伺服器端指令碼的相應解碼函數來還原字串,如此一來,我們就得到了一個我們希望得到的正確的字串了。這樣做的壞處是,我們不得不成倍的增加Send出去的資料量。要知道,資料量變大,出錯的機會也就隨之變大。
  還有一種方式是使用cookies轉儲資料,這樣雖然不會增加資料但是對於瀏覽器許可權有一定要求。雖然讀寫cookie是很容易得事情。但我覺得這樣操作並不理想。在我沒有進行實驗的情況下我也不好多說什麼。而我認為,應該還有第三種方法可以解決亂碼的問題。

  AJAX POST 亂碼在 PHP 中的解決方案!
  雖然不進階,也不帥,但最終還是解決了問題。而問題的解決,正式因為PHP完善的函數庫!只是一個 iconv() 函數就解決了亂碼的問題!
  在用戶端,不需要任何的設定。只要將正常的值擷取並使用xmlHTTP Send到伺服器端,然後在伺服器端正常接受值。在接收到值之後使用iconv()函數將字串重新編碼一下就好了!
$R_Guest = strval(iconv("UTF-8","GB2312",$_POST["R_Guest"]));
$R_Content = strval(iconv("UTF-8","GB2312",$_POST["R_Content"]));

 

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.