事情起源于项目另一开发者在中文Windows下构建时遇到的部分中文出现乱码问题.

当时很不解的是, 为什么会只有部分出现乱码. 第一感觉是, 如果编码转换不正确, 要么全乱码, 要么全正确. 为何会”部分”出现乱码.

初步分析在此. 简单说, 就是在转码过程中, Java会把某些它不认识的部分直接用某个值代替. 至于为何不默认保留原数据, 是个好的考古研究课题.

示例如下(除了”开始检”, 其他都乱码了):

编码 原字1 原字2 原字3 原字4 原字5 原字6
原字 开 始 检 查 … …
UTF8表示 e5 bc 80 e5 a7 8b e6 a3 80 e6 9f a5 e2 80 a6 e2 80 a6
转为GBK后 e5 bc 3f e5 a7 8b e6 a3 80 e6 9f a5 e2 3f a6 e2 3f 3f
转回UTF8 �? 开 始 检 �?� �??

网上很多资源提到字符数是奇数会有问题, 这是没错. 但实际上即使偶数也可能会有问题. 上面的转换过程中, 80不是合法GBK字符, 就被替换成3f. 而替换过后再转回UTF8当然就挂了.

这个问题里的插件就是把输出字符串指定编码成了UTF8格式的数据, 但输出/解码时又用了系统默认的编码格式(GBK). 详见 GBK<->UTF8 互转问题: Maven checkstyle输出乱码 · Issue #26 · program-in-chinese/overview, zh-cn ,,,, cmd gbk encode · Issue #3569 · checkstyle/checkstyle.

个人觉得这种转码问题是除了亚洲/非洲之外的开发者很容易忽视的. UTF8的字符除了亚洲(包括中日韩)和非洲语言的字符用三字节数据表示外, 其他多数语言的字符都是用单字节或双字节. 来源). 这些UTF8中三字节的字符和GBK之类的双字节码转码时会更容易出问题.

在调查过程中, 还发现了其他一些类似疑问, 比如UTF-8编码，部分中文正常，部分为乱码的问题？-CSDN论坛.

直觉是也是类似问题, 但想用编码互转的方式重现未果, 参考上面的例子试了几种2次转码, 都没有重现. JDBC连接MySQL抛出异常信息乱码 - insist的专栏 - CSDN博客提到了CP1252编码, 又经过几次尝试, 才试出了这个过程: “utf-8”->”windows-1252”->”iso-8859-1”->”utf-8”.

阶段总结一下, 乱码问题的缘由都是编码互转. 全部乱码, 部分乱码都可能. 随着国外代码库/软件的编码方式更多地使用UTF8, 类似第二个问题的可能会变少, 但类似第一个的UTF8<->GBK互转的问题也许会存在很长一段时间.