Java编程中出现乱码的原因

乱码的原因

理解了编码，我们来看乱码。乱码有两种常见原因：一种比较简单，就是简单的解析错误；另外一种比较复杂，在错误解析的基础上进行了编码转换。我们分别介绍。

1.解析错误

看个简单的例子。一个法国人采用Windows-1252编码写了个文件，发送给了一个中国人，中国人使用GB18030来解析这个字符，看到的可能就是乱码。比如，法国人发送的是Pékin，Windows-1252的二进制（采用十六进制）是50E96B 696E，第二个字节E9对应é，其他都是ASCII码，中国人收到的也是这个二进制，但是他把它看成了GB18030编码，GB18030中E96B对应的是字符“閗”，于是他看到的就是“P閗in”，这看来就是一个乱码。

反之也是一样的，一个GB18030编码的文件如果被看作Windows-1252也是乱码。

这种情况下，之所以看起来是乱码，是因为看待或者说解析数据的方式错了。只要使用正确的编码方式进行解读就可以纠正了。很多文件编辑器，如EditPlus、NotePad++、UltraEdit都有切换查看编码方式的功能，浏览器也都有切换查看编码方式的功能，如Fire-fox，在菜单“查看”→“文字编码”中即可找到该功能。

切换查看编码的方式并没有改变数据的二进制本身，而只是改变了解析数据的方式，从而改变了数据看起来的样子，这与前面提到的编码转换正好相反。很多时候，做这样一个编码查看方式的切换就可以解决乱码的问题，但有的时候这样是不够的。

2.错误的解析和编码转换

如果怎么改变查看方式都不对，那很有可能就不仅仅是解析二进制的方式不对，而是文本在错误解析的基础上还进行了编码转换。我们举个例子来说明：

1）两个字“老马”，本来的编码格式是GB18030，编码（十六进制）是C0CF C2ED。

2）这个二进制形式被错误当成了Windows-1252编码，解读成了字符“ÀÏÂí”。

3）随后这个字符进行了编码转换，转换成了UTF-8编码，形式还是“ ÀÏÂí”，但二进制变成了C380C38F C382C3AD，每个字符两个字节。

4）这个时候再按照GB18030解析，字符就变成了乱码形式“脌脧脗铆”，而且这时无论怎么切换查看编码的方式，这个二进制看起来都是乱码。

这种情况是乱码产生的主要原因。

https://www.bilibili.com/video/BV16G4y1Q7Ub/?spm_id_from=333.999.0.0