关于unicode:字符编码解惑

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

古代编程语言都形象出了 String 字符串这个概念，留神它是一个高级形象，然而计算机中理论示意信息时，都是用的字节，所以就须要一种机制，让字符串与字节之间能够互相转换，这种转换机制就是字符编码，如 GBK，UTF-8
所以能够这样了解字符串与字符编码的关系:

字符串是一种形象，比方 java 中的 String 类，它在概念上是编码无关的，外面蕴含一串字符，你不须要关怀它在内存中是用什么编码实现的，只管字符串在内存中存储也是须要应用编码机制的。
字节串才须要关怀编码，当咱们要将字符串保留到文件中或发送到网络上时，都须要应用字符编码机制，将字符串转换为字节串，因为计算机底层只认字节。

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

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

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

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 解码，就会呈现乱码了。

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");

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

UTF- 8 作为 Unicode 的一种字符编码方案，原本是能够编码 Unicode 中的所有字符的，但晚期 mysql 在实现 utf- 8 时，实现时自行限度 utf- 8 最多应用 3 个字节，也称 utf8mb3，导致现在广泛呈现的 emoji 表情无奈存储，因为 emoji 表情要应用 4 个字节能力编码，这就导致 mysql 又推出了 utf8mb4 来补救这个缺点。

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

真正了解可反复读事务隔离级别
Linux 文本命令技巧 (下)
Linux 文本命令技巧(上)
原来 awk 真是神器啊
罕用网络命令总结

关于unicode:字符编码解惑

简介

常见字符编码方案

ASCII

ISO8859-1

GBK

Unicode

乱码又是怎么回事？

实际 -java

实际 -linux

mysql 中的 utf8mb4 又是啥？

总结

往期内容