简单生活 —— Kevin Yang的博客 » AspDotNet

Asp.Net页面的编码问题

Kevin Yang — Fri, 27 Nov 2009 06:13:00 +0000

莫名其妙的问题

这些天，一个客户的网站遇到了一些莫名其妙的问题。先是首页在Firefox下看正常，但是在IE上看，同个样式表文件，却有部分样式没能加载，导致导航菜单没有背景并且走位了。后来样式的问题解决了，但是又出现了一个页面上，部分文字乱码部分正常的诡异问题。

字符编码导致的样式文件解析错误

对于第一个问题我的第一反应是CSS样式表中部分样式存在不兼容性。但是检查了导航菜单样式的写法，没有看出来有什么特别的，都是常见的属性常见的值。但是用IE自带的开发者工具看了一下出问题的元素的样式，发现和在Firebug中看到的样式居然不同。后来无意中在HTTP Watch中看了style.css文件的内容，发现注释有乱码，当即联想到以前写过的文章《文档字符集导致的脚本错误》。当一个文档（HTML文档或是CSS文档）的文件存储字符集和浏览器解码使用的字符集不一致的时候会出现类似的问题，特别是utf-8编码过的文档却以gb2312去解码的时候，出现的问题就更诡异了。

于是我在IE上改用UTF-8去解析网页，结果果然，导航菜单的样式正常了，背景图片也正常加载了（虽然其他地方出现了一些乱码情况）。这证明了我的思路是对的。但是具体是哪个地方出了问题呢，为什么Firefox、Opera和Chrome下都没问题，偏偏就IE有问题呢？

我又仔细查看了客户给出的网页和样式文件，又分析了相关的HTTP消息，发现请求.aspx文件（出问题的网页文档）的时候，服务端返回的Content-Type是text/html;charset=gb2312，那么所有浏览器自然会以服务器返回的字符集来解析文档，这个没问题，但是当网页中引用了外部资源的时候（在这里是css样式表），IE是使用当前网页的文档字符集去解析此外部资源，除非外部资源声明了编码格式（HTTP响应头中声明或是在文档最前方使用@charset声明），而Firefox、Opera和Chrome在CSS文件没有显式声明字符集的情况下，始终是以UTF-8来解码的。

问题既然和样式相关，也就是说在使用gb2312解析该样式表的时候出现了问题，那可以猜到，样式表文件实际的存储格式是utf-8的。

为了找到具体出问题的地方，我用Notepad++——貌似手头只有这软件可以自由编解码——模拟了一下使用gb2312解码此utf-8格式的样式表的场景，发现了其中一段出问题的样式，UTF-8解码后很正常，因为本身就是UTF-8编码的：

/*新导航*/
#new_nav ul{ width:672px; height:33px; margin:0px; padding:0px;  }

当使用gb2312解码之后得到如下:

/*鏂板鑸?/
#new_nav ul{ width:672px; height:33px; margin:0px; padding:0px;}

很明显的，下面的样式都被注释掉了。自然一切问题都得以解释了。

解决办法很多种，但目标都是一个，保证文档声明和实际字符集的一致。对于CSS样式表，我们可以在文件头显式设置@charset ‘XXX’来声明字符集。或者在使用link引用外部样式表的时候显式加上charset属性。

另外，如果所有文件都能保存为utf-8 with signature的话，也就是带BOM标记的UTF-8编码格式，那么所有浏览器都能自识别，而不会产生识别错误的问题。

Asp.Net中涉及到的编码问题

第二个问题虽然我知道还是编解码的环节出了问题，但还是分析了我半天才找到问题所在。

测试环境简化

为了简单，我把第二个问题中涉及到的页面简化成如下两个文件：

Default.aspx文件：

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>
DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
head>
<body>
    <p><%= Msg %>p>
    <p>
        Aspx页面中的中文
    p>
body>
html>

Default.aspx.cs后台代码文件：

using System;
public partial class _Default : System.Web.UI.Page
{
    public String Msg = "代码中的中文";
    protected void Page_Load(object sender, EventArgs e)
    {
    }
}

两个文件非常简单，从aspx文件中输出一段文字，从cs文件中输出一段文件。

Asp.Net页面涉及到的编解码环节

为了理解第二个问题，我们首先先来看一下在Asp.Net中一个页面究竟会涉及到什么编码环节。

1. 文件本身存储使用的编码（在Visual Studio中新建文件的默认编码是UTF-8 With BOM）

2. 文件被Asp.Net引擎转换处理时使用的编码

3. 文件写到HTTP响应流时使用的编码

4. 文件在HTTP头声明的编码（Content-Type=”text/html;charset=xxx”）

对于第一个环节就不需要说了，直接“Advanced Save As..”然后选择相应编码即可。对于2、3、4环节中涉及到的编码，asp.Net提供了全局配置还有页面级配置两种方式。

在web.config文件中可以管理全局编码配置。

<configuration>
    <system.web>
        <globalization responseEncoding="utf-8" fileEncoding="utf-8" />
    system.web>
configuration>

在system.web一节下添加globalization元素，它有几个可配置选项，具体参见MSDN。其中有两个属性和此次的问题相关，一个是fileEncoding（注意区分大小写），这个配置项决定了asp.net引擎在将aspx文件以及cs文件合并成html文档时使用的编码。如果aspx或者cs文件的格式和此属性配置的不一致，那么就有可能导致生成的html文档出现乱码。默认情况下，该属性的值为ANSI编码，也就是说中文系统下为GB2312。但是如果文档本身存储格式是UTF-8 with BOM，那么asp.net将始终以UTF-8编码来解析aspx和cs文件。这也是为什么默认情况下什么都不需要配置的缘故。

另外一个属性是responseEncoding，这个配置决定了上述的第3、4环节，也就是当asp.net生成好html文档之后，将其写入HTTP响应正文时使用的编码，同时会设置HTTP的Content-Type响应头中的charset域。如果前面的环节没有问题，html生成正常的话，那么这里无论设置什么编码浏览器均会正常解码，页面上都不会有乱码。但是如果前面的步骤出了问题，那自然就会有乱码产生了。

注意上面4个环节我分别用了两种颜色来标明，看了上面的解释之后你就很明白了，1和2环节编码需一致，否则中间生成的html文档就已经有乱码了。3和4环节的编码须一致，否则浏览器显示不正常。

客户网站出现的部分文字乱码问题的原因就是因为aspx文件存储的格式是不带BOM标记的UTF-8（天知道他是怎么给整成这个编码的）而CS文件没有改动过，还是UTF-8 with BOM，而全局的fileEncoding没有配置，因此在第二个环节的时候使用gb2312去解析一个utf-8的文档，自然有问题，因此aspx文件中的中文显示为乱码，而cs文件中指定的中文正常显示。

上面介绍的是asp.net中的全局编码配置，其实针对每个页面还可以进行特殊配置。例如在aspx页面中的Page指令中可以添加ResponseEncoding属性。

或者我们可以在后台C#代码中利用Response对象。

Response对象提供了两个和字符集编码相关的属性，Response.Charset和Response.ContentEncoding。这两个有什么区别呢？ContentEncoding和web.config中配置的responseEncoding是等价的，都是既影响HTTP响应流编码又影响Content-Type响应头，而Charset影响的只是响应头Content-Type而已。将其设置为null的话，Content-Type中就不会有charset域了。

——Kevin Yang

标签：AspDotNet, Content-Type, HTTP Watch, Response, 字符集, 样式表, 疑难杂症, 编解码

你可能对下面的文章感兴趣

（转）Http 请求处理流程

Kevin Yang — Mon, 20 Jul 2009 15:24:00 +0000

文章来自：张子阳

引言

我查阅过不少Asp.Net的书籍，发现大多数作者都是站在一个比较高的层次上讲解Asp.Net。他们耐心、细致地告诉你如何一步步拖放控件、设置控件属性、编写CodeBehind代码，以实现某个特定的功能。

这种做法，实际上是回答了"如何去做"的问题，却没有回答"为什么可以这样做"的问题。

尽管我很推崇悉江华先生的《圣殿祭祀的Asp.Net开发详解》一书，但当我翻看了一下其对角色(Role) 和用户(Member)的讲解时，我决定跳过去直接读后面的章节。因为我发现他也随了大流，对这部分的讲解停留在"如何去做"的层面上。我相信像悉先生这样的牛人是不可能不了解底层运作原理的，仅仅是因为那本书原本就已经很厚了吧。

当你按"如何去做"所讲解的内容去开发程序的时候，对于你的用户，你仍是一名程序员；但对于实现了MembershipProvider 和 RoleProvider 抽象类的微软开发人员来说，你已经成了他们的一个用户。

NOTE：我既不反对一些作者只讲解"如何去做"，也不反对你只学"如何去做"，这样也有它的好处，就是可以快速开发。我只是建议多掌握一点底层知识，对一些问题会有更好的理解。

希望通过这一系列文章的讲解，可以让你更好的理解Asp.Net的运作原理和做以了解。

Http请求处理流程概述

思考"为什么在地址栏输入www.tracefact.net就可以看到张子阳的个人空间？"，类似于思考"为什么苹果是往地上掉不是往天上飘？"。对于普通访问者来说，这就像每天太阳东边升起西边落下一样是理所当然的；对于很多程序员来说，认为这个与己无关，不过是系统管理员或者网管员的责任。毕竟，IIS是 Windows 的一个组件，又不是 Asp.Net 的一个组成部分。而实际上，从你轻拍回车到页面呈现在你眼前的十分之一秒内，IIS和.Net Framework已经做了大量的幕后工作。

你可能觉得了解这些幕后工作是如何运作的无关紧要，作为程序员的你只要保证开发出的程序可以高效地运行就可以了。然而，在开发过程中，你却发现常常需要使用诸如 HttpContext 这样的类。这个时候，你可曾思考过这些类的构成和类的实体是如何创建的？你可能简单地回答：HttpContext代表当前请求的一个上下文环境。可你又知道IIS 、Framework、Asp.Net 是如何协同工作处理每个Http请求、如何区分不同的请求、IIS、Framework、Asp.Net三者之间的数据如何流动么？

回答上面这些问题，首先需要了解IIS是如何处理页面请求的，这也是理解 Form验证模式和Windows 验证模式的基础。

Http请求刚刚到达服务器的时候

当服务器接收到一个 Http请求的时候，IIS 首先需要决定如何去处理这个请求（NOTE：服务器处理一个.htm页面和一个.aspx页面肯定是不一样的么）。那IIS依据什么去处理呢？―― 根据文件的后缀名。

服务器获取所请求的页面（NOTE：也可以是文件，比如 jimmy.jpg）的后缀名以后，接下来会在服务器端寻找可以处理这类后缀名的应用程序，如果IIS找不到可以处理此类文件的应用程序，并且这个文件也没有受到服务器端的保护（NOTE：一个受保护的例子就是 App_Code中的文件，一个不受保护的例子就是你的js脚本），那么IIS将直接把这个文件返还给客户端。

能够处理各种后缀名的应用程序，通常被称为 ISAPI 应用程序（NOTE：Internet Server Application Programe Interface，互联网服务器应用程序接口）。虽然这 ISAPI 听上去还挺气派，也算是"应用程序"呢，但仔细看看它的全称就明白了：它实际上只是一个接口，起到一个代理的作用，它的主要工作是映射所请求的页面(文件) 和与此后缀名相对应的实际的处理程序。

让我们更进一步地看一下 ISAPI ，看看它到底是什么样子，请按下面的步骤进行：

打开IIS。
选择随意一个站点，鼠标右键，"属性"。
选择"主目录"选项卡。
选择"配置"。

你应该会看到如下的画面：

图1. 应用程序配置

很清楚地就可以看到，所有IIS所能处理，或者叫 ISAPI 所提供代理服务的文件类型及其相对应的实际的后台处理程序都在这里清楚地列出来了。

我们找到 .aspx 的应用处理程序，然后点"编辑"，会出现下面的画面：

图2. 编辑.aspx文件的处理程序

一路看到这里，可以看出，所有的.aspx文件实际上都是由 aspnet_isapi.dll 这个程序来处理的，当IIS把对于.aspx页面的请求提交给了aspnet_isapi.dll以后，它就不再关心这个请求随后是如何处理的了。现在我们应该知道：Asp.Net 只是服务器(IIS)的一个组成部分而已，它是一个 ISAPI扩展。

这里需要注意两点：

当你修改"限制为"后，可以限制页面(文件)只能以某种特定方式访问
"确认文件是否存在"是实现 URL 地址映射的关键选项，我以后会专门讲述。

理解宿主环境（Hosting）

从本质上讲，Asp.Net 主要是由一系列的类组成，这些类的主要目的就是将Http请求转变为对客户端的响应。HttpRuntime类是Asp.Net的一个主要入口，它有一个称作ProcessRequest 的方法，这个方法以一个 HttpWorkerRequest 类作为参数。HttpRuntime 类几乎包含着关于单个Http请求的所有信息：所请求的文件、服务器端变量、QueryString、Http 头信息等等。Asp.Net 使用这些信息来加载、运行正确的文件，并且将这个请求转换到输出流中，一般来说，也就是HTML页面。

NOTE：二般来说，也可以是张图片。

当 Web.config文件的内容发生改变或者 .aspx文件发生变动的时候，为了能够卸载运行在同一个进程中的应用程序（NOTE：卸载也是为了重新加载），Http请求被分放在相互隔离的应用程序域中。

NOTE：可能你以前就听过应用程序域，但是不了解怎么回事，应用程序域就是 AppDomain。

对于IIS来说，它依赖一个叫做 HTTP.SYS 的内置驱动程序来监听来自外部的 HTTP请求。在操作系统启动的时候，IIS首先在HTTP.SYS中注册自己的虚拟路径。

NOTE：实际上相当于告诉HTTP.SYS哪些URL是可以访问的，哪些是不可以访问的。举个简单的例子：为什么你访问不存在的文件会出现 404 错误呢？就是在这一步确定的。

如果请求的是一个可访问的URL，HTTP.SYS会将这个请求交给 IIS 工作者进程。

NOTE：IIS6.0中叫做 w3wp.exe，IIS5.0中叫做 aspnet_wp.exe。

每个工作者进程都有一个身份标识以及一系列的可选性能参数。

NOTE：可选性能参数，是指诸如回收机制的设置、超时时间设置等等。

接下来进行的事情就是上一章节讲述的 ISAPI 了。

NOTE：这部分的内容相关性比较强，为了让大家好理解，我最后还是决定把 ISAPI 放到前面了，可能全系列完成的时候会再调整吧。

除了映射文件与其对应的处理程序以外，ISAPI 还需要做一些其他的工作：

从HTTP.SYS中获取当前的Httq请求信息，并且将这些信息保存到 HttpWorkerRequest 类中。
在相互隔离的应用程序域AppDomain中加载HttpRuntime。
调用 HttpRuntime的ProcessRequest方法。

接下来才是程序员通常编写的代码所完成的工作了，然后，IIS 接收返回的数据流，并重新返还给 HTTP.SYS，最后，HTTP.SYS 再将这些数据返回给客户端浏览器。

OK，现在你看到张子阳的空间主页了。

图3.Asp.Net 的宿主环境

理解管道（Pipeline）

在前面两章中，我们在一个相对比较低的层次上讨论了从发出Http请求到看到浏览器输出这转瞬即逝的十分之一秒内IIS和 Framework 所做的事情。但是我们忽略了一个细节：程序员编写的代码是如何在这一过程中衔接的，本章我们就来看看这个问题。

当Http请求进入 Asp.Net Runtime以后，它的管道由托管模块（NOTE：Managed Modules）和处理程序（NOTE：Handlers）组成，并且由管道来处理这个 Http请求。

我们按编号来看一下这幅图中的数据是如何流动的。

1. HttpRuntime将Http请求转交给 HttpApplication，HttpApplication代表着程序员创建的Web应用程序。HttpApplication创建针对此Http 请求的 HttpContext对象，这些对象包含了关于此请求的诸多其他对象，主要是HttpRequest、HttpResponse、 HttpSessionState等。这些对象在程序中可以通过Page类或者Context类进行访问。、

2. 接下来Http请求通过一系列Module，这些Module对Http请求具有完全的控制权。这些Module可以做一些执行某个实际工作前的事情。

3. Http请求经过所有的Module之后，它会被HttpHandler处理。在这一步，执行实际的一些操作，通常也就是.aspx页面所完成的业务逻辑。可能你会觉得在创建.aspx页面并没有体会到这一过程，但是，你一定知道，.aspx 页面继承自Page类，我们看一下Page类的签名：

public class Page : TemplateControl, IHttpHandler{
// 代码省略
}

可以看到，Page类实现了IHttpHandler接口，HttpHandler也是Http请求处理的最底层。

4.HttpHandler处理完以后，Http请求再一次回到Module，此时Module可以做一些某个工作已经完成了之后的事情。

NOTE：注意我用红色标识的字，然后回想一下：Asp.Net 中是不是有众多的 Inserting 、Inserted 之类成对的事件？其实，这里讲述的就是为什么Asp.Net可以将一个Insert操作分成前后两部分，然后再分别进行事件拦截的幕后原理。

如果我们将注意力只集中在Http请求、HttpHandler和HttpModule上，不去考虑HttpContext和HttpApplication，那么图4.可以简化成下面这样：

图5.Http请求在HttpHandler 和 HttpModule 中的流动方向

总结

本文中，我首先概要介绍了这系列文章将要为大家讲述的主题。然后，我提出了部分程序员存在的一个问题：在一个比较高的层次上学习和使用Asp.Net。

随后，我以一个访问我个人空间首页的例子，引出了本文主要讲述的三个内容：

Http请求刚刚到达时IIS时，IIS 所做的工作。
Http请求的宿主环境。
Http管道。

希望这篇文章能给你带来帮助。

标签：AspDotNet, HTTP请求, 原理, 好文分享, 应用程序域