字符编码解惑

原创：打码日记（微信公众号ID：codelogs），欢迎分享，转载请保留出处。

简介

现代编程语言都抽象出了String字符串这个概念，注意它是一个高级抽象，但是计算机中实际表示信息时，都是用的字节，所以就需要一种机制，让字符串与字节之间可以相互转换，这种转换机制就是字符编码，如GBK，UTF-8

所以可以这样理解字符串与字符编码的关系:

1. 字符串是一种抽象，比如java中的String类，它在概念上是编码无关的，里面包含一串字符，你不需要关心它在内存中是用什么编码实现的，尽管字符串在内存中存储也是需要使用编码机制的。


2. 字节串才需要关心编码，当我们要将字符串保存到文件中或发送到网络上时，都需要使用字符编码机制，将字符串转换为字节串，因为计算机底层只认字节。

常见字符编码方案

ASCII

全称为American Standard Code for Information Interchange，美国信息交换标准代码，用来编码英文字符，一个字符占一个字节，只用了字节中的低7位，最高位始终为0，因此只能表示2^7=128个字符。

ISO8859-1

对ASCII的扩充，添加了西欧语言、希腊语、泰语、阿拉伯语、希伯来语对应的文字符号，也称latin-1，将ASCII中最高一位也利用起来了，能表示2^8=256个字符，当最高位是0时，编码方式就是ASCII，所以ISO8859-1是兼容ASCII码的。

GBK

全称为Chinese Internal Code Specification，于1995年制定，用来编码汉字的一种方案，一个汉字编码为两个字节，兼容ASCII码编码方案，ASCII中的英文字符编码为一个字节。

Unicode

Unicode 的全称是 universal character encoding，中文一般翻译为"统一码、万国码、单一码"，用于定义世界上所有的字符，避免了各个国家设计的本地字符集互相不兼容的问题。早期由于另一个组织也定义了一种与Unicode类似的方案ucs，而后与Unicode合并，故有时Unicode也称为ucs。

注意，Unicode是一种字符集，而不是一种具体的字符编码，要理解Unicode具体是什么，首先要理解字符集与字符编码的关系，一般来说，字符集定义字符与代码点(codepoint)之间的对应关系，而字符编码定义代码点(codepoint)与字节之间的对应关系。

比如ASCII字符集规定A用65表示，至于65在计算机中用什么字节表示，字符集并不关心，而ASCII字符编码定义65应该用一个字节表示，对应为01000001，十六进制表示法为0x41，它是ASCII字符集的一种实现，也是唯一的实现。

但Unicode做为一种字符集，它没有规定Unicode中的字符该如何编码为字节，而UTF-16、UTF-32、UTF-8就都是Unicode的字符编码实现方案，它们具体定义了如何将Unicode字符转换为相应的字节。

UTF-32

UTF-32编码，也称UCS-4，是Unicode 最直接的编码方式，用 4 个字节来表示 Unicode 字符中的 code point ，比如字母A对应的4个字节为0x00000041。它也是 UTF-*编码家族中唯一的一种定长编码（fixed-length encoding），定长编码的好处是能快速定位第N个字符，便于指针运算。但用四个字节来表示一个字符，对于英文字母来说，空间占用就太大了。

UTF-16

UTF-16编码，也称UCS-2，最少可以采用 2 个字节表示 code point，比如字母A对应的2个字节为0x0041。需要注意的是，UTF-16 是一种变长编码（variable-length encoding），只不过对于 65535 之内的 code point，只需要使用 2 个字节表示而已。但是，很多历史代码库在实现 UTF-16 编码时，直接使用2字节存储，这导致在处理超出 65535 之外的 code point 字符时，会出现一些问题，另外，UTF-16对于纯英文存储，也会浪费1倍存储空间。

字节序与BOM

不同的计算机存储字节的顺序是不一样的，比如 U+4E2D 在 UTF-16 可以保存为4E 2D，也可以保存成2D 4E，这取决于计算机是大端模式还是小端模式，UTF-32也类似。为了解决这个问题，UTF-32与UTF-16都引入了BOM机制，在文件的起始位置放置一个特殊字符BOM(U+FEFF)，如果 UTF-16 编码的文件以FF FE开始，那么就意味着其字节序为小端模式，如果以FE FF开始，那么就是大端模式。所以UTF-16根据大小端可区分为两种，UTF-16BE(大端)与UTF-16LE(小端)，UTF-32同理。

Unicode表示法

我们经常会看到形如 U+XXXX 或 \uXXXX 形式的东西，它是一种表示Unicode字符的方式，俗称Unicode表示法，其中XXXX是 code point 的十六进制表示，比如 U+0041 或 \u0041 表示Unicode中的字母A。咋一看，这玩意有点类似 UTF-16 ，但要注意它是一种用英文字符串指代一个Unicode字符的方式，不是一种字符编码，字符编码是用字节串指代一个Unicode字符。

UTF-8

由于UTF-16用两个字节编码英文字符，对于纯英文存储，对空间是一种极大的浪费，所以unix之父Ken Thompson又发明了一种Unicode字符编码——UTF-8，它对于ASCII范围内的字符，编码方式与ASCII完全一致，其它字符则采用2字节、3字节甚至4字节的方式存储，所以UTF-8是一种变长编码。对于常见的中文字符，UTF-8使用3字节存储。

包含关系图

乱码又是怎么回事？

乱码本质上是编码端程序与解码端程序用的字符编码不同导致的，比如一个程序(编码端)使用UTF-8存储字符串到文件中，另一个程序(解码端)读取时却用GBK解码，就会出现乱码了。

实践-java

String.getBytes()与new String(bytes)

String str = "好";
//字符串转字节，使用UTF-8
byte[] bytes = str.getBytes("UTF-8");
//'好'在UTF-8下编码为3字节e5a5bd
System.out.println(Hex.encodeHexString(bytes));
//字节转字符串，使用UTF-8
System.out.println(new String(bytes, "UTF-8"));
//字符串转字节，不传字符编码，默认使用操作系统的编码，我开发机是Windows，默认编码为GBK
bytes = str.getBytes();
//'好'在GBK下编码为2字节bac3
System.out.println(Hex.encodeHexString(bytes));
//字节转字符串，同样使用我当前操作系统默认编码GBK
System.out.println(new String(bytes));


对于java的String.getBytes()与new String(bytes)方法，是用来进行字符串与字节转换的，但建议最好使用带charset版本的方法，如String.getBytes("UTF-8")与new String(bytes,"UTF-8")，因为没有指定字符编码的方法，会默认使用操作系统上设置的编码，而Windows上默认编码经常是GBK，这就导致使用linux或mac开发的程序，运行得好好的，在Windows上却乱码了。

另外，像如下的InputStreamReader与OutputStreamWriter，也有带charset与不带charset版本的，最好也使用带charset版本的方法。

//InputStreamReader与OutputStreamWriter也一样，如果不指定字符编码，就使用操作系统的
InputStreamReader isr = new InputStreamReader(in, "UTF-8");
OutputStreamWriter osw = new OutputStreamWriter(out, "UTF-8");


另外，在启动java项目时，最好带上jvm参数-Dfile. encoding=utf-8，这样可以设置jvm默认编码为UTF-8，避免程序继承操作系统编码，也可以像下面这样，在项目启动的第一行，手动设置编码为UTF-8，这样没有设置jvm参数的同学也不会出现乱码了。

//设置当前jvm默认字符编码为UTF-8，避免继承操作系统编码
System.setProperty("file.encoding", "UTF-8");


实践-linux

od与xxd

od与xxd是查看字节数据的工具，可以以十六进制、八进制、二进制、十进制的方式查看字节，非常方便，如下：

#查看'好'的十六进制，如下'好'输出3个字节，可见echo使用了utf-8编码
$ echo -n 好|xxd
00000000: e5a5 bd
# -b选项表示输出01二进制形式
$ echo -n 好|xxd -b
00000000: 11100101 10100101 10111101
# od同样可以输出十六进制
$ echo -n 好|od -t x1
0000000 e5 a5 bd
# linux下查看ASCII码表
$ man ASCII
$ printf "%0.2X" {0..127}| xxd -r -ps | od -t x1d1c


iconv

iconv是用来转换字符编码的好工具，如下:

# iconv将echo输出的utf-8字节转换为gbk字节，可见中文的gbk编码为2字节
$ echo -n 好|iconv -f utf-8 -t gbk |xxd
00000000: bac3
# 转换为utf-16be，可见中文的utf-16编码一般是2字节
$ echo -n 好|iconv -f utf-8 -t utf-16be |xxd
00000000: 597d
# 转换为utf-32be，可见中文的utf-32编码是4字节，且一般前2个字节都是0
$ echo -n 好|iconv -f utf-8 -t utf-32be |xxd
00000000: 0000 597d


其它有用工具

# Unicode表示法转字符串
$ echo -e '\u597d'
好
# 字符串转Unicode表示法
$ echo -n '好' | iconv -f utf-8 -t ucs-2be | od -A n -t x2 --endian=big | sed 's/\x20/\\u/g'
\u597d
# 猜测文件编码
$ enca -L zh_CN -g -i file.txt
UTF-8
# 转换文件编码为UTF-8
$ enca -L zh_CN -c -x UTF-8 file.txt


mysql中的utf8mb4又是啥？

UTF-8作为Unicode的一种字符编码方案，本来是可以编码Unicode中的所有字符的，但早期mysql在实现utf-8时，实现时自行限制utf-8最多使用3个字节，也称utf8mb3，导致如今普遍出现的emoji表情无法存储，因为emoji表情要使用4个字节才能编码，这就导致mysql又推出了utf8mb4来弥补这个缺陷。

总结

彻底理解字符编码并不容易，主要是这个在计算机书籍上从来没有重点介绍过，而在自己刚开始工作时，经常遇到各种乱码问题，然后网上一通搜索胡乱设置来解决问题，但却一直没搞清楚为啥，直到自己摸熟iconv这个命令后，才真正理解清楚。

往期内容

真正理解可重复读事务隔离级别

Linux文本命令技巧(下)

Linux文本命令技巧(上)

原来awk真是神器啊

常用网络命令总结