关于编码你必须知道的知识和技巧

知其然，知其因此然，完全搞懂编码，搞定乱码

乱码问题是全部运维职业生涯中都会遇到的问题，本篇文章带你探究背后的原理以及解决的技巧

字符编码

咱们知道计算机只认识二进制数据，其余格式的数据都须要转换成二进制才能被计算机处理，也就是说咱们在计算机上看到的文本、视频、可执行程序等格式的文件，最终都会转换成二进制数据交给计算机处理

计算机中最小的数据单位是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=<LOCAL>,<REMOTE>，须要注意的是，本地两个目录之间同步时LOCAL表示的是源目录的文件名编码，经过网络同步时LOCAL表示本地编码

---

相关文章推荐阅读：

• Nginx的几个经常使用配置和技巧
• Redis删除特定前缀key的优雅实现