对于ASP编码问题的深入研究与最终解决方案
ASP乱码确实棘手，这个说明比较权威。有待研究。哪的资料都不如官方资料权威。今天总算从MSDN中择出了ASP编码问题的解决方案。
... ASP乱码确实棘手，这个说明比较权威。有待研究。
哪的资料都不如官方资料权威。今天总算从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还是不能轻易用的！
参考文章：
相关推荐
-
asp.net下数据库操作优化一例
下面是最初实现的代码,其中 LargerResultProcessor 是一个基类,负责遍历泛型参数 T 所指向的数据库表,并以每页 100 项的方式分页,并对每一项调用 ProcessItem 函数,而子类只需实现 ProcessItem 函数即可: 复制代码 代码如下: public class ItemRenameCompanyId : LargerResultProcessor<Item> { protected override void ProcessItem(Item item)
-
asp.net程序优化 尽量减少数据库连接操作
项目以我自己的设计编码完成,并整合测试.初始化数据时,问题出现了.刚开始体现在客户端接受数据很慢.测试环境环境下,数据库服务器部署在国外,网站部署在公司内部,而且我一直认为我的程序在数据库数据处理这里已经做了足够的优化,包括索引和主键已经做到了合理使用.综上所述,起初的速度问题一直没有引起我的关注. 然而最后问题的关键恰恰出在数据库连接查询方面,频繁查询导致数据初始化速度很慢.刚开始我采取的方法是即用即查:需要数据的时候就从数据库查,有比较多的单表查询返回单个字段的情况.假如我有大概3000条左
-
Asp.Net性能优化技巧汇总
本文搜集汇总了Asp.net性能优化的各种技巧,对于Asp.Net开发人员有很好的参考借鉴价值.具体内容如下: 一.选择会话状态存储方式 在Webconfig文件配置: <sessionState mode="???" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
-
ASP.NET性能优化之减少请求
这种机制存在的性能损耗,就是服务器的ASP.NET仍旧要接收请求,处理请求.此篇所讲的机制是让浏览器自己去决定是否去读缓存,这样就彻底消灭了针对服务器的请求. 1:减少静态页面请求 要让静态页面支持这个需求,我们需要用到http头中的Cache-Control: max-age.值得注意的是Cache-Control是在HTTP/1.1协议下的标识,它是HTTP/1.0协议中的Expires的升级.为了让静态页支持Cache-Control,一种方案是在IIS中进行设置,如下,我在需要静态缓存的
-
ASP.NET性能优化之让浏览器缓存动态网页的方法
OutputCache是针对所有访问服务器资源的用户,本篇要介绍的浏览器缓存则是针对单个用户,让浏览器在我们的控制下彻底不持续访问服务器上的动态内容,也就是我们要让浏览器变成我们的缓存机制中的一部分,在某些特定的场景下最大化地提升ASP.NET站点的性能.如果说OutputCache是从广度上提升并发效率,则浏览器缓存是从深度上提升效率. 一:HTTP头简介 1.1浏览器第一次请求 假设我们请求一个URL地址,譬如我服务器上的一个静态页面http://192.168.0.77/luminji2/
-
Asp.Net 网站优化系列之数据库优化措施 使用主从库（全）
网站规模到了一定程度之后,该分的也分了,该优化的也做了优化,但是还是不能满足业务上对性能的要求:这时候我们可以考虑使用主从库. 主从库是两台服务器上的两个数据库,主库以最快的速度做增删改操作+最新数据的查询操作:从库负责查询较旧数据,做一些对实效性要求较小的分析,报表生成的工作.这样做将数据库的压力分担到两台服务器上从而保证整个系统响应的及时性. SQL Server提供了复制机制来帮我们实现主从库的机制.我们看下如何在sql server 2005中实践: 实践前需要新创建一个Test的数据库
-
Asp.Net 网站优化系列之数据库优化分字诀上 分库
如果你有先见之明的话,会给表名,存储过程的名字加上前缀,例如论坛表命名为BBS_xxx,博客表命名为BLOG_xxx:这样的话在分表处理时会比较容易一些.说到这儿也许你会想到外键约束怎么办,我的博客表,论坛帖子表都有用了User表的主键做外键呀.这个很容易处理,我们需要当机立断的删掉外键,这个当机立断可能会带来一些麻烦,我们来分析下可能会遇到一些什么问题: 1. 分成多个库,没了外键了以前的inner join操作要跨库吗? 假定场景:博客表有对用户表的外键引用,我们需要在首页显示博客列表,博客
-
Asp.Net 网站优化系列之数据库优化 分字诀 分表（纵向拆分，横向分区）
1. 纵向分表 纵向分表是指将一个有20列的表根据列拆分成两个表一个表10列一个表11列,这样单个表的容量就会减少很多,可以提高查询的性能,并在一定程度上减少锁行,锁表带来的性能损耗. 纵向分表的原则是什么呢,应该怎样拆分呢?答案是根据业务逻辑的需要来拆分,对于一张表如果业务上分两次访问某一张表其中一部分数据,那么就可以根据每次访问列的不同来做拆分; 另外还可以根据列更新的频率来拆分,例如某些列每天要更新3次,有些列从创建开始基本上很少更新. 举例: 假定场景,我有一张用户表,这张表包含列: I
-
Asp.net 网站性能优化二则分享
随着后端优化空间越来越小,现在越来越多的网站更注重前端性能的优化,就是浏览器,http层面的优化,这里写两点最简单最有效的 asp.net网站优化技巧. 了解常见的网站性能优化技巧 首先我们要学一些优化网站性能和体验的理论和基础知识,雅虎已经帮我们总结好了,详见参考链接中的几篇文章,有好心人已经给翻译成中文了.这里面提到的一些技巧可操作性都很强,建议每一个网站开发人员都仔细学习并进行实践,可以说不了解这里面说的优化技巧,提升网站前端性能就无从谈起. 诊断网站性能 要想优化网站的前端性能,首先要查
-
Asp编码优化技巧
8条Asp编码优化技巧: 1.声明VBScript变量 在ASP中,对vbscript提供了强劲的支持,能够无缝集成vbscript的函数.方法,这样给扩展ASP的现有功能提供了很大便利.由于ASP中已经模糊了变量类型的概念,所以,在进行ASP与vbscript交互的过程中,很多程序员也惯于不声明vbscript的变量,这样加重了服务器的解析负担,进而影响服务器的响应请求速度. 鉴于此,我们可以象在VB中强制用户进行变量声明一样在vbscript中强制用户进行变量声明.实现方法是在AS
-
asp.net小谈网站性能优化
当然,网站性能优化是多方面的,这里先谈一下这些天来的所获: 1.书写代码的习惯: 再复杂的逻辑,也是从最简单的开始.在书写代码的过程中,很多不好的规范都会影响网站的性能: 以下是整理出来的些许代码习惯: 1)字符串的比较 用 string.Empty 代替 " " 2)在遍历过程中,先定义好计数变量, 再遍历, 这样会减少每次遍历就分配一次内存空间: 复制代码 代码如下: int i; for( i=0; i<100;i++) { // codeing } 3)同样的,用 Str