目录
- 了解字符编码
- Unicode与UTF-8，UTF-16之间的关系
- 字符编码常见问题
- 相关资料链接
1. 了解字符编码
字符编码，即其字面意，就是每一个字符都对应一个编码（根据规格不同，最终得到的编码结果也不同）。我们在日常使用中，经常接触到的字符编码有以下三种：ASCII，ANSI，Unicode。
ASCII编码: 是这三种编码中最原始的编码方式，即采用一个字节（8位二进制位）对字符进行编码。低7位二进制位进行编码，第8位通常为0，十进制可以表示为0128，十六进制为0x000x8F。因此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如何解决效率问题
由上图可知，一个英文字符占用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范围内，因此其转换方式为
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中，默认不会显示文本的字符编码，需要手动修改配置文件，菜单Perference → Settings – User，修改用户配置，覆盖默认配置。
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">标签，使用响应头中标识的字符集，浏览器页面也会正常展示。
