这是自己很久以前写的，发在这里保存下。
大家一般都知道设置 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派上用场了.
参考如下代码:
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在这个方面是不是有所改观呢.