這是自己很久以前寫的,發在這裡儲存下。
大家一般都知道設定 Response.Charset="utf-8"來確保瀏覽器可以正確解釋頁面內容,使用<%@ CODEPAGE=65001 %>來保證頁面源碼自身編碼的正確性,但是很多人會忘記session.codepage屬性.
session.codepage是用來確保動態內容的輸出編碼的.例如可以控制response.write輸出的字串編碼.如果不設定session.codepageasp引擎一般設定為asp源碼的編碼格式而不是response.Charset中指定的編碼.
例子: asp代碼用utf-8格式儲存,頁面中設定了正確的codepage 和 response.Charset, 此時使用response.write輸出一串中文,瀏覽器可以正確按照utf-8編碼顯示.在response.write語句之前設定session.codepage=936,再次重新整理頁面則瀏覽器顯示亂碼,強制瀏覽器按照gb2312編碼顯示則正確.
上面說了這麼多,下面談談session.codepage的一個用途.
現在的檔案下載一般不直接提供真是的url地址,而是使用組件write,例如adostream之類的.此時要設定content-type為 application/octet-stream之類,同時設定Header:Content-Disposition為 attachment;filename=youfilename.txt;來確保瀏覽器彈出下載對話方塊而不是直接顯示.
這裡有一個問題:IE6有一個bug,就是不能正確處理attachment;filename中的filename編碼,IE使用作業系統預設編碼來處 理.中文windows的預設編碼為gbk,所以如果asp頁面輸出使用gb2312格式則不會出錯,如果使用utf-8格式輸出的話則會100%的亂 碼.
此時session.codepage派上用場了.
參考如下代碼:
fn = "中文檔案名稱.doc"
session.CodePage = 936 '設定為gb2312編碼輸出
Response.AddHeader "Content-Disposition", "attachment;filename=" & fn
Response.AddHeader "Content-Type", "application/octet-stream"
session.CodePage = 65001 '恢複為utf-8編碼輸出
這樣在返回的header中filename被強制編碼為gb2312編碼, IE就可以正確的處理了.
btw:據說IE6的某個版本還有個bug就是不能處理長度超過150個位元組的filename,我沒有遇到過,可能我補丁打的比較勤吧.
Firefox在處理attachment;filename=的時候預設用utf-8來解碼,但是像上面那樣用gb2312他也能正確識別出來..真是神奇
不知道IE7在這個方面是不是有所改觀呢.