ASP中UTF-8亂碼的問題

來源:互聯網
上載者:User

ASP中UTF-8亂碼的問題
1,<%@codepage="65001"%>
2,<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
3,Session.CodePage = 65001
4,檔案存成 UTF-8

以上都試了,從資料庫讀取的資訊還是會經常亂碼(有時也會正常一下);
為何判斷是資料庫讀取的問題,因為所有從資料庫讀取的資訊直接就是亂碼;
Access資料庫已經轉為繁體了;

還在找尋中。。。

========================================================

網上有誤傳,說沒法解決????

還是先說解決方案,每個對外顯示的畫面都必須加上,特別是針對UTF-8編碼:
<%@LANGUAGE="VBSCRIPT" CODEPAGE="65001"%>
<% response.charset="utf-8" %>
<%Session.CodePage=65001%>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8" />

檔案儲存為 UTF-8編碼格式;
========================================================

MSDN中ASP編碼問題的解決方案:

下面是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.
這句話解釋清楚了@CODEPAGE,Response.CodePage,Session.CodePage 分別的作用是什麼。
@CODEPAGE作用於所有靜態字串,比如某檔案中的 const blogname="我的家"
Response.CodePage,Session.CodePage作用於所有動態輸出的字串,比如<%=blogname%>
這句話很關鍵的是說明了Response.CodePage的作用範圍是a single response,而SXNA中聲明的Session.CodePage的作用範圍是all responses in a session。
再看另外一句話。
If Response.CodePage is not explicitly set in a page, it is implicitly set by Session.CodePage, if sessions are enabled. If sessions are not enabled, Response.CodePage is set by @CodePage, if @CodePage is present in the page. If there is no @CodePage in the page, Response.CodePage is set by the AspCodePage metabase property. If the AspCodePage metabase property is not set, or set to 0, Response.CodePage is set by the system ANSI code page.
這句話我乍一看,把意思理解成了這樣:在sessions are enabled的時候,如果Response.CodePage沒有聲明,則Response.CodePage會被Session.CodePage賦值。如果sessions are not enabled的時候, 如果@CodePage已聲明,則Response.CodePage會被@CodePage賦值,等等.............
這句話解釋了為什麼從SXNA中出來以後進入一些別的頁面比如oblog,z-blog等等容易出現亂碼,因為其它程式沒有聲明Response.CodePage而恰巧SXNA聲明了Session.CodePage,因此一進入SXNA,Session.CodePage立即被賦值(版本不同,有的版本賦了936有的版本賦了65001),而後進入其它程式的時候Response.CodePage馬上被Session.CodePage賦值,如果這時Response.CodePage與頁面本身編碼不一樣的話,頁面就會出現亂碼。所以進入z-blog出現亂碼的時候我查了當時的Session.CodePage和Response.CodePage都是936,而進入oblog出現亂碼的時候Session.CodePage和Response.CodePage都是65001.就是說要想保證葉面不出現亂碼,應該聲明Response.CodePage,否則他就會按照Session.CodePage來解釋網頁(而不是按照@codepage解釋網頁).
如果僅僅按照上面的解釋的話,我實際上是很糊塗的,因為我們都是用的中文操系統,當每一次進入瀏覽器的時候你可以嘗試輸出Session.CodePage,能看到他都是936!為什麼進入Z-blog的時候他不把預設的Session.CodePage的936賦給Response.CodePage呢?反而把@CodePage給了Response.CodePage?什麼情況下Session.CodePage才賦值給Response.CodePage呢?原文的sessions are enabled應該如何理解呢?
也許上面的話應該這樣理解:
在Session.CodePage被任何程式聲明的時候,如果Response.CodePage沒有聲明,則Response.CodePage會被Session.CodePage賦值。如果Session.CodePage沒有被任何程式聲明的時候, 如果@CodePage已聲明,則Response.CodePage會被@CodePage賦值,....,最後的頁面動態內容部分按照Response.CodePage的值解釋。
因為Zblog和Oblog都聲明了@CodePage,所以,使用者剛剛啟動完機器然後進入瀏覽器瀏覽Zblog和Oblog的時候Response.CodePage會被@CodePage賦值,於是葉面顯示正常。
這句話進一步解釋了產生亂碼的原因
If you set Response.CodePage or Session.CodePage explicitly, do so before sending non-literal strings to the client. If you use literal and non-literal strings in the same page, make sure the code page of @CODEPAGE matches the code page of Response.CodePage, or the literal strings are encoded differently from the non-literal strings and display incorrectly.
其中比較有用的一句話是說如果Response.CodePage和@CODEPAGE不一樣的話會產生亂碼。也就是說當Z-blog的@CODEPAGE=65001而Z-blog的Response.CodePage被Session.CodePage賦為936的時候就會出現亂碼,oblog反之亦然。
不知道上面說了這麼多解釋清楚沒有-_-||
下面解釋一下為什麼SXNA有時會把Session.CodePage賦為936,我有一個版本是這樣寫的:
<% OriginalCodePage=Session.CodePage %>
.......
<% Session.CodePage=OriginalCodePage %>
當使用者進入瀏覽器的時候Session.CodePage預設為936,這個時候的預設936不是程式聲明的,因此不會賦給Response.CodePage,當進入SXNA的時候,Session.CodePage被上面那段代碼一折騰就變成了程式聲明的Session.CodePage=936,因此再進入Zblog的時候就把936給了Response.CodePage。
至此,全部原因已經分析清楚了。
因此說,保證asp葉面一定不會出現亂碼的代碼應該是這樣的:(假定是UTF-8的葉子)
<%@ CODEPAGE=65001 %>
<% Response.CodePage=65001%>
<% Response.Charset="UTF-8" %>
進一步說明為什麼要加Response.Charset,因為MSDN說應該加...呵呵
If the code page is set in a page, then Response.Charset should also be set.
另外,檔案的編碼格式應該與@CODEPAGE一樣:
The file format of a Web page must be the same as the @CODEPAGE used in the page.
這就是為什麼zblog,pjblog等一些程式要吧檔案存成UTF8編碼格式的原因.
綜上,如果所有的程式都聲明了Response.CodePage就不會被Session.CodePage幹擾而出現亂碼了。所以Session.CodePage還是不能輕易用的!

 

另外: utf-8編碼引起js輸出中文亂碼的解決辦法

 

如果web application的編碼規則是utf-8,如網頁頭中的:
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
那麼js檔案中如果有中文輸出就會出現亂碼,解決此個問題可在引用javascript輸出的地方加上charset="gb2312" 或 charset="big5"(假設輸出的是Big5繁體字)。

例:
<script type="text/javascript" language="javascript" src="scripts/output.js" charset="gb2312"></script>

PS:另一種解決方案是把js檔案儲存為utf-8編碼。
如果web application的編碼規則是utf-8,如網頁頭中的:
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
那麼js檔案中如果有中文輸出就會出現亂碼,解決此個問題可在引用javascript輸出的地方加上charset="gb2312" 或 charset="big5"(假設輸出的是Big5繁體字)。

例:
<script type="text/javascript" language="javascript" src="scripts/output.js" charset="gb2312"></script>

PS:另一種解決方案是把js檔案儲存為utf-8編碼。

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在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.