目录前言：最近，在写关于字符编码和乱码的文章，想总结我目前遇到的所有乱码问题及其原因。这个问题是很早之前就遇到的，并且在网上一搜也可以轻易的获取解决问题的方法。但是，从没有人解释为什么会出现这个问题？提供的方法又是如何解决问题的？因此，想写一篇文章介绍下这部分内容，授人以渔，不如授人以鱼。
- 一、问题发生
- 二、问题解决
- 三、问题分析
-
- 1. 虚拟机写出字符到输出源发生了哪些事
- 2. 上文提及的解决方案的原理
- 3. (其他解决方法)修改命令行窗口的字符编码规则
-
- (1) 临时修改
- (2)永久配置
在cmd命令行窗口运行命令： startup.bat，会重新打开一个命令行窗口打印输出tomcat启动、运行过程中的日志信息。
可以看到命令行窗口的中文发生乱码，而引人注目的文字就是”淇℃伅，在真正表示的字符是”信息“二字。
编辑 %CATALINA_HOME%/conf/logging.properties 文件（注：%CATALINA_HOME%指的是tomcat软件的根目录）
将字符编码从“UTF-8”修改为“GBK”，如下所示
java.util.logging.ConsoleHandler.encoding = GBK
修改后重新启动，结果如下图所示：
至此，问题已经解决。
另外，三、问题分析的第3小节还提供了其他两种解决该问题的方法，可以直接移步至【三、问题分析~3. (其他解决方法)修改命令行窗口的字符编码规则】进行查看
三、问题分析这部分会介绍问题发生的根本原因，可能不太容易理解，需要对字符编码及解码和编码有一些了解并且有一定的Java SE知识才能更好的理解本部分内容。可以参考【字符编码及乱码】，建议看下，有利于理解本文
（如果对这部分内容不感兴趣，其实可以略过，没有关系。不影响正常学习和项目开发。但是，如果你想了解乱码的原理，我非常支持你继续看下去。这对于解决你以后可能在其他地方遇到乱码问题，也是有帮助的。）
1. 虚拟机写出字符到输出源发生了哪些事第一点：无论Java源文件的字符编码是什么，编译后的字节码文件都是使用UTF-8编码字符（源代码字符串中的字符）。
例如：编码为GBK的GBK.java源文件
编码为UTF-8的UTF8.java源文件
在命令行窗口编译上述文件，源文件是什么编码，就指定使用什么编码解码文件，否则可能出现"GBK不可映射字符"的错误。
查看二者十六进制的class文件
使用工具【汉字字符集编码】查询到，“E4BFA1E681AF”（UTF-8的编码）表示的文字是“信息”。
到此，证明了不管源文件是什么编码，其中的字符在编译后的class文件中是以UTF-8编码表示的。
那么现在问题来了，Windows平台的命令行窗口使用的默认字符编码是GBK（当然，这是因为我所在区域是中国决定的），class文件中的字符编码是UTF-8，为什么运行程序后不乱码呢？
tomcat程序的class文件也是以UTF-8表示（保存）文字的啊，但是它为什么乱码呢？那么，就要讲解编码和解码的过程了。
对于System.out.println(“信息”);代码，虚拟机在运行的时候，
-
把底层的UTF-8编码的字符，解码为Unicode字符；
-
依据你指定的编码规则将字符重新编码； 例如：可以通过-Dfile.encoding=GBK指定解码使用的编码规则为GBK，这是一般方式，具体软件可能有其他方式
-
通过输出流把重新编码的字节序列写入到你指定的输出源（文件、标准输出、网络等等）；例如new FileOutputStream()是节点流，代表文件（输出源）、System.out本质是PrintStream类是处理流，它的底层绑定了标准输出（输出源），标准输出默认是屏幕的命令行窗口，当然也可重定向到文件
-
编辑器使用你指定的编码打开文件并显示（或者说解码）字符，命令行窗口使用你指定的编码显示（或者说解码）字符。
Java虚拟机写出到输出源的字符都会经过编码器的编码（即将字符编码为字节序列），如果解码输出源中字符使用的编码规则与编码时一致或者兼容，就不会发生乱码；反之，则产生乱码。
解决Java中的大部分乱码问题，关注第二步和第四步，即编码和解码就好了。
2. 上文提及的解决方案的原理回顾一下上文提及的tomcat命令行乱码的解决方法，将“java.util.logging.ConsoleHandler.encoding”的字符编码从“UTF-8”修改为GBK。其发挥作用是在第二步，也就是编码阶段。
我们先假设解码器使用UTF-8编码字符，后使用GBK解码字符。由于编码、解码不一致或者不兼容发生乱码。java.util.logging.ConsoleHandler.encoding原来为UTF-8，则使用UTF-8编码字符，但是命令行窗口默认使用GBK解码，因此，把java.util.logging.ConsoleHandler.encoding改为GBK，使得编码、解码一致就解决了。
等等，你似乎也发现了吧，编码，解码一致就不会乱码了。那为什么不把命令行窗口解码使用的规则改为UTF-8呢？这样也一致呀，java.util.logging.ConsoleHandler.encoding是UTF-8，也就不用修改了。没错，没错，接下来就要将第二种解决乱码的方式了。其发挥作用是在第四部，即解码阶段。
先介绍下tomcat的启动和停止命令
startup.bat 启动
shutdown.bat 关闭
等价于
catalina start
catalina stop
还有一个canalina run，它和catalina start 的区别是，前者启动tomcat后，会在当前窗口继续打印输出日志信息，不会重新打开一个新窗口。因为报错后不会关闭窗口，可以查看出错的信息。Ctrl + C关闭服务器。
另外，还要了解一个，我个人感觉很实用的CMD命令chcp (change code page) 可以临时改变窗口的字符编码。
代码页编号就像字符编码的ID一样。点击查看windwos支持的所有代码页编号
我列举几个常用的代码页编号：
编号
字符编码
936
GBK
65001
UTF-9
28591
iso-8859-1或 latin1
有了上面的知识就可以，就可以临时修改命令行窗口的字符编码了。缺点，每次打开都需要重新设置命令行窗口编码，好处是可以解决乱码并且出错时能查看报错信息。
(2)永久配置- win + R，输入regedit
- 找到位置：计算机HKEY_CURRENT_USERConsole
如果没有tomcat就添加名为tomcat的项
3. 添加32位值，命名为“CodePage"
4.添加数据
5.测试
在命令行窗口输入startup.bat或者catalina start
先自我介绍一下，小编13年上师交大毕业，曾经在小公司待过，去过华为OPPO等大厂，18年进入阿里，直到现在。深知大多数初中级java工程师，想要升技能，往往是需要自己摸索成长或是报班学习，但对于培训机构动则近万元的学费，着实压力不小。自己不成体系的自学效率很低又漫长，而且容易碰到天花板技术停止不前。因此我收集了一份《java开发全套学习资料》送给大家，初衷也很简单，就是希望帮助到想自学又不知道该从何学起的朋友，同时减轻大家的负担。添加下方名片，即可获取全套学习资料哦
