开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> Java知识库 -> tomcat命令行下启动中文乱码(解释原理版) -> 正文阅读

[Java知识库]tomcat命令行下启动中文乱码(解释原理版)

前言：最近，在写关于字符编码和乱码的文章，想总结我目前遇到的所有乱码问题及其原因。这个问题是很早之前就遇到的，并且在网上一搜也可以轻易的获取解决问题的方法。但是，从没有人解释为什么会出现这个问题？提供的方法又是如何解决问题的？因此，想写一篇文章介绍下这部分内容，授人以渔，不如授人以鱼。

一、问题发生

在cmd命令行窗口运行命令： startup.bat，会重新打开一个命令行窗口打印输出tomcat启动、运行过程中的日志信息。

在这里插入图片描述
可以看到命令行窗口的中文发生乱码，而引人注目的文字就是”淇℃伅，在真正表示的字符是”信息“二字。

二、问题解决

编辑 %CATALINA_HOME%/conf/logging.properties 文件（注：%CATALINA_HOME%指的是tomcat软件的根目录）

在这里插入图片描述

将字符编码从“UTF-8”修改为“GBK”，如下所示

java.util.logging.ConsoleHandler.encoding = GBK

修改后重新启动，结果如下图所示：
在这里插入图片描述

至此，问题已经解决。

三、问题分析

这部分会介绍问题发生的根本原因，可能不太容易理解，需要对字符编码及解码和编码有一些了解并且有一定的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，也就不用修改了。没错，没错，接下来就要将第二种解决乱码的方式了。其发挥作用是在第四部，即解码阶段。