在日常的前端开发工作中，我们会经常的与HTML、javascript、css等语言打交道，和一门真正的语言一样，计算机语言也有它的字母表、语法、词法、编码方式等，在这里我简单的谈一下前端HTML与javascript日常工作中常碰到的编码问题。

在计算机中，我们储存的信息都是用二进制码表示的。我们认识的、屏幕上显示的英文、汉字等符号和储存用的二进制代码的互相转换，就是编码。

有两个基本概念需要说明，charset 和 character encoding：

charset ，字符集，也就是某个符号和某个数字映射关系的一个表，也就是它决定了107 是koubei 的 ‘a’，21475 是口碑的“口”，不同的表有不同的映射关系，如 ascii，gb2312，Unicode. 通过这个数字和字符的映射表，我们可以把一个二进制表示的数字转换成某个字符。
chracter encoding ，编码方式。例如，同是对于应“口”的 21475 这个数，我们是用 \u5k3e3 表示呢，还是用 %E5%8F%A3 来表示呢？这就是由 character encoding 来决定的。

对于 ‘koubei.com’ 这样的 字符串来说，是美国人的常用字符，他们就制定了一个 叫做ASCII 的字符集，全称是 american standard code of information interchange 美国标准信息交换码，用0-127这128个数字，（2的7次方，0×00-0x7f) 代表了123abc这样的常用的128个字符。一共是 7 bits，再加上第一个是符号位，要用来去补码反码表示负数什么的，一共8 bits 构成一个 byte。当年美国人就是小气了点，要是一开始就设计成一个 byte 是16 bits、32 bits，世界上会少很多问题，不过当时，估计他们觉得 8 bits 就够了，可以表示128个不同的字符呢！

介于计算机这玩意儿是美国人搞出来的，所以他们自己省事，把自家用的符号都编码好了，用的挺爽的。但当计算机开始国际化的时候，问题出来了，拿中国举例吧，汉字就好几万，怎么办？

现有的 8 bits 一个 byte 的系统是基础，不能破坏，不能去改到 16 bits之类的，否则改动太大了，只能走另一条路：用多个 ascii 的字符去表示一个其他字符，也就是 MBCS ( Multi-Byte Character System，多字节字符系统)。
有了这个 MBCS 的概念，我们可以表示更多个字符了，比如我们用 2 个 ascii 字符，就有 16 bits, 理论上有 2 的 16 次方 65536 个字符。但这些编码怎么分配到字符上呢？比如口碑的”口”的 Unicode 编码就是 21475，谁决定的呢？字符集，也就是刚刚介绍的charset。ascii就是最基础的一个字符集，在此之上，我们有类似于 gb2312， big5这样针对简体中文和繁体中文的MBCS的字符集等等。终于有个叫 Unicode Consortium 的机构，决定做一个囊括所有字符在内的字符集（UCS, Universal Character Set）和对应编码方式的标准，即 Unicode。从1991年开始，它发布了第一版 Unicode 国际标准，ISBN 0-321-18578-1 ，国际标准化组织 ISO 也参与了这个的定制，ISO/IEC 10646 : the Universal Character Set。总之，Unicode 是个基本覆盖了所有已经存在的地球上的符号的字符标准了，现在正在被越来越广泛的使用，ECMA 标准也规定，javascript语言的内部字符使用 Unicode 标准（这意味着，javascript的变量名、函数名等是允许中文的！）。

对于身在中国的开发者来说，可能碰到比较多的问题就是 gbk,  gb2312, utf-8 之间转换之类的问题了。严格的说这个说法不是很准确，gbk，gb2312是字符集 (charset)，而 utf-8 是一种编码方式 (character encoding) ，是 Unicode 标准中 UCS 字符集的一种编码方式，因为使用 Unicode 字符集的网页主要用UTF-8编码，所以大家常常就把它们并列了，其实是不准确的。

有了 Unicode 后，至少人类文明没有碰到外星人之前，这是一把万能钥匙了，都用它吧。而现在使用最广泛 Unicode 的编码方式就是 UTF-8 (8-bit UCS/Unicode Transformation Format) 了，它有几个特别好的地方：
1，编码 UCS 字符集，全世界通用
2，是一种变长编码方式（variable-length character encoding），兼容 ascii
第二点是个很大的优点，它使得以前使用纯 ascii 编码的系统兼容，而且不会增加额外的存储量（假设定长的编码方式，规定每个字符由2个 bytes 组成，那么这时候 ascii 字符占用的存储空间将增大一倍）。

要把 UTF-8 说清楚，引入一个表会更方便了:

U-00000000 - U-0000007F:    0xxxxxxx
U-00000080 - U-000007FF:    110xxxxx 10xxxxxx
U-00000800 - U-0000FFFF:    1110xxxx 10xxxxxx 10xxxxxx
U-00010000 - U-001FFFFF:    11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
U-00200000 - U-03FFFFFF:    111110xx 10xxxxxx 10xxxxxx 10xxxxxx  10xxxxxx
U-04000000 - U-7FFFFFFF:    1111110x 10xxxxxx 10xxxxxx 10xxxxxx  10xxxxxx 10xxxxxx

要看懂这个表呢，我们看前两行就够了

U-00000000 - U-0000007F:
0xxxxxxx 第一行是这样的，意思是说，如果你发现一个utf-8编码的 byte 的二进制码是0xxxxxxx，是0开头的， 即十进制的0-127之间，那么他就是单独的这一 byte 代表一个字符，而且是拥有和 ascii 码完全一样的含义。其他所有的 utf8 编码的二进制值都是用1开头的1xxxxxxx，大于127的，而且都需要至少2 bytes才能代表一个符号。所以一个字节的第一位是一个开关，代表这个字符是不是一个 ascii 码。这个就是刚才谈到的兼容性，从英文定义上看，就是utf8编码的两个属性：

UCS characters U+0000 to U+007F (ASCII) are encoded simply as bytes 0×00 to 0x7F (ASCII compatibility). This means that files and strings which contain only 7-bit ASCII characters have the same encoding under both ASCII and UTF-8.
All UCS characters >U+007F are encoded as a sequence of several bytes, each of which has the most significant bit set. Therefore, no ASCII byte (0×00-0x7F) can appear as part of any other character.

然后我们看看第二行：

U-00000080 - U-000007FF:    110xxxxx 10xxxxxx
先看第一个字节：110xxxxx，它的含义是，我不是一个 ascii 码（因为第一位不为0），我是一个多 bytes 字符的第一个 byte （第二位为1），我参与表示的这个字符是由2个 bytes 组成的（第三位为0），从第四位开始，就是字符的信息储存的位置。
再看第二个字节：10xxxxxx，它的含义是：我不是一个 ascii 码（因为第一位不为0），我不是一个多 bytes 字符的第一个 byte （第二位为0），第三位开始是字符的信息储存的位置。

从这个例子中可以总结出来，utf-8编码方式中，在一长串连续的二进制 byte 码中，可能由2个至6个 bytes 来表示一个符号，那么相比较于用一个 byte 表示符号的 ascii 码，我们需要空间来储存两个额外信息： 一，这个符号开始位置，一个“starter”的位置，用生物学上的话来说，就是蛋白质翻译时候起始密码子AUG的位置了；二，这个符号使用的 bytes 数（其实如果每个符号都有 starter，这个长度是可以不提供的，但是提供长度信息增加了在部分 bytes 丢失时的容错能力）。解决方案是：用一个 byte 的第二位是否是1来代表这一 byte 是否是一个字符的起始 byte （因为一个 byte 里面的第一位刚才已经被使用了，0表示ascii码，1表示非ascii )，即，一个多字节符号的第一 个bytes一定是 11xxxxxx，一个192到255之间的二进制数。接下来，从第三位开始，提供长度信息，第三位是0表示这个符号是2字节的，第三位开始每多一个1，字符占用的 bytes 数加一。utf-8 最多定义到了 6 字节字符，需要比 110xxxxx 这样的表示2字节的starter多 4 个 1，所以这个starter就是 1111110x，如上表所示。
再看看英文定义的标准吧，表达的同样的意思：

The first byte of a multibyte sequence that represents a non-ASCII character is always in the range 0xC0 to 0xFD and it indicates how many bytes follow for this character. All further bytes in a multibyte sequence are in the range 0×80 to 0xBF. This allows easy resynchronization and makes the encoding stateless and robust against missing bytes.

真正的信息位（即，真正的charset字符集中的数字信息），是直接用二进制的方式，依顺序放在上面这个表的’x’上的。用我们中国程序员接触最多的汉字来说吧，它们的编码区间是在 U-00000800 - U-0000FFFF 之间的，从上面的表中可以查到，这个区间的 utf-8 编码是用三个字节来表示的（这就是 utf-8 编码的汉字会比每个字符占用2 bytes的 EUC-CN 编码的 gb2312 字符集的汉字使用更多储存空间的原因），还是用 口碑的”口”字举例吧，口字在 Unicode 中的编号是这样的：
口: 21475 == 0x53e3 ==  二进制 101001111100011

在 javascript 中，run这段代码（使用 firebug 的 console，或者编辑一个HTML将下列代码插入一对 script 标签之间）：

alert(‘\u53e3′);  //get ‘口’
alert(escape(‘口’));  // get ‘%u53E3′
alert(String.fromCharCode(’21475′));  // get ‘口’
alert(‘口’.charCodeAt(0));  // get ’21475‘
alert(encodeURI(‘口’));  //get ‘%E5%8F%A3′

可以看到，string直接量可以用\u+十六进制 Unicode 码的形式得到字符 ‘口’，而fromCharCode 方法接受 10 进制的 Unicode 码，得到字符 ‘口’。

其中第二个alert得到的是 ‘%u7545′ , 这是一种不标准的Unicode编码，是属于 URI 的 Percent encoding 一部分，但这种使用方法已经正式被 W3C 拒绝了，任何一个 RFC中都没有这个标准，ECMA-262 标准中规定了 escape 的这种行为，估计也是暂时的。
比较有意思的是第五次alert得到的 ‘%E5%8F%A3′ 这是什么呢？怎么得到的呢？

这就是在URI上用的比较多的 Percent encoding，百分号编码，RFC 3986 标准中规定的。

RFC 3986 规定，Percent encoding的非保留字如下：

Unreserved characters, per RFC 3986 (January 2005)
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 - _ . ~

也就是说，这些字出现在 URI 中的时候，不进行编码，因为他们和URI的格式没有关系，只是表示原义的字符

另外，保留字如下：

Reserved characters, per RFC 3986 (January 2005)
! * ‘ ( ) ; : @ & = + $ , / ? % # [ ]

这些字符，是有特殊意义的，如果在不代表那些特殊意义而代表原意的时候出现，必须经过编码，如下：

Reserved characters after percent-encoding
! * ‘ ( ) ; : @ & = + $ , / ? % # [ ]
%21 %2A %27 %28 %29 %3B %3A %40 %26 %3D %2B %24 %2C %2F %3F %25 %23 %5B %5D

而 % 号后面就是一个2位的十六进制数，这个数，就是 Unicode 的 UTF-8 编码的另一种表现形式。

让我们详细还原一下’口’ 字为什么是 ‘%E5%8F%A3′ 吧。

刚才我们谈到 ‘口’ 的 Unicode 编码 21475 的二进制形式是：
101001111100011

刚才我们又聊到，对于一个的汉字，它的UTF-8编码的形式是：
U-00000800 - U-0000FFFF:    1110xxxx 10xxxxxx 10xxxxxx

现在我们做个填空题，把 ‘口’ 二进制码切开填进去替换掉 x:
101001111100011 = ―-0101 -001111 -100011
101001111100011 = 1110xxxx 10xxxxxx 10xxxxxx
第一个字节少一位，左边加个0补齐，得到：
11100101 10001111 10100011

让我们把这三个二进制数转换成16进制，并且加上百分号，运行如下javascript代码：

alert(
‘%’ + parseInt(’11100101′, 2).toString(16) +
‘%’ + parseInt(’10001111′, 2).toString(16) +
‘%’ + parseInt(’10100011′, 2).toString(16)
)  // get ‘%e5%8f%a3′

怎么样，得到 %e5%8f%a3 了吧。

另外javascript的内置函数 encodeURI、decodeURI、encodeURIComponent、decodeURIComponent 就是进行的 Percent Encode，只是在对待 : / ; ?等特殊字符的时候有区别。

另外，再介绍一下 HTML 中的 Numeric character reference, NCR编码
相信大家都知道，HTML中的特殊字符是需要编码的，比如 & 需要被编码为： &  还有 ® 这样的特殊字符。其实HTML也是可以利用 Unicode 编码来显示任何一个字符的，编辑一个如下的html文件：

<html>
<body>
&#21475;
&#021475;
&#x53e3;
</body>
</html>

结果就是三个“口”字。

还有一种常用的编码是 base64 编码，base64编码本来是为了在 email 这样的非纯 8-bit 的传输层传输二进制数据而设计出来的，这样就可以在 email 中传递二进制的附件。它用 a-z A-Z 0-9 +/= 这64个字符来表示原有的数据，并且将连续的三个字符编码为四个，长度增加33%。
这个编码方式在一些比较超前的 javascript 应用中比较常用，这就是 RFC 2397 规定的 data URIs 协议，Firefox 浏览器支持，IE8也开始部分支持了，利用 data URIs 和 base64 编码，我们可以不借助任何外来的音乐、图像等多媒体文件而创造出丰富的效果。

建议继续学习：

1. 字符编码和中文乱码小叙    (阅读：5604)
2. 中文编码杂谈    (阅读：4930)
3. Hadoop的map/reduce作业输入非UTF-8编码数据的处理原理    (阅读：4596)
4. PHP编码规范    (阅读：4339)
5. base64_encode 和 urlencode    (阅读：4071)
6. UTF-8编码中BOM的检测与删除    (阅读：4020)
7. Linux screen窗口中文乱码问题    (阅读：3941)
8. Unicode与字符汉字相互转换    (阅读：3881)
9. python-django的中文编码总结    (阅读：3776)
10. 字符引用和空白字符    (阅读：3635)