相信大家在日常生活中，都见过类似下面的这些类似的字符串：
上面这种，看起来不明所以的内容，通常被称作乱码。那么乱码是如何产生的，并且如何修复呢？我们接下来就一步步对此进行解释
编码规则
字符串，本质上都是一个字节一个字节的数据，连在一起存储的。而要将这些数据显示在屏幕上，则需要按一种编码规则进行解析。
ASCII
ASCII编码是最容易理解的。ASCII编码因为每个字符仅占用7bit，所以最多只能存储127个字符，而每个字符都有唯一的一个数字与其对应。
例如：
数字0x35在这种编码规则下，会被解析为字符5
数字0x6C在这种编码规则下，会被解析为字符l
数字0x4C在这种编码规则下，会被解析为字符L
具体对应规则，可以在网上搜索ASCII码表查看
按照这种规则，一串hello，用16进制数据表示就是68656C6C6F
GB2312
因为ASCII只能显示127个字符，远远不能满足中文字符的显示需求，所以中国国家标准总局于1980年发布了国家标准代码GB2312标准（目前最新标准为GB18030）
简单来说，在这套编码规范下，每个中文字符可以由2个字节表示，例如：
啊的实际数据为0xB00xA1
测的实际数据为0xB20xE2
试的实际数据为0xCA0xD4
同时，因为ASCII编码下每字节使用了7bit（0x00-0x7f）,GB2312为了对其进行兼容，规定每个中文字符的高位字节（第一个字节）使用0xA1–0xF7的范围，避开了ASCII编码使用的区域。
也就是说，想下面的一串混用了中英文的数据，也可以正常被解析并显示出来：
UTF-8
UTF-8可以使用1-4字节来表示字符，因为其兼容性强，可以对Unicode字符集中的所有有效编码点进行编码，是目前使用最广泛的编码标准。
与GB2312一样，UTF-8同样兼容ASCII编码。只是UTF-8比GB2312包含了更多字符，并且每种字符的字节数并不是完全固定的。由于编码规则比较复杂，这里不作具体解释，只会举例说明：
啊的实际数据为0xE50x950x8A
测的实际数据为0xE60xB50x8B
试的实际数据为0xE80xAF0x95
其他编码
除了GB2312、UTF-8和ASCII编码，还有许多编码标准，他们大部分互不兼容。
存储和传输字符串数据
数据都是要进行存储和传输的
存储
微软使用BOM头这种技术来为纯文本文件标记其编码，这样打开文件时就可以用正确的编码进行解析。
而大部分Linux不使用类似技术，所以读取后只能靠猜测，或强行指定，来进行显示。
传输
传输不仅指字符串数据在互联网上的传输，也包括了在各类函数调用过程中的传输。这类操作通常都不会带有字符编码标准的标记，一般靠直接指定编码来解决。
产生乱码
聪明的你应该已经想到了，如果一串某编码的数据，被人使用另一种编码标准进行解析，那么得出的结果几乎一定是错误的。
比如测试解析结果这几个字，我们使用UTF-8编码，得到下面16进制数据：
如果，收到这些数据的人尝试使用GB2312编码来显示，那么结果就是我们非常熟悉的乱码了：
上面的过程就是典型的乱码形成过程
修复乱码
乱码是否可以还原？答案是肯定的，只需要按乱码形成时的操作反过来做一遍就可以恢复了。但是有些编码中会出现?这种无法解析显示的数据，这部分数据就完全丢失了。
一般的乱码修复操作，就是把各种编码可能性都试一遍，看哪个结果可靠，那么就是原始内容。
这里推荐使用开源的工具llcom(llcom.papapoi.com)，来进行乱码恢复工作
我们用上一节生成的乱码数据作为例子，尝试修复：
可以看到可靠的结果已经显示出来，修复成功
避免乱码
建议在写代码时统一使用UTF-8编码，这是目前互联网的最主要的编码形式
如果是资源占用紧张，但依旧需要中文显示的地方，可以考虑使用GB2312编码存储数据