万字长文讲解编码知识，看这文就够了！（二）

（4）UTF-8

从前述内容可以看出：无论是UCS-2/4还是UTF-16/32，一个字符都需要多个字节来编码，这对那些英语国家来说多浪费带宽啊！（尤其在网速本来就不快的那个年代......），而且我们注意到UTF-16最少2字节和UTF-32不变4字节，这肯定是不兼容ASCII码的，由此，UTF-8产生了。

在UTF-8编码中，ASCII码中的字符还是ASCII码的值，只需要一个字节表示，其余的字符需要2字节、3字节或4字节来表示。

UTF-8的编码规则：

• 对于ASCII码中的符号，使用单字节编码，其编码值与ASCII值相同。其中ASCII值的范围为0~0x7F，所有编码的二进制值中第一位为0（这个正好可以用来区分单字节编码和多字节编码）。

• 其它字符用多个字节来编码（假设用N个字节），多字节编码需满足：第一个字节的前N位都为1，第N+1位为0，后面N-1 个字节的前两位都为10，这N个字节中其余位全部用来存储Unicode中的码位值。

现如今UTF-8 是互联网上使用最广的一种 Unicode 的实现方式，是其他两种无可比拟的。

（5）UTF的字节序和BOM

字节序就要先补充一点知识：

码元（code unit）：是能用于处理或交换编码文本的最小比特组合。它代表某种编码中最小的可用来识别一个合法字符的最小字节数序列。

• UTF-8使用变长的字节序列来表示字符；某个字符(对应一个码点)可能使用1-4个字节才能表示；在UTF-8中一个字符最小可能一个字节，所以我们规定1个字节就是一个码元；

• UTF-16使用也变长字节序列来表示字符；某个字符(对应一个码点)可能使用2个或者4个字符来表示；因为2个字节序列是最小的能够识别一个码点的单位，同理我们规定2个字节就是一个码元；

• UTF-32使用定长的4个字节表示一个字符；一个字符(对应一个码点)使用4个字符来表示，这样4个字节就是一个码元。

简单来说，就是“码点”经过映射后得到的二进制串的转换格式单位称之为“码元”。“码点”就是一串二进制数，“码元”就是切分这个二进制数的方法。这些编码每次处理一个码元，你可以把它理解为UTF-8每次读码点的8位，UTF-16每次读码点的16位，UTF-32每次读码点的32位,。当然这也是为什么叫这些叫Unicode转换格式的原因。处理的是同一个字符集，但是处理方式不同。

三

字节序

UTF-8一次一个UTF-8码元，即处理一个字节，没有字节序的问题。UTF-16一次处理一个UTF-16码元，对应两个字节，UTF-32一次一个UTF-32码元，对应处理四个字节，所以这就要考虑到一个字节序问题。

以UTF-16w为例，在解释一个UTF-16编码文本前，首先要弄清楚每个编码单元的字节序。例如收到一个“奎”的Unicode编码是594E，“乙”的Unicode编码是4E59。

如果我们收到UTF-16字节流“594E”，那么这是“奎”还是“乙”？这就考虑大小端问题，所以UTF-16编码包括三种：UTF-16BE（Big Endian），UTF-16LE（Little Endian）、UTF-16（类似的名称UCS-2BE和UCS-2LE用于显示UCS-2的版本。）

UTF-16BE和UTF-16LE好理解，直接指定了字节序（大小端），但是UTF-16怎么处理呢？

Unicode规范中推荐的标记字节顺序的方法是BOM。BOM不是“Bill Of Material”的BOM表，而是Byte Order Mark。BOM是一个有点小聪明的想法：

在UCS编码中有一个叫做"ZERO WIDTH NO-BREAKSPACE"的字符，它的编码是FEFF。而FFFE在UCS中是不存在的字符，所以不应该出现在实际传输中。UCS规范建议我们在传输字节流前，先传输字符"ZERO WIDTH NO-BREAK SPACE"。这样如果接收者收到FEFF，就表明这个字节流是Big-Endian的；如果收到FFFE，就表明这个字节流是Little-Endian的。

同样的类比，UTF-32也是这样的。有UTF-32BE、UTF-32LE、UTF-32。前面UTF-32BE和UTF-32LE直接指定了字节序（大小端），后面的UTF-32也是靠BOM。

UTF-8不需要BOM来表明字节顺序，但可以用BOM来表明编码方式。字符"ZERO WIDTH NO-BREAKSPACE"的UTF-8编码是EF BB BF（读者可以用我们前面介绍的编码方法验证一下）。所以如果接收者收到以EF BB BF开头的字节流，就知道这是UTF-8编码了。

Windows就是使用BOM来标记文本文件的编码方式的。它就建议所有的 Unicode 文件应该以 ZERO WIDTH NOBREAK SPACE（U+FEFF）字符开头。这作为一个“特征符”或“字节顺序标记（byte-ordermark，BOM）”来识别文件中使用的编码和字节顺序。所以用Windows自带的记事本将文件保存为UTF-8编码的时候，记事本会自动在文件开头插入BOM（虽然BOM对UTF-8来说并不是必须的）。

但也有一些系统或程序不支持BOM，因此带有BOM的Unicode文件有时会带来一些问题。比如JDK1.5以及之前的Reader都不能处理带有BOM的UTF-8编码的文件，解析这种格式的xml文件时，会抛出异常：Content is not allowed inprolog。

Linux/UNIX 并没有使用 BOM，因为它会破坏现有的 ASCII 文件的语法约定。所以一般我们不建议用Windows自带的记事本编辑UTF-8文件就是这样。

四

总结

1、简单地说：Unicode和UCS是字符集，不属于编码UTF-8、UTF-16、UTF-32等是针对Unicode字符集的编码，UCS-2和UCS-4是针对UCS字符集的编码（只是我们习惯把Unicode字符集编码简称为Unicode编码，把UCS字符集编码称为UCS编码）。

Unicode沿用UCS字符集，在UCS-2和UCS-4基础上提出的UTF-16、UTF-32。并发展了UTF-8，发展到现在，就密不可分了，大家基于UCS就把Uniocde维护好就行，发布标准大家统一。以往的UCS-2和UCS-4概念就默认作废了这样一个关系，整个他们的发展长话短说就是这样，懂了吗。

2、UTF-8、UTF-16、UTF-32、UCS-2、UCS-4对比：

由于历史方面的原因，你还会在不少地方看到把Unicode称为一种编码的情况，那是因为早期的2字节编码最初称为“ Unicode”，但现在称为“ UCS-2”，这种情况下的 Unicode 通常就是 UTF-16 或者是更早的 UCS-2 编码，只是被一直搞混了，在某些老软件上尤为常见。比如下面editplus里面文件编码设置。

以前的Windows电脑上的记事本（左边）显示的是Unicode，不过现在好像改了变成了UTF-16。

不过由于各种原因，必须承认，在不同的语境下，“Unicode”这个词有着不同的含义。

它可能指：

（1）Unicode 标准

（2）Unicode 字符集

（3）Unicode 的抽象编码（编号），也即码点、码位（code point）

（4）Unicode 的一个具体编码实现，通常即为变长的 UTF-16（16 或 32 位），又或者是更早期的定长 16 位的 UCS-2

所以像我一般有时候非要区分的话都是直接说全，Unicode 标准，Unicode 字符集，Unicode编码等等。

五

ANSI编码

为使计算机支持更多语言，通常使用0x800~xFF范围的2个字节来表示1个字符。比如：汉字‘中’ 在中文操作系统中，使用 [0xD6,0xD0]这两个字节存储。

不同的国家和地区制定了不同的标准，由此产生了 GB2312、GBK、GB18030、Big5、Shift_JIS 等各自的编码标准。这些使用多个字节来代表一个字符的各种语言延伸编码方式，称为 ANSI 编码。

在简体中文Windows操作系统中，ANSI 编码代表 GBK 编码；在繁体中文Windows操作系统中，ANSI编码代表Big5；在日文Windows操作系统中，ANSI 编码代表 Shift_JIS 编码。

不同 ANSI 编码之间互不兼容，当信息在国际间交流时，无法将属于两种语言的文字，存储在同一段 ANSI 编码的文本中。

在使用ANSI编码支持多语言阶段，每个字符使用一个字节或多个字节来表示（MBCS，Multi-Byte Character System），因此，这种方式存放的字符也被称作多字节字符。比如，“中文123” 在中文 Windows 95 内存中为7个字节，每个汉字占2个字节，每个英文和数字字符占1个字节。

在非 Unicode 环境下，由于不同国家和地区采用的字符集不一致，很可能出现无法正常显示所有字符的情况。微软公司使用了代码页（Codepage）转换表的技术来过渡性的部分解决这一问题，即通过指定的转换表将非Unicode 的字符编码转换为同一字符对应的系统内部使用的Unicode 编码。

可以在“语言与区域设置”中选择一个代码页作为非 Unicode 编码所采用的默认编码方式，如936为简体中文GBK，950为正体中文Big5（皆指PC上使用的）。在这种情况下，一些非英语的欧洲语言编写的软件和文档很可能出现乱码。而将代码页设置为相应语言中文处理又会出现问题，这一情况无法避免。

从根本上说，完全采用统一编码才是解决之道，虽然现在Unicode有了，但由于历史遗留，老软件等等原因，所以系统统一用某种编码格式的Unicode目前尚无法做到这一点。

代码页技术现在广泛为各种平台所采用。UTF-7 的代码页是65000，UTF-8的代码页是65001。简体中文上使用的代码页为936，GBK编码。

以前中文DOS、中文/日文Windows95/98时代系统内码使用的是ANSI编码（本地化，根据不同地区设置不同的系统内码Windows版本），现在win7，win10等等系统的内码都是用的Unicode。

不过微软为了以前的程序兼容性，比如在某些情况下，比如你的程序需要和不支持Unicode的程序交互时，可能还是会需要用到code page，提供代码页服务（就好比微软不能说：“老子支持unicode了，以后不支持Unicode的程序都给我滚粗。”只能撅着屁股让这些老掉牙的程序仍然可以运行，于是只好给他们提供一个“非Unicode默认字符集”） 。可以在cmd下输入chcp查看code page。

• WindowsAPI 的Wide Char 表达是 UTF-16: Unicode (Windows), L"" 表示是转换为 wide char。

• Cocoa的NSString 和 Core Foundation 的CFString 内部表达都是 UTF-16，所以其实 OSX 和 iOS 内部处理都用的是 UTF-16。

• JavaString 的内部表达是 UTF-16，所以大量跨平台程序和 Android 程序其实内部也在用 UTF-16。

• 大部分的操作系统和 UI framework 的内部字符串表达（内码）都是UTF-16，不过Linux系统内使用的内码是UTF-8。

六

Tip：内码和外码

在计算机科学及相关领域当中，内码指的是“将信息编码后，透过某种方式存储在特定记忆设备时，设备内部的编码形式”。在不同的系统中，会有不同的内码。

在以往的英文系统中，内码为ASCII。在繁体中文系统中，当前常用的内码为大五码。在简体中文系统中，内码则为国标码。

为了软件开发方便，如国际化与本地化，现在许多系统会使用Unicode做为内码，常见的操作系统Windows、Mac OS X、Linux皆如此。许多编程语言也采用Unicode为内码，如Java、Python3。

外码：除了内码，皆是外码。要注意的是，源代码编译产生的目标代码文件（如果Java可执行文件或class文件）中的编码方式属于外码。