> 知其然，知其所以然，彻底搞懂编码，搞定乱码
乱码问题是所有运维职业生涯中都会遇到的问题，本篇文章带你探究背后的原理以及解决的技巧
## 字符编码
我们知道计算机只认识二进制数据，其他格式的数据都需要转换成二进制才能被计算机处理，也就是说我们在计算机上看到的文本、视频、可执行程序等格式的文件，最终都会转换成二进制数据交给计算机处理
计算机中最小的数据单位是bit，也叫二进制位，每一个bit都有0和1两种状态，最早的计算机在设计时采用了8个bit作为一个字节byte，所以一个字节能表示的最大整数就是二进制的`11111111`，等于十进制的`255`，想要表示更大的整数就必须要用多个字节，例如两个字节可以表示最大的整数就是二进制的`1111111111111111`，等于十进制的`65535`
由于计算机是由美国人发明的，在1967年美国人制订了一套字符编码规范，规定了包含大小写字母、数字和一些符号共计128个字符与二进制数字的对应关系，例如回车Enter是二进制是`00001101`，等于十进制的13，大写字母A是二进制`01000001`，等于十进制的65，这一套字符编码被称为**ASCII**码，一直沿用至今
英文比较简单，用128个符号编码就够了，但是用来表示中文就不够了，单单汉字就有超过8万个，所以就有了针对中文的编码标准出现，例如我们经常见到的`GB2312`，使用两个字节表示一个汉字，理论上最多可以表示65535个
世界上有上百种语言，每种语言都有自己的编码标准，例如韩文编码`EUC_KR`，日文编码`Shift_JIS`，俄文编码`KOI8-R`，为了促进互联网的发展，**Unicode**编码应运而生，Unicode编码又称万国码、国际码，它对世界上大部分的文字系统进行了整理，使每一个文字符号都有独一无二的编码表示，当前Unicode最新的版本为2019年5月公布的`12.1.0`，已经收录超过13万个字符，很明显2个字节已经无法保证所有字符都独一无二了，实际上最新的Unicode规定可以占用4字节来表示一个字符，理论上最多能表示2的31次方共计2147483648个字符
Unicode虽然能够解决不同编码出现的问题，使得电脑可以用更为简单的方式来呈现和处理文字，但同时存在着浪费存储和带宽的问题，例如大写字母A，用ASCII码表示是`01000001`，只需要占一个字节，如果转换成2个字节的Unicode编码就变成了`0000000001000001`，这就极大的浪费了存储空间，同时对于网络传输消耗也相应增大
为了解决Unicode的问题，**UTF-8**编码方式出现了，UTF-8是一种可变长的编码方式，它通过前缀码的方式使Unicode编码变成了可变长度，关于UTF-8的具体前缀规则简单总结为2点如下：
1. 单字节的字符，字节的第一位设为0，后边7位为Unicode码。对于英语字母，UTF-8编码和ASCII码完全相同
2. n个字节的字符(n>1)，第一个字节的前n位设为1，第n+1位设为0，后面字节的前两位都设为10，这n个字节的其余空位填充该字符unicode码，不足用0补足
那就形成了如下的UTF-8编码规则，其中的`x`表示的就是要用Unicode填充可用的编码位
Unicode符号范围（16进制） | UTF-8编码方式（2进制）
--- | ---
0000 0000 - 0000 007F | 0xxxxxxx
0000 0080 - 0000 07FF | 110xxxxx 10xxxxxx
0000 0800 - 0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
0001 0000 - 0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
对于运维咖啡吧的`咖`字，其Unicode编码为`U+5496`，`5496`在上边的第三行`0000 0800 - 0000 FFFF`的范围内，因此带入公式计算如下
```
0101 010010 010110 (最前边的0便是unicode不足，用0代替)
1110xxxx 10xxxxxx 10xxxxxx (模板，由于3字节，所以是上边第三行)
------------------------------------------------------------------
11100101 10010010 10010110 (结果，UTF-8的二进制值)
```
根据上边的计算结果得出运维咖啡吧的`咖`字UTF-8编码是`111001011001001010010110`，转换为16进制为`E59296`
这便是Unicode与UTF-8的区别，UTF-8可变长就是这么可变长的，对于英文字母来说UTF-8只占一个字节，而对于汉字来说他可能就占了3个字节
## 终端乱码
从上边的编码介绍中我们已经知道了不同编码的存在，那么想要查看一个文件，就必须知道他的编码方式，用错误的编码方式打开文件就会出现乱码。
linux下可以通过`file`命令查看文件的编码方式
```
# file ops-coffee.cn
ops-coffee.cn: UTF-8 Unicode text
```
工作中我们在XSHELL之类的终端中查看文件时出现的乱码就是系统或文件保存的中文编码与终端设置的编码不一致，从而导致解码错误。这里涉及到三方编码：
1. 文件内容或文件名
2. SHELL环境的语言编码
3. XSHELL之类的终端编码
需要保持三方编码统一，才不会有乱码的出现，其中SHELL环境的语言编码指的是登陆服务器的SHELL环境时指定的语言编码，例如`LANG`、`LC_*`这些变量设置的编码，XSHELL之类终端编码就是这类终端软件设置的编码
所有遇到的乱码问题都仔细检查以上**三方编码**是否一致，就可以顺利解决了，同时也建议在工作中制定相应的规范，减少乱码的发生
## 处理技巧
1.临时切换命令输出语言
正常情况下命令的输出结果都遵循系统设置的语言编码，例如
```
root@ops-coffee:~# echo $LANG
zh_CN.UTF-8
root@ops-coffee:~# date
2020年 03月 04日 星期三 19:00:55 HKT
root@ops-coffee:~#
root@ops-coffee:~#
root@ops-coffee:~# export LANG=en_US.UTF-8
root@ops-coffee:~# echo $LANG
en_US.UTF-8
root@ops-coffee:~# date
Wed Mar 4 19:01:21 HKT 2020
```
运维脚本中，我们希望所有系统执行相同命令的时候输出的结果一致，不要因为字符集不同而产生不同的结果，那么如可处理呢？在命令前添加`LC_ALL=C`
```
root@ops-coffee:~# date
2020年 03月 04日 星期三 19:05:58 HKT
root@ops-coffee:~#
root@ops-coffee:~# LC_ALL=C date
Wed Mar 4 19:06:05 HKT 2020
```
这里之所以用`LC_ALL`是因为在LOCALE标准中，`LC_ALL`优先级最高：`LC_ALL>LC_*>LANG`
2.批量转换文件名编码
有时候我们会遇到文件名或者目录名乱码的问题，尤其是在不同类型系统之间传输时，可以借助`rsync`实现批量转换文件名或目录名的编码
```
rsync -av --iconv=GBK,UTF8 /www/ /nav/
```
iconv模块在rsync的3.0以后版本中才支持，用法为`--iconv=
