原创:打码日记(微信公众号ID:codelogs),欢迎分享,转载请保留出处。
简介#
现代编程语言都抽象出了String字符串这个概念,注意它是一个高级抽象,但是计算机中实际表示信息时,都是用的字节,所以就需要一种机制,让字符串与字节之间可以相互转换,这种转换机制就是字符编码,如GBK
,UTF-8
所以可以这样理解字符串与字符编码的关系:
- 字符串是一种抽象,比如java中的String类,它在概念上是编码无关的,里面包含一串字符,你不需要关心它在内存中是用什么编码实现的,尽管字符串在内存中存储也是需要使用编码机制的。
- 字节串才需要关心编码,当我们要将字符串保存到文件中或发送到网络上时,都需要使用字符编码机制,将字符串转换为字节串,因为计算机底层只认字节。
常见字符编码方案#
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这个命令后,才真正理解清楚。