共计 4702 个字符,预计需要花费 12 分钟才能阅读完成。
原创:打码日记(微信公众号 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 这个命令后,才真正了解分明。
往期内容
真正了解可反复读事务隔离级别
Linux 文本命令技巧 (下)
Linux 文本命令技巧(上)
原来 awk 真是神器啊
罕用网络命令总结