ASP乱码确实棘手，这个说明比较权威。有待研究。哪的资料都不如官方资料权威。今天总算从MSDN中择出了ASP编码问题的解决方案。 ... ASP乱码确实棘手，这个说明比较权威。有待研究。 哪的资料都不如官方资料权威。今天总算从MSDN中择出了ASP编码问题的解决方案。

下面是MSDN中的一段话。 Setting[b]@CODEPAGE[/b] explicitly affects literal strings in a single response. [b]Response.CodePage[/b] affects dynamic strings in a single response, and [b]Session.CodePage[/b] affects dynamic strings in all responses in a session.

这句话解释清楚了[b]@CODEPAGE[/b]，[b]Response.CodePage，Session.CodePage[/b] 分别的作用是什么。 [b]@CODEPAGE[/b]作用于所有静态的字符串，比如某文件中的 const blogname="我的家" [b]Response.CodePage[/b],[b]Session.CodePage[/b]作用于所有动态输出的字符串，比如<%=blogname%> 这句话很关键的是说明了[b]Response.CodePage的作用范围是[/b]a single response，而SXNA中声明的[b]Session.CodePage[/b]的作用范围是all responses in a session。

再看另外一句话。 If[b]Response.CodePage[/b] is not explicitly set in a page, it is implicitly set by Session.CodePage,[b]if sessions are enabled[/b].[b]If sessions are not enabled[/b],[b]Response.CodePage[/b] is set by[b] @CodePage[/b], if @CodePage is present in the page. If there is no [b]@CodePage[/b] in the page, Response.CodePage is set by the [b]AspCodePage[/b] metabase property. If the [b]AspCodePage[/b] 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），[b]而后进入其他程序的时候Response.CodePage马上被Session.CodePage赋值[/b]，[b]如果这时Response.CodePage与页面本身编码不一样的话[/b]，页面就会出现乱码。所以进入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应该如何理解呢？ 也许上面的话应该这样理解：

[b]在Session.CodePage被任何程序声明的时候，如果Response.CodePage没有声明，则Response.CodePage会被Session.CodePage赋值。如果Session.CodePage没有被任何程序声明的时候, 如果@CodePage已声明，则Response.CodePage会被@CodePage赋值，....，最后的页面动态内容部分按照Response.CodePage的值解释。[/b]

因为Zblog和Oblog都声明了@CodePage，所以，用户刚刚启动完机器然后进入浏览器浏览Zblog和Oblog的时候Response.CodePage会被@CodePage赋值，于是叶面显示正常。

这句话进一步解释了产生乱码的原因 If you set [b]Response.CodePage[/b] or [b]Session.CodePage[/b] 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[b]@CODEPAGE[/b] matches the code page of [b]Response.CodePage[/b], or the literal strings are encoded differently from the non-literal strings and display incorrectly.

其中比较有用的一句话是说如果[b]Response.CodePage[/b]和[b]@CODEPAGE[/b]不一样的话会产生乱码。也就是说当Z-blog的[b]@CODEPAGE[/b]=65001而Z-blog的Response.CodePage被[b]Session.CodePage[/b]赋为936的时候就会出现乱码，oblog反之亦然。 不知道上面说了这么多解释清楚没有-_-||

下面解释一下为什么SXNA有时会把Session.CodePage赋为936，我有一个版本是这样写的： <% OriginalCodePage=Session.CodePage %> ....... <% Session.CodePage=OriginalCodePage %>

当用户进入浏览器的时候Session.CodePage默认为936，这个时候的默认936不是程序声明的，因此不会赋给[b]Response.CodePage[/b]，当进入SXNA的时候，[b]Session.CodePage[/b]被上面那段代码一折腾就变成了程序声明的[b]Session.CodePage=936[/b],因此再进入Zblog的时候就把936给了[b]Response.CodePage[/b]。 至此，全部原因已经分析清楚了。 因此说，保证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 [b]Response.Charset[/b] 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还是不能轻易用的！   参考文章： [url=http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iissdk/html/268f1db1-9a36-4591-956b-d7269aeadcb0.asp]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iissdk/html/268f1db1-9a36-4591-956b-d7269aeadcb0.asp[/url] [url=http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iissdk/html/582e6f47-52eb-413e-8b5d-c99145cb61d8.asp]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iissdk/html/582e6f47-52eb-413e-8b5d-c99145cb61d8.asp[/url]