简单生活 -- Kevin Yang的博客 » 编解码

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, 字符集, 样式表, 疑难杂症, 编解码

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

文档字符集导致的脚本错误

Kevin Yang — Tue, 18 Aug 2009 18:01:25 +0000

Html页面中可以通过meta标签指定页面文档使用的字符集，这样浏览器就会根据此标签使用指定的字符集去解析文档流，而不用靠“猜”了。

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

文档字符集需要对应文件实际存储使用的字符集，否则会引发很多意料不到而又难以调试的Bug。

问题1——页面显示乱码

如果文档中指定的字符集和文件实际存储的字符集不一致，那么就会造成页面的非ASCII字符显示为乱码。如下面的HTML页面（文件的实际存储格式为UTF-8）：


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>
        <meta http-equiv="Content-Type" content="text/html; charset=gb2312" />
    head>
    <body>
        <div>中文div>
    body>
html>

“中文”会变成“涓枃”。

问题2——脚本执行结果不正确

问题1实际上还是比较容易发现的，因为一看到乱码就可以猜到和字符集相关了。但是如果假设你在上面这个页面的基础上写了如下Javascript代码：

<script type="text/javascript">
    location.href = "http://www.example.com/search?q=" + encodeURI("中文");
script>

你期望将用户重定向到一个特定的页面，你直接在页面中使用了Unicode字符串，并期望encodeURI会使用UTF-8对其进行Url编码。但是实际上你获得的Url却是：

http://www.example.com/search?q=%E6%B6%93%EE%85%9F%E6%9E%83

后台在解析这个Url参数的时候无论使用何种字符集进行Url解码，都无法得到“中文”这个字符串。原因和文章开头提到的乱码问题实际上是同一个问题。如果你的文档字符集和页面存储字符集不一致，那么你在使用非ASCII码字符作字面量（就是直接写在代码里面的字符串）的时候就会出现意料不到的各种问题。

问题3——脚本抛出异常

在问题2举的例子中，脚本执行的时候没有抛出异常，但是其执行的结果却不是我们所期望的。在下面这个例子中，脚本的执行过程甚至会抛出莫名其妙的异常。

<script type="text/javascript">
    alert("对象初始化");
script>

如果你真到第8行去看那段脚本，你会发现，你死活就是看不出问题来，直到你把中文替换成英文之后你才可能会恍然大悟。

问题4——引用外部脚本导致的异常

现在我们把页面存储成gb2312，再运行问题3中的示例代码，这个时候就没有问题了。为了Html页面的纯洁性，我们将脚本移到一个独立的Js文件中去，并在Html中引用这个脚本文件。如下：


页面index.html
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>
        <meta http-equiv="Content-Type" content="text/html; charset=gb2312" />
    head>
    <body>
        <script type="text/javascript" src="script/test.js">script>
    body>
html>

脚本script/test.js
alert("对象初始化");

这个时候再查看index.html页面的时候，我们发现，脚本又抛出问题3的异常来了。这是为什么呢？

这是因为，当Html页面在引用一个外部资源的时候，使用的字符集就是当前文档字符集。因此test.js文件会被浏览器使用gb2312字符集去解析，而我在Aptana中建此文件的时候，默认的文件存储格式就是utf-8，因此还是回归到了文档字符集和存储字符集不一致的问题上来。

这个问题，我们可以通过在引用外部资源的时候显式指定charset属性来解决。

<script type="text/javascript" src="script/test.js" charset="utf-8">script>

update:

以上试验提到的UTF-8均指UTF-8 without BOM，即不带标记的UTF-8。IE、Chrome、Opera和Safari均能支持BOM标记，这就意味着，如果你的文件本身是以UTF-8 with BOM编码的，那么无需指定charset，浏览器也能正确解析。此优先级最高。Firefox则无法正确识别BOM标记，因此总会以页面中指定的charset或者HTTP响应中的charset来解析文档。

——Kevin Yang

标签：charset, Web传统技术, 字符集, 引用外部脚本, 文档字符集, 编解码, 脚本, 脚本异常

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

详解Javascript中的Url编码/解码

Kevin Yang — Tue, 18 Aug 2009 17:21:35 +0000

摘要

本文主要针对URI编解码的相关问题做了介绍，对Url编码中哪些字符需要编码、为什么需要编码做了详细的说明，并对比分析了Javascript中和编解码相关的几对函数escape / unescape,encodeURI / decodeURI和encodeURIComponent / decodeURIComponent。

预备知识

   foo://example.com:8042/over/there?name=ferret#nose
   \_/ \______________/ \________/\_________/ \__/
     |                 |                        |                    |             |
scheme     authority               path             query      fragment

URI是统一资源标识的意思，通常我们所说的Url只是URI的一种。典型Url的格式如上面所示。下面提到的Url编码，实际上应该指的是URI编码。

为什么需要Url编码

通常如果一样东西需要编码，说明这样东西并不适合传输。原因多种多样，如Size过大，包含隐私数据，对于Url来说，之所以要进行编码，是因为Url中有些字符会引起歧义。

例如Url参数字符串中使用key=value键值对这样的形式来传参，键值对之间以&符号分隔，如/s?q=abc&ie=utf-8。如果你的value字符串中包含了=或者&，那么势必会造成接收Url的服务器解析错误，因此必须将引起歧义的&和=符号进行转义，也就是对其进行编码。

又如，Url的编码格式采用的是ASCII码，而不是Unicode，这也就是说你不能在Url中包含任何非ASCII字符，例如中文。否则如果客户端浏览器和服务端浏览器支持的字符集不同的情况下，中文可能会造成问题。

Url编码的原则就是使用安全的字符（没有特殊用途或者特殊意义的可打印字符）去表示那些不安全的字符。

哪些字符需要编码

RFC3986文档规定，Url中只允许包含英文字母（a-zA-Z）、数字（0-9）、-_.~4个特殊字符以及所有保留字符。

RFC3986文档对Url的编解码问题做出了详细的建议，指出了哪些字符需要被编码才不会引起Url语义的转变，以及对为什么这些字符需要编码做出了相应的解释。

US-ASCII字符集中没有对应的可打印字符

Url中只允许使用可打印字符。US-ASCII码中的10-7F字节全都表示控制字符，这些字符都不能直接出现在Url中。同时，对于80-FF字节（ISO-8859-1），由于已经超出了US-ACII定义的字节范围，因此也不可以放在Url中。

保留字符

Url可以划分成若干个组件，协议、主机、路径等。有一些字符（:/?#[]@）是用作分隔不同组件的。例如:冒号用于分隔协议和主机，/用于分隔主机和路径，?用于分隔路径和查询参数，等等。还有一些字符（!$&'()*+,;=）用于在每个组件中起到分隔作用的，如=用于表示查询参数中的键值对，&符号用于分隔查询多个键值对。当组件中的普通数据包含这些特殊字符时，需要对其进行编码。

RFC3986中指定了以下字符为保留字符：

(

)

;

[

]

不安全字符

还有一些字符，当他们直接放在Url中的时候，可能会引起解析程序的歧义。这些字符被视为不安全字符，原因有很多。

空格	Url在传输的过程，或者用户在排版的过程，或者文本处理程序在处理Url的过程，都有可能引入无关紧要的空格，或者将那些有意义的空格给去掉
引号以及<>	引号和尖括号通常用于在普通文本中起到分隔Url的作用
#	通常用于表示书签或者锚点
%	百分号本身用作对不安全字符进行编码时使用的特殊字符，因此本身需要编码
{}\|\^[]`~	某一些网关或者传输代理会篡改这些字符

需要注意的是，对于Url中的合法字符，编码和不编码是等价的，但是对于上面提到的这些字符，如果不经过编码，那么它们有可能会造成Url语义的不同。因此对于Url而言，只有普通英文字符和数字，特殊字符$-_.+!*'()还有保留字符，才能出现在未经编码的Url之中。其他字符均需要经过编码之后才能出现在Url中。

但是由于历史原因，目前尚存在一些不标准的编码实现。例如对于~符号，虽然RFC3986文档规定，对于波浪符号~，不需要进行Url编码，但是还是有很多老的网关或者传输代理会

如何对Url中的非法字符进行编码

Url编码通常也被称为百分号编码（Url Encoding，also known as percent-encoding），是因为它的编码方式非常简单，使用%百分号加上两位的字符——0123456789ABCDEF——代表一个字节的十六进制形式。Url编码默认使用的字符集是US-ASCII。例如a在US-ASCII码中对应的字节是0x61，那么Url编码之后得到的就是%61，我们在地址栏上输入http://g.cn/search?q=%61%62%63，实际上就等同于在google上搜索abc了。又如@符号在ASCII字符集中对应的字节为0x40，经过Url编码之后得到的是%40。

常见字符的Url编码列表：

保留字符的Url编码
!	*	"	'	(	)	;	:	@	&
`%21`	`%2A`	`%22`	`%27`	`%28`	`%29`	`%3B`	`%3A`	`%40`	`%26`
=	+	$	,	/	?	%	#	[	]
`%3D`	`%2B`	`%24`	`%2C`	`%2F`	`%3F`	`%25`	`%23`	`%5B`	`%5D`

对于非ASCII字符，需要使用ASCII字符集的超集进行编码得到相应的字节，然后对每个字节执行百分号编码。对于Unicode字符，RFC文档建议使用utf-8对其进行编码得到相应的字节，然后对每个字节执行百分号编码。如“中文”使用UTF-8字符集得到的字节为0xE4 0xB8 0xAD 0xE6 0x96 0x87，经过Url编码之后得到“%E4%B8%AD%E6%96%87”。

如果某个字节对应着ASCII字符集中的某个非保留字符，则此字节无需使用百分号表示。例如“Url编码”，使用UTF-8编码得到的字节是0x55 0x72 0x6C 0xE7 0xBC 0x96 0xE7 0xA0 0x81，由于前三个字节对应着ASCII中的非保留字符“Url”，因此这三个字节可以用非保留字符“Url”表示。最终的Url编码可以简化成“Url%E7%BC%96%E7%A0%81” ，当然，如果你用"%55%72%6C%E7%BC%96%E7%A0%81”也是可以的。

由于历史的原因，有一些Url编码实现并不完全遵循这样的原则，下面会提到。

Javascript中的escape,encodeURI和encodeURIComponent的区别

Javascript中提供了3对函数用来对Url编码以得到合法的Url，它们分别是escape / unescape,encodeURI / decodeURI和encodeURIComponent / decodeURIComponent。由于解码和编码的过程是可逆的，因此这里只解释编码的过程。

这三个编码的函数——escape，encodeURI，encodeURIComponent——都是用于将不安全不合法的Url字符转换为合法的Url字符表示，它们有以下几个不同点。

安全字符不同

下面的表格列出了这三个函数的安全字符（即函数不会对这些字符进行编码）

	安全字符
escape（69个）	*/@+-._0-9a-zA-Z
encodeURI（82个）	!#$&'()*+,/:;=?@-._~0-9a-zA-Z
encodeURIComponent（71个）	!'()*-._~0-9a-zA-Z

兼容性不同

escape函数是从Javascript1.0的时候就存在了，其他两个函数是在Javascript1.5才引入的。但是由于Javascript1.5已经非常普及了，所以实际上使用encodeURI和encodeURIComponent并不会有什么兼容性问题。

对Unicode字符的编码方式不同

这三个函数对于ASCII字符的编码方式相同，均是使用百分号+两位十六进制字符来表示。但是对于Unicode字符，escape的编码方式是%uxxxx，其中的xxxx是用来表示unicode字符的4位十六进制字符。这种方式已经被W3C废弃了。但是在ECMA-262标准中仍然保留着escape的这种编码语法。encodeURI和encodeURIComponent则使用UTF-8对非ASCII字符进行编码，然后再进行百分号编码。这是RFC推荐的。因此建议尽可能的使用这两个函数替代escape进行编码。

适用场合不同

encodeURI被用作对一个完整的URI进行编码，而encodeURIComponent被用作对URI的一个组件进行编码。

从上面提到的安全字符范围表格来看，我们会发现，encodeURIComponent编码的字符范围要比encodeURI的大。我们上面提到过，保留字符一般是用来分隔URI组件（一个URI可以被切割成多个组件，参考预备知识一节）或者子组件（如URI中查询参数的分隔符），如:号用于分隔scheme和主机，?号用于分隔主机和路径。由于encodeURI操纵的对象是一个完整的的URI，这些字符在URI中本来就有特殊用途，因此这些保留字符不会被encodeURI编码，否则意义就变了。

组件内部有自己的数据表示格式，但是这些数据内部不能包含有分隔组件的保留字符，否则就会导致整个URI中组件的分隔混乱。因此对于单个组件使用encodeURIComponent，需要编码的字符就更多了。

表单提交

当Html的表单被提交时，每个表单域都会被Url编码之后才在被发送。由于历史的原因，表单使用的Url编码实现并不符合最新的标准。例如对于空格使用的编码并不是%20，而是+号，如果表单使用的是Post方法提交的，我们可以在HTTP头中看到有一个Content-Type的header，值为application/x-www-form-urlencoded。大部分应用程序均能处理这种非标准实现的Url编码，但是在客户端Javascript中，并没有一个函数能够将+号解码成空格，只能自己写转换函数。还有，对于非ASCII字符，使用的编码字符集取决于当前文档使用的字符集。例如我们在Html头部加上

<meta http-equiv="Content-Type" content="text/html; charset=gb2312" />

这样浏览器就会使用gb2312去渲染此文档（注意，当HTML文档中没有设置此meta标签，则浏览器会根据当前用户喜好去自动选择字符集，用户也可以强制当前网站使用某个指定的字符集）。当提交表单时，Url编码使用的字符集就是gb2312。

文档字符集会影响encodeURI吗？

之前在使用Aptana（为什么专指aptana下面会提到）遇到一个很迷惑的问题，就是在使用encodeURI的时候，发现它编码得到的结果和我想的很不一样。下面是我的示例代码：


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>
        <meta http-equiv="Content-Type" content="text/html; charset=gb2312" />
    head>
    <body>
        <script type="text/javascript">
            document.write(encodeURI("中文"));
        script>
    body>
html>

运行结果输出%E6%B6%93%EE%85%9F%E6%9E%83。显然这并不是使用UTF-8字符集进行Url编码得到的结果（在Google上搜索“中文”，Url中显示的是%E4%B8%AD%E6%96%87）。

所以我当时就很质疑，难道encodeURI还跟页面编码有关，但是我发现，正常情况下，如果你使用gb2312进行Url编码也不会得到这个结果的才是。后来终于被我发现，原来是页面文件存储使用的字符集和Meta标签中指定的字符集不一致导致的问题。Aptana的编辑器默认情况下使用UTF-8字符集。也就是说这个文件实际存储的时候使用的是UTF-8字符集。但是由于Meta标签中指定了gb2312，这个时候，浏览器就会按照gb2312去解析这个文档，那么自然在“中文”这个字符串这里就会出错，因为“中文”字符串用UTF-8编码过后得到的字节是0xE4 0xB8 0xAD 0xE6 0x96 0x87，这6个字节又被浏览器拿gb2312去解码，那么就会得到另外三个汉字“涓枃”（GBK中一个汉字占两个字节），这三个汉字在传入encodeURI函数之后得到的结果就是%E6%B6%93%EE%85%9F%E6%9E%83。因此，encodeURI使用的还是UTF-8，并不会受到页面字符集的影响。

其他和Url编码相关的问题

对于包含中文的Url的处理问题，不同浏览器有不同的表现。例如对于IE，如果你勾选了高级设置“总是以UTF-8发送Url”，那么Url中的路径部分的中文会使用UTF-8进行Url编码之后发送给服务端，而查询参数中的中文部分使用系统默认字符集进行Url编码。为了保证最大互操作性，建议所有放到Url中的组件全部显式指定某个字符集进行Url编码，而不依赖于浏览器的默认实现。

另外，很多HTTP监视工具或者浏览器地址栏等在显示Url的时候会自动将Url进行一次解码（使用UTF-8字符集），这就是为什么当你在Firefox中访问Google搜索中文的时候，地址栏显示的Url包含中文的缘故。但实际上发送给服务端的原始Url还是经过编码的。你可以在地址栏上使用Javascript访问location.href就可以看出来了。在研究Url编解码的时候千万别被这些假象给迷惑了。

——Kevin Yang

标签：Javascript, RFC文档, UrlEncode, Url编码, Web传统技术, 字符集, 编解码

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

Excel中使用VBA自定义函数对字符串进行Url编码（UTF-8）

Kevin Yang — Mon, 27 Apr 2009 18:09:58 +0000

Excel是个非常强大的工具，工作中因为需要用到他老完成一些表格数据的处理，所以抽空学了一点小技巧。

VBA是Visual Basic Application的全称，我们在Office的产品家族里面会经常看到它的身影。甚至SQL Server里头也有它的足迹，善于使用这些VBA函数或者自定义一些函数能够帮我们实现一些看似很强大的功能而又不用花费太大的精力。

步骤一. 打开Excel 2007中的Visual Basic编辑器

在Excel 2007中的开发工具菜单下，点击Visual Basic，即可弹出Visual Basic的编辑界面。默认情况下，这个开发工具在功能区是不显示的，需要在Excel设置中勾选上，如下图。

步骤二. 编写自定义函数

选择菜单->插入->模块，就会弹出一个编辑窗口，在其中输入下面代码，即可定义一个UrlEncode的函数。

Public Function UrlEncode(ByRef szString As String) As String
       Dim szChar   As String
       Dim szTemp   As String
       Dim szCode   As String
       Dim szHex    As String
       Dim szBin    As String
       Dim iCount1  As Integer
       Dim iCount2  As Integer
       Dim iStrLen1 As Integer
       Dim iStrLen2 As Integer
       Dim lResult  As Long
       Dim lAscVal  As Long
       szString = Trim$(szString)
       iStrLen1 = Len(szString)
       For iCount1 = 1 To iStrLen1
           szChar = Mid$(szString, iCount1, 1)
           lAscVal = AscW(szChar)
           If lAscVal >= &H0 And lAscVal <= &HFF Then
              If (lAscVal >= &H30 And lAscVal <= &H39) Or _
                 (lAscVal >= &H41 And lAscVal <= &H5A) Or _
                 (lAscVal >= &H61 And lAscVal <= &H7A) Then
                 szCode = szCode & szChar
              Else

                 szCode = szCode & "%" & Hex(AscW(szChar))
              End If
           Else
              szHex = Hex(AscW(szChar))
              iStrLen2 = Len(szHex)
              For iCount2 = 1 To iStrLen2
                  szChar = Mid$(szHex, iCount2, 1)
                  Select Case szChar
                         Case Is = "0"
                              szBin = szBin & "0000"
                         Case Is = "1"
                              szBin = szBin & "0001"
                         Case Is = "2"
                              szBin = szBin & "0010"
                         Case Is = "3"
                              szBin = szBin & "0011"
                         Case Is = "4"
                              szBin = szBin & "0100"
                         Case Is = "5"
                        szBin = szBin & "0101"
                         Case Is = "6"
                              szBin = szBin & "0110"
                         Case Is = "7"
                              szBin = szBin & "0111"
                         Case Is = "8"
                              szBin = szBin & "1000"
                         Case Is = "9"
                              szBin = szBin & "1001"
                         Case Is = "A"
                              szBin = szBin & "1010"
                         Case Is = "B"
                              szBin = szBin & "1011"
                         Case Is = "C"
                              szBin = szBin & "1100"
                         Case Is = "D"
                              szBin = szBin & "1101"
                         Case Is = "E"
                              szBin = szBin & "1110"
                         Case Is = "F"
                              szBin = szBin & "1111"
                         Case Else
                  End Select
              Next iCount2
              szTemp = "1110" & Left$(szBin, 4) & "10" & Mid$(szBin, 5, 6) & "10" & Right$(szBin, 6)
              For iCount2 = 1 To 24
                  If Mid$(szTemp, iCount2, 1) = "1" Then
                     lResult = lResult + 1 * 2 ^ (24 - iCount2)
                  Else: lResult = lResult + 0 * 2 ^ (24 - iCount2)
                  End If
              Next iCount2
              szTemp = Hex(lResult)
                    szCode = szCode & "%" & Left$(szTemp, 2) & "%" & Mid$(szTemp, 3, 2) & "%" & Right$(szTemp, 2)
           End If
           szBin = vbNullString
           lResult = 0
       Next iCount1
       UrlEncode = szCode
End Function

步骤三：测试

定义完之后，我们选择菜单->文件->关闭并返回Excel。然后我们就可以在Excel中测试刚才定义的这个函数了。如下图所示。

注意，使用了VBA函数的excel文件需要在打开时启用宏，否则函数无效。

标签：Excel, Office, UrlEncode, UTF-8, VBA, 中文编码, 代码库, 函数, 工具技巧, 技巧, 编解码, 自定义函数

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

字符编解码的故事（ASCII，ANSI，Unicode，Utf-8区别）

Kevin Yang — Sun, 01 Mar 2009 00:58:15 +0000

（关于字符编码的深入解释，请参见我的原创文章《关于字符编码，你所需要知道的》。）

此文为转载，有少许修订，原文出处不详。

很久很久以前，有一群人，他们决定用8个可以开合的晶体管来组合成不同的状态，以表示世界上的万物。他们认为8个开关状态作为原子单位很好，于是他们把这称为"字节"。

再后来，他们又做了一些可以处理这些字节的机器，机器开动了，可以用字节来组合出更多的状态，状态开始变来变去。他们看到这样是好的，于是它们就这机器称为"计算机"。

开始计算机只在美国用。八位的字节一共可以组合出256（2的8次方）种不同的状态。

他们把其中的编号从0开始的32种状态分别规定了特殊的用途，一但终端设备或者打印机遇上这些约定好的字节时，就要做一些约定的动作。遇上 00x10, 终端就换行，遇上0x07, 终端就向人们嘟嘟叫，例好遇上0x1b, 打印机就打印反白的字，对于终端就用彩色显示字母。他们看到这样很好，于是就把这些0x20（十进制32）以下的字节状态称为"控制码"。

他们又把所有的空格、标点符号、数字、大小写字母分别用连续的字节状态表示，一直编到了第127号，这样计算机就可以用不同字节来存储英语的文字了。大家看到这样，都感觉很好，于是大家都把这个方案叫做 ANSI 的"Ascii"编码（American Standard Code for Information Interchange，美国信息互换标准代码）。当时世界上所有的计算机都用同样的ASCII方案来保存英文文字。

后来，就像建造巴比伦塔一样，世界各地的都开始使用计算机，但是很多国家用的不是英文，他们用到的许多字母在ASCII中根本没有，为了也可以在计算机中保存他们的文字，他们决定采用127号之后的空位来表示这些新的字母、符号，还加入了很多画表格时需要用下到的横线、竖线、交叉等形状，一直把序号编到了最后一个状态255。从128到255这一页的字符集被称"扩展字符集"。从此之后，贪婪的人类再没有新的状态可以用了，美帝国主义可能没有想到还有第三世界国家的人们也希望可以用到计算机吧！

等中国人们得到计算机时，已经没有可以利用的字节状态来表示汉字，况且有6000多个常用汉字需要保存呢。但是这难不倒智慧的中国人民，我们不客气地把那些127号之后的奇异符号们直接取消掉，并且规定：一个小于127的字符的意义与原来相同，但两个大于127的字符连在一起时，就表示一个汉字，前面的一个字节（他称之为高字节）从0xA1用到 0xF7，后面一个字节（低字节）从0xA1到0xFE，这样我们就可以组合出大约7000多个简体汉字了。在这些编码里，我们还把数学符号、罗马希腊的字母、日文的假名们都编进去了，连在 ASCII 里本来就有的数字、标点、字母都统统重新编了两个字节长的编码，这就是常说的"全角"字符，而原来在127号以下的那些就叫"半角"字符了。

中国人民看到这样很不错，于是就把这种汉字方案叫做"GB2312"。GB2312 是对 ASCII 的中文扩展。

但是中国的汉字太多了，我们很快就就发现有许多人的人名没有办法在这里打出来，特别是某些很会麻烦别人的国家领导人（如朱镕基的“镕”字）。于是我们不得不继续把 GB2312 没有用到的码位找出来老实不客气地用上。

后来还是不够用，于是干脆不再要求低字节一定是127号之后的内码，只要第一个字节是大于127就固定表示这是一个汉字的开始，不管后面跟的是不是扩展字符集里的内容。结果扩展之后的编码方案被称为 GBK 标准，GBK 包括了 GB2312 的所有内容，同时又增加了近20000个新的汉字（包括繁体字）和符号。

后来少数民族也要用电脑了，于是我们再扩展，又加了几千个新的少数民族的字，GBK 扩成了 GB18030。从此之后，中华民族的文化就可以在计算机时代中传承了。

中国的程序员们看到这一系列汉字编码的标准是好的，于是通称他们叫做 "DBCS"（Double Byte Charecter Set 双字节字符集）。在DBCS系列标准里，最大的特点是两字节长的汉字字符和一字节长的英文字符并存于同一套编码方案里，因此他们写的程序为了支持中文处理，必须要注意字串里的每一个字节的值，如果这个值是大于127的，那么就认为一个双字节字符集里的字符出现了。那时候凡是受过加持，会编程的计算机僧侣们都要每天念下面这个咒语数百遍：

"一个汉字算两个英文字符！一个汉字算两个英文字符……"

因为当时各个国家都像中国这样搞出一套自己的编码标准，结果互相之间谁也不懂谁的编码，谁也不支持别人的编码，连大陆和台湾这样只相隔了150海里，使用着同一种语言的兄弟地区，也分别采用了不同的 DBCS 编码方案——当时的中国人想让电脑显示汉字，就必须装上一个"汉字系统"，专门用来处理汉字的显示、输入的问题，但是那个台湾的愚昧封建人士写的算命程序就必须加装另一套支持 BIG5 编码的什么"倚天汉字系统"才可以用，装错了字符系统，显示就会乱了套！这怎么办？而且世界民族之林中还有那些一时用不上电脑的穷苦人民，他们的文字又怎么办？

真是计算机的巴比伦塔命题啊！

正在这时，大天使加百列及时出现了——一个叫 ISO （国际标谁化组织）的国际组织决定着手解决这个问题。他们采用的方法很简单：废了所有的地区性编码方案，重新搞一个包括了地球上所有文化、所有字母和符号的编码！他们打算叫它"Universal Multiple-Octet Coded Character Set"，简称 UCS, 俗称 "UNICODE"。

UNICODE 开始制订时，计算机的存储器容量极大地发展了，空间再也不成为问题了。于是 ISO 就直接规定必须用两个字节，也就是16位来统一表示所有的字符，对于ascii里的那些"半角"字符，UNICODE 包持其原编码不变，只是将其长度由原来的8位扩展为16位，而其他文化和语言的字符则全部重新统一编码。由于"半角"英文符号只需要用到低8位，所以其高 8位永远是0，因此这种大气的方案在保存英文文本时会多浪费一倍的空间。

这时候，从旧社会里走过来的程序员开始发现一个奇怪的现象：他们的strlen函数靠不住了，一个汉字不再是相当于两个字符了，而是一个！是的，从 UNICODE 开始，无论是半角的英文字母，还是全角的汉字，它们都是统一的"一个字符"！同时，也都是统一的"两个字节"，请注意"字符"和"字节"两个术语的不同， "字节"是一个8位的物理存贮单元，而"字符"则是一个文化相关的符号。在UNICODE 中，一个字符就是两个字节。一个汉字算两个英文字符的时代已经快过去了。

从前多种字符集存在时，那些做多语言软件的公司遇上过很大麻烦，他们为了在不同的国家销售同一套软件，就不得不在区域化软件时也加持那个双字节字符集咒语，不仅要处处小心不要搞错，还要把软件中的文字在不同的字符集中转来转去。UNICODE 对于他们来说是一个很好的一揽子解决方案，于是从 Windows NT 开始，MS 趁机把它们的操作系统改了一遍，把所有的核心代码都改成了用 UNICODE 方式工作的版本，从这时开始，WINDOWS 系统终于无需要加装各种本土语言系统，就可以显示全世界上所有文化的字符了。

但是，UNICODE 在制订时没有考虑与任何一种现有的编码方案保持兼容，这使得 GBK 与UNICODE 在汉字的内码编排上完全是不一样的，没有一种简单的算术方法可以把文本内容从UNICODE编码和另一种编码进行转换，这种转换必须通过查表来进行。

如前所述，UNICODE 是用两个字节来表示为一个字符，他总共可以组合出65535不同的字符，这大概已经可以覆盖世界上所有文化的符号。如果还不够也没有关系，ISO已经准备了UCS-4方案，说简单了就是四个字节来表示一个字符，这样我们就可以组合出21亿个不同的字符出来（最高位有其他用途），这大概可以用到银河联邦成立那一天吧！

UNICODE 来到时，一起到来的还有计算机网络的兴起，UNICODE 如何在网络上传输也是一个必须考虑的问题，于是面向传输的众多 UTF（UCS Transfer Format）标准出现了，顾名思义，UTF8就是每次8个位传输数据，而UTF16就是每次16个位，只不过为了传输时的可靠性，从UNICODE到 UTF时并不是直接的对应，而是要过一些算法和规则来转换。

受到过网络编程加持的计算机僧侣们都知道，在网络里传递信息时有一个很重要的问题，就是对于数据高低位的解读方式，一些计算机是采用低位先发送的方法，例如我们PC机采用的 INTEL 架构；而另一些是采用高位先发送的方式。在网络中交换数据时，为了核对双方对于高低位的认识是否是一致的，采用了一种很简便的方法，就是在文本流的开始时向对方发送一个标志符——如果之后的文本是高位在位，那就发送"FEFF"，反之，则发送"FFFE"。不信你可以用二进制方式打开一个UTF-X格式的文件，看看开头两个字节是不是这两个字节？

下面是Unicode和UTF-8转换的规则

Unicode

UTF-8

0000 - 007F

0xxxxxxx

0080 - 07FF

110xxxxx 10xxxxxx

0800 - FFFF

1110xxxx 10xxxxxx 10xxxxxx

例如"汉"字的Unicode编码是6C49。6C49在0800-FFFF之间，所以要用3字节模板：1110xxxx 10xxxxxx 10xxxxxx。将6C49写成二进制是：0110 1100 0100 1001，将这个比特流按三字节模板的分段方法分为0110 110001 001001，依次代替模板中的x，得到：1110-0110 10-110001 10-001001，即E6 B1 89，这就是其UTF8的编码。

讲到这里，我们再顺便说说一个很著名的奇怪现象：当你在 windows 的记事本里新建一个文件，输入"联通"两个字之后，保存，关闭，然后再次打开，你会发现这两个字已经消失了，代之的是几个乱码！呵呵，有人说这就是联通之所以拼不过移动的原因。

其实这是因为GB2312编码与UTF8编码产生了编码冲撞的原因。

当一个软件打开一个文本时，它要做的第一件事是决定这个文本究竟是使用哪种字符集的哪种编码保存的。软件一般采用三种方式来决定文本的字符集和编码：

检测文件头标识，提示用户选择，根据一定的规则猜测

最标准的途径是检测文本最开头的几个字节，开头字节 Charset/encoding,如下表：

EF BB BF UTF-8

FF FE UTF-16/UCS-2, little endian

FE FF UTF-16/UCS-2, big endian

FF FE 00 00 UTF-32/UCS-4, little endian.

00 00 FE FF UTF-32/UCS-4, big-endian.

当你新建一个文本文件时，记事本的编码默认是ANSI（代表系统默认编码，在中文系统中一般是GB系列编码）, 如果你在ANSI的编码输入汉字，那么他实际就是GB系列的编码方式，在这种编码下，"联通"的内码是：

c1 1100 0001

aa 1010 1010

cd 1100 1101

a8 1010 1000

注意到了吗？第一二个字节、第三四个字节的起始部分的都是"110"和"10"，正好与UTF8规则里的两字节模板是一致的，

于是当我们再次打开记事本时，记事本就误认为这是一个UTF8编码的文件，让我们把第一个字节的110和第二个字节的10去掉，我们就得到了"00001 101010"，再把各位对齐，补上前导的0，就得到了"0000 0000 0110 1010"，不好意思，这是UNICODE的006A，也就是小写的字母"j"，而之后的两字节用UTF8解码之后是0368，这个字符什么也不是。这就是只有"联通"两个字的文件没有办法在记事本里正常显示的原因。

而如果你在"联通"之后多输入几个字，其他的字的编码不见得又恰好是110和10开始的字节，这样再次打开时，记事本就不会坚持这是一个utf8编码的文件，而会用ANSI的方式解读之，这时乱码又不出现了。

标签：ANSI, ASCII, Unicode, UTF-8, 好文分享, 字符编解码, 字符集, 编解码