字符编码介绍及常见问题总结

2017-11-29 本文已影响39人勤劳的小叶

ASCII编码: 是这三种编码中最原始的编码方式，即采用一个字节（8位二进制位）对字符进行编码。低7位二进制位进行编码，第8位通常为0，十进制可以表示为0_{128，十六进制为0x00}0x8F。因此ASCII可以标识128个常用字符，其中有 96 个可打印字符，包括常用的字母、数字、标点符号等，另外还有 32 个控制字符。
ANSI编码: 是各个国家对ASCII的扩充，它根据用户所使用的系统的不同而不同，如在中文操作系统下，字符编码为GB2312编码，而在日文操作系统下，则是ANSI 编码代表 JIS 编码等。
因此也会出现一个问题：如果在中文系统中保存为ANSI编码，那么在日文操作系统中，直接打开就会出现乱码，因为此时日文系统的ANSI编码代表的是JIS编码，而保存的编码格式是GB2312编码。
Unicode编码: 上述中的ANSI编码方式得到的字符编码，由于其编码规范都具有区域性，因此，可能会出现，同一个字符使用不同编码方式时，出现不同编码值；同一个编码值在不同的编码方式中，代表的字符也不同。因此Unicode编码出现了，它统一了字符编码规范，使得字符和编码值实现一一对应的关系。

2. Unicode与UTF-8，UTF-16之间的关系

UTF-8，UTF-16出现的原因

根据上面提到的Unicode已经满足了人们的同意编码的要求，但是为什么还会出现UTF-8和UTF-16这两种编码方式呢？

主要原因：直接使用Unicode编码的效率不高，比如UCS-4(Unicode的标准之一)规定用4个字节存储一个符号，那么每个英文字母前都必然有三个字节是0，这对存储和传输来说都很耗资源。

因此，UTF-8和UTF-16对于Unicode来说，就是提供了额外的编码方式。用特定的编码规则来解决Unicode编码的效率问题。

UTF-8，UTF-16如何解决效率问题

UTF-8不同字符对应编码值

由上图可知，一个英文字符占用1个字节，一个中文字符占用3个字节，一个表情（特殊字符）占用四个字节。

可以看出，UTF-8根据不同的字符类型，采用不同的字节进行存储，相对有上面提到的UCS-4来说，对任意字符都采用4字节存储，会更加的高效。

对于UTF-16编码，在U+0000 - U+FFFF范围类，都固定是使用2个字节进行存储，因此不管是中文还是因为字符，都是用两个字节。

UTF-8，UTF-16转换规则

UTF-8 
U+ 0000 ~ U+ 007F: 0XXXXXXX
U+ 0080 ~ U+ 07FF: 110XXXXX 10XXXXXX 
U+ 0800 ~ U+ FFFF: 1110XXXX 10XXXXXX 10XXXXXX 
U+10000 ~ U+10FFFF: 11110XXX 10XXXXXX 10XXXXXX 10XXXXXX

UTF-16 
U+0000 - U+FFFF         xxxxxxxx xxxxxxxx
U+10000 - U+10FFFF   110110xx xxxxxxxx 110111xx xxxxxxxx

如，‘我’的Unicode编码为6211，如果采用UTF-8编码，该编码落在U+ 0800 ~ U+ FFFF范围内，因此其转换方式为

Unicode转化为UTF-8

UTF-8，UTF-16使用场景

UTF-8是目前互联网上最常用的一种编码格式。
UTF-8的优势在于，其英文字符只需要1个字节来表示，但是中文字符却需要3个字节。
UTF-16的优势在于，其中文字符只需要2个字节来表示，但是英文字符也需要2个字节。

因此，如果文本中，主要是中文字符，则使用UTF-16；主要使用英文字符，则使用UTF-8。当然也要适当考虑第一条，即通用性。

3. 字符编码常见问题

乱码问题

正常情况下，主要由于文本的编码方面出现问题：

使用ANSI编码进行存储
如上面提到的，在不同语言的操作系统中，打开使用ANSI编码保存的文本时，就会出现保存和打开时的编码方式不一致，如果在中文系统中保存为ANSI编码，那么在日文操作系统中，直接打开就会出现乱码，因为此时日文系统的ANSI编码代表的是JIS编码，而保存的编码格式是GB2312编码。
本地编辑器设置打开的编码方式不正确
每个文本编辑器中都可以设置文本的编码格式。如sublime中文本文件默认的编码格式即为‘utf-8’，如果文本保存的格式为GBK，使用sublime打开时，默认使用uft-8格式，这就导致中文出现乱码。

sublime中设置默认编码格式

在sublime中，默认不会显示文本的字符编码，需要手动修改配置文件，菜单Perference → Settings – User，修改用户配置，覆盖默认配置。

sulime中默认不展示编码格式

在用户配置中进行配置

最终显示效果

windows中文件文件编辑器的问题

千万不要使用Windows自带的记事本编辑任何文本文件。原因是Microsoft开发记事本的团队使用了一个非常弱智的行为来保存UTF-8编码的文件，他们自作聪明地在 每个文件开头添加了0xefbbbf（十六进制）的字符，你会遇到很多不可思议的问题，比如，网页第一行可能会显示一个“?”，明明正确的程序一编译就报语法错误，等等，都是由记事本的弱智行为带来的。建议你下载Notepad++代替记事本，不但功能强大，而且免费！记得把Notepad++的默认编码设置为UTF-8 without BOM即可。

网络传输中文件字符编码问题

下面针对一个最简单的HTML文件进行讲解：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="gbk">
    <title>Document</title>
</head>
<body>
    welcome to Beijing! 欢迎来到北京！😊😊😊
</body>
</html>

http.createServer(function(req, res) {
    let content = fs.readFileSync('./test.html', 'utf-8');
    res.setHeader('Content-Type', 'text/html;')
    res.write(content);

    res.end();
})

此时，如果我们使用utf-8编码保存HTML文件，然后我们在服务器中，使用utf-8编码形式读取文件。但是此时，我们访问服务器，获取的html页面却得到了乱码。

访问页面出现乱码

这是为什么呢？

仔细观察，页面头部的meta标签。

<meta charset="gbk">

这个标签，告诉浏览器，这个html字符编码是gbk编码，因此浏览器就会使用gbk编码的方式识别字符，因此会出现乱码。

但是，如果你在响应头中，设置charset=utf-8'，则可以解决这个问题。

res.setHeader('Content-Type', 'text/html;charset=utf-8')

此时，浏览器就会忽略<meta charset="gbk">标签，使用响应头中标识的字符集，浏览器页面也会正常展示。

页面正常展示

4. 相关资料链接