一呜投、前言

編碼配置原則

1. 源碼文件用于項(xiàng)目組之間進(jìn)行版本控制, 一般用UTF-8

2. 日志文件可能會(huì)用于在各個(gè)平臺(tái)上查看, 一般用UTF-8

3. 控制臺(tái)編碼對(duì)接你的電腦系統(tǒng)編碼, 一般電腦默認(rèn)是GBK

   因?yàn)槲业碾娔X是Window10默認(rèn)編碼是GBK, 所以我控制臺(tái)配置主打GBK

我的編碼配置

1. IDEA中 idea64.exe.vmoptions 中的 -Dfile.encoding 和 -Dconsole.encoding 的相關(guān)配置全部去除掉, 使用系統(tǒng)默認(rèn)GBK即可.

   這個(gè)使用系統(tǒng)默認(rèn)即可, 沒(méi)必要一亂碼就改這個(gè), 你的亂碼往往不是這個(gè)原因.

   
   

2. Run/Debug Configurations 中的 -Dfile.encoding 全部去除掉, 使用系統(tǒng)默認(rèn)GBK即可.

這個(gè)地方和上面 idea64.exe.vmoptions配置的都是VM這個(gè)參數(shù), 這個(gè)比上面那個(gè)優(yōu)先級(jí)更高,和上面的原因一樣, JDK默認(rèn)的已經(jīng)很好了, 不需要配置這個(gè)

這個(gè)地方會(huì)影響到控制臺(tái)log日志, 以及文件日志編碼, 但是未必一定要配置為UTF-8編碼, 使用默認(rèn)即可, 具體原因下面會(huì)講

===========================注意============================

3. 在你的項(xiàng)目中加上一句下面的代碼, 看下打印的結(jié)果.

   System.out.println(System.getProperty("file.encoding"));
   

   • 如果此時(shí)打印的是GBK, 那么下面的控制臺(tái)默認(rèn)編碼就是GBK.
   • 如果此時(shí)打印的是UTF-8, 那么下面的控制臺(tái)默認(rèn)編碼就是UTF-8.

   之前使用IDEA2018, 2019的時(shí)候, 下面的結(jié)果應(yīng)該是GBK, 但是用2020的時(shí)候, 有時(shí)卻莫名其妙變成了UTF-8,

4. tomcat路徑下, \conf\logging.properties配置, 注意和控制臺(tái)有關(guān)的Handler:java.util.logging.ConsoleHandler.encoding 改為第3步file.encoding輸出的編碼, 其它和文件有關(guān)的Handler全部UTF-8

   ############################################################
   # Handler specific properties.
   # Describes specific configuration info for Handlers.
   ############################################################
   
   1catalina.org.apache.juli.AsyncFileHandler.level = FINE
   1catalina.org.apache.juli.AsyncFileHandler.directory = ${catalina.base}/logs
   1catalina.org.apache.juli.AsyncFileHandler.prefix = catalina.
   1catalina.org.apache.juli.AsyncFileHandler.encoding = UTF-8
   
   2localhost.org.apache.juli.AsyncFileHandler.level = FINE
   2localhost.org.apache.juli.AsyncFileHandler.directory = ${catalina.base}/logs
   2localhost.org.apache.juli.AsyncFileHandler.prefix = localhost.
   2localhost.org.apache.juli.AsyncFileHandler.encoding = UTF-8
   
   3manager.org.apache.juli.AsyncFileHandler.level = FINE
   3manager.org.apache.juli.AsyncFileHandler.directory = ${catalina.base}/logs
   3manager.org.apache.juli.AsyncFileHandler.prefix = manager.
   3manager.org.apache.juli.AsyncFileHandler.encoding = UTF-8
   
   4host-manager.org.apache.juli.AsyncFileHandler.level = FINE
   4host-manager.org.apache.juli.AsyncFileHandler.directory = ${catalina.base}/logs
   4host-manager.org.apache.juli.AsyncFileHandler.prefix = host-manager.
   4host-manager.org.apache.juli.AsyncFileHandler.encoding = UTF-8
   
   java.util.logging.ConsoleHandler.level = FINE
   java.util.logging.ConsoleHandler.formatter = org.apache.juli.OneLineFormatter
   java.util.logging.ConsoleHandler.encoding = GBK
   12345678910111213141516171819202122232425262728
   

   因?yàn)橐话鉾eb項(xiàng)目都是用到了tomcat, 因此tomcat也需要配置, 但實(shí)際上這個(gè)配置影響的只是tomcat相關(guān)的log文件
   至于這個(gè)地方為什么網(wǎng)上大多都是 GBK? 請(qǐng)往下看, 下面有解釋

5. 正確配置log配置文件編碼(重要)

   • 終于到了我們最重要的環(huán)節(jié), 我想說(shuō)的是99%的亂碼問(wèn)題都是我們log配置文件沒(méi)有配置好導(dǎo)致的, 結(jié)果大家不去改log配置文件, 偏偏盯上VM配置, 和tomcat配置.

   • 我想告訴大家的是, 人家IDEA, tomcat, JDK的默認(rèn)配置明明已經(jīng)很好了, 我們應(yīng)該去適應(yīng)人家, 而不是修改人家的默認(rèn)配置來(lái)適應(yīng)我們五花八門(mén)的log配置文件,

     例如:
     A的log配置的有問(wèn)題, 導(dǎo)致IDEA控制臺(tái)亂碼了, 他修改了IDEA, tomcat, JDK配置, 成功強(qiáng)迫IDEA, tomcat, JDK配置適應(yīng)它的他配置, 最終成功正確輸出日志,
     之后B的log配置的也有問(wèn)題, 日志也亂碼了, 然后他參照A的配置配置之后, 發(fā)現(xiàn)亂碼問(wèn)題依然沒(méi)有解決,

   • 要知道這個(gè)項(xiàng)目一個(gè)log配置, 那個(gè)項(xiàng)目一個(gè)log配置, 還有的log框架都不一樣, 就算要強(qiáng)迫IDEA, tomcat, JDK適應(yīng)我們的log配置文件, 由于我們的log配置文件不一樣, 對(duì)應(yīng)的被強(qiáng)迫的IDEA, tomcat, JDK配置也是不一樣的

   • 因此為了統(tǒng)一配置方式, IDEA, tomcat, JDK 配置使用默認(rèn)即可, 由我們的log配置來(lái)適應(yīng)它們.

   下面是我的 log4j2.xml 部分示例配置, 如果你用的是log4j或logback或其它, 就參照相對(duì)的log框架的Appenders配置方法

   這里我為每個(gè)Appender 配置一下輸出編碼, 和控制臺(tái)有關(guān)的:Console:charset 改為*第3步file.encoding輸出的編碼*, 其它和文件有關(guān)的RollingFile全部設(shè)置為UTF-8**

   <?xml version="1.0" encoding="UTF-8"?>
   <Configuration status="DEBUG">
       <Appenders>
           <!--這個(gè)輸出控制臺(tái)的配置立润，這里輸出除了warn和error級(jí)別的信息到System.out -->
           <Console name="Console" target="SYSTEM_OUT" follow="true">
               <ThresholdFilter level="INFO" onMatch="ACCEPT" onMismatch="DENY" />
               <!-- 輸出日志的格式 -->
               <PatternLayout charset="GBK" pattern="%m%n" />
           </Console>
   
           <!-- 同一來(lái)源的Appender可以定義多個(gè)RollingFile泄朴，定義按天存儲(chǔ)日志 -->
           <RollingFile name="rolling_file" fileName="${logDir}/dust-server.log" filePattern="${logDir}/dust-server_%d{yyyy-MM-dd}.log">
               <ThresholdFilter level="INFO" onMatch="ACCEPT" onMismatch="DENY" />
               <!-- 輸出日志的格式 -->
               <PatternLayout charset="UTF-8" pattern="%m%n" />
           </RollingFile>
       </Appenders>
   
       <Loggers>
           <Root level="all">
               <AppenderRef ref="Console"/>
               <AppenderRef ref="rolling_file"/>
           </Root>
       </Loggers>
   </Configuration>
   12345678910111213141516171819202122232425
   

   另外說(shuō)一下幾個(gè)重要但是和亂碼無(wú)關(guān)的配置

   項(xiàng)目配置

   這個(gè)地方挺重要的, 它控制著你整個(gè)項(xiàng)目java 文件編碼, 配置文件編碼, 新建文件編碼.
   但是它和你的控制臺(tái)亂碼是毫無(wú)關(guān)系的, 就算你將這里的編碼配置改成UTF-3.1415926, 它也管不到你的日志亂碼

可能有很多人對(duì)上面的配置不理解 請(qǐng)繼續(xù)往下看.

二蜻懦、亂碼原因

首先我們要知道什么是亂碼, 簡(jiǎn)而言之亂碼就是文件打開(kāi)的編碼方式和文件本身編碼方式不對(duì), 注意這個(gè)地方有兩個(gè)編碼, 一個(gè)是文件本身的編碼, 一個(gè)是用什么編碼打開(kāi)文件, 兩個(gè)編碼不對(duì)應(yīng), 就會(huì)出現(xiàn)亂碼.

關(guān)于這個(gè) 淇℃伅, 我可以明確告訴你們這個(gè)是UTF-8編碼信息, 那為什么會(huì)顯示成淇℃伅呢, 是因?yàn)榭刂婆_(tái)以 GBK的方式顯示UTF-8編碼.

圖片中的控制臺(tái)亂碼中的日志一般有兩種, 一個(gè)是 tomcat 輸出日志到控制臺(tái), 另一個(gè)是 jvm 輸出日志到控制臺(tái)., 網(wǎng)上關(guān)于解決控制臺(tái)亂碼的方法大都是 修改 jvm 輸出日志編碼 和 tomcat 輸出日志編碼, 但是卻忽視了一個(gè)重要的編碼, 那就是 控制臺(tái)是以什么編碼方式顯示信息的呢?.

關(guān)于這點(diǎn)我可以告訴你們, 一般來(lái)說(shuō), 中國(guó)電腦系統(tǒng)默認(rèn)編碼是 GBK, IDEA 控制臺(tái)顯示的編碼也是 GBK.

現(xiàn)在是不是已經(jīng)明白了, 也就是說(shuō)控制臺(tái)以 GBK 的方式打開(kāi)了 tomcat 和 JVM 輸出的 UTF-8 編碼, 那不亂碼才怪.

三、深入分析亂碼原理

1. 首先讓我們列舉下我們可能用到的編碼有哪些

1. 在一些編譯器里面也許有 ANSI 這種編碼, 但實(shí)際上 ANSI 并不是特指某一種具體的編碼, 這里以window為例, 假如你window電腦的區(qū)域和語(yǔ)言是中國(guó), 那么“ANSI編碼”實(shí)際是GBK編碼揉燃。當(dāng)你把它改成Korean(Korea)時(shí)扫尺，“ANSI編碼”實(shí)際是EUC-KR編碼，當(dāng)你把它改成English(US)時(shí)你雌，“ANSI編碼”實(shí)際是ASCII編碼.
2. UTF-16 是JDK String 的存儲(chǔ)編碼, 但一般來(lái)說(shuō), 你只要不對(duì)char數(shù)組進(jìn)行bit解析, 至少你在日志中一般不會(huì)碰到UTF-16的情況.
3. 綜上分析, 我們只需要研究下GBK 和 UTF-8 兩種編碼格式即可.

2. 其次讓我們分析下JAVA IDEA開(kāi)發(fā)中涉及到的編碼配置可能有哪些

列舉所有可能出現(xiàn)的情況大概就以下幾種, 先別管對(duì)不對(duì), 只要可能的就先列舉上

1. java 源文件編碼.
2. java編譯成的class文件編碼.
3. jvm 以什么編碼格式運(yùn)行class文件.
4. jvm 以什么方式輸出日志
5. 控制臺(tái)以什么編碼格式顯示輸出日志.
6. 系統(tǒng)默認(rèn)編碼
7. log 日志輸出編碼(log4j, log4j2, logback).

四器联、接下來(lái)讓我們通過(guò)問(wèn)答的方式大家明白幾個(gè)解釋起來(lái)比較散亂的常識(shí)

Q1: java 源代碼會(huì)對(duì)亂碼有影響嗎

A: 源文件編碼格式對(duì)亂碼沒(méi)什么影響

事實(shí)上不管你 java 源代碼用的是什么編碼格式, 編譯成的 class 文件都是一樣的, 而class文件編碼貌似只有一種, 盲猜應(yīng)該是UTF-16.

下面是我將內(nèi)容同樣而編碼格式不同的兩份源碼編譯成的兩個(gè)class文件屬性圖, 通過(guò)文件算碼發(fā)現(xiàn)兩個(gè)class文件完全一致.

所以那些一亂碼就亂改文件格式的行為實(shí)際上對(duì)亂碼是沒(méi)有什么幫助的

Q2: -Dfile.encoding到底是什么

在命令行中輸入 java，在給出的提示中會(huì)出現(xiàn) -D 的說(shuō)明：

-D<name>=<value> # set a system property
1

也就是說(shuō) -D 后面需要跟一個(gè)鍵值對(duì)婿崭，作用是設(shè)置一項(xiàng)系統(tǒng)屬性
-Dfile.encoding=UTF-8 來(lái)說(shuō)就是設(shè)置系統(tǒng)屬性 file.encoding 為 UTF-8

Q3: file.encoding到底是有什么用

JVM 在運(yùn)行時(shí)有一個(gè)屬性 file.encoding, 這個(gè) file.encoding 的值, 默認(rèn)是系統(tǒng)編碼(中國(guó)大陸window系統(tǒng)編碼默認(rèn)是GBK), 但是如果在JVM啟動(dòng)時(shí)加一個(gè)參數(shù) -Dfile.encoding=UTF-8, 那么獲取 file.encoding 的值就變成了UTF-8,

這個(gè)file.encoding可重要了, 它不僅控制著JVM運(yùn)行時(shí)的編碼格式, 還控制著 System.out.println() 打印到控制臺(tái)的輸出編碼格式, 而且類(lèi)似于IDEA這類(lèi)IDE在顯示控制臺(tái)的時(shí)候還會(huì)通過(guò) file.encoding 確定控制臺(tái)用什么編碼來(lái)解析日志.

關(guān)于file.encoding, 在java代碼中獲取它的值的代碼是 System.getProperty("file.encoding") 或 Charset.defaultCharset().name().

在此說(shuō)一個(gè)題外話(huà), 例如在項(xiàng)目啟動(dòng)處, 例如Springboot啟動(dòng)處添加一句下面的代碼對(duì)亂碼時(shí)的解決是很有幫助的.

log.info("file.encoding: {}", System.getProperty("file.encoding"));

Q4: console.encoding 是什么

關(guān)于這個(gè)實(shí)際上可以在IDEA 官網(wǎng)看到這樣的內(nèi)容

翻譯成中文就是

然而我照著上面試過(guò)之后發(fā)現(xiàn), 無(wú)論我怎么添加配置后重啟, 最終都沒(méi)什么卵用, 為此這幾天我特意將IDEA從2019.3.3升級(jí)到了2020.3, 但是發(fā)現(xiàn)還是沒(méi)什么用, 最終決定控制臺(tái)輸出編碼的還是file.encoding, 如果有小伙伴知道, 這個(gè)有什么用的話(huà), 歡迎留言

Q5: log 日志配置對(duì)亂碼有影響嗎

A:關(guān)于log日志, 我只想說(shuō)的就是, 日常90%的亂碼都是因?yàn)閘og日志沒(méi)有配置好而引起的.

絕大多數(shù)日志亂碼情況下, 大家都是去改IDEA配置, 改 file.encoding, 但事實(shí)上是 IDEA 配置是沒(méi)有問(wèn)題的, 即便你的配置有些小問(wèn)題, java語(yǔ)言和IDEA的智能性也能幫你顯示成正確的編碼, 然后大家的處理方式就成了 明明是Log日志配置不對(duì), 卻偏偏去改IDEA配置, 致使IDEA去適應(yīng)log, 這樣即使最后顯示正確的編碼, 實(shí)際上也是沒(méi)有靈魂的.

1. 首先我想說(shuō)明一點(diǎn), log4j 實(shí)際上是有很多問(wèn)題的, 例如就有版本問(wèn)題和各種亂碼問(wèn)題.
2. 而且 log4j 比較惡心的是有些版本默認(rèn)輸出編碼格式遵循 file.encoding, 還有的默認(rèn) 系統(tǒng)編碼格式, 也就是說(shuō), 有些垃圾版本即便你改了file.encoding=UTF-8也沒(méi)用, 它依然遵循系統(tǒng)默認(rèn)GBK編碼.

而且都什么年代了, 別用log4j了, 換 log4j2 吧

Q6: log配置文件中編碼如何配置(以log4j2 配置為例)

1. 首先第一個(gè) encoding, 這個(gè) encoding 跟你的亂碼一般沒(méi)什么關(guān)系的, 它管理的是 log 配置文件的編碼格式, 也就是說(shuō)它管理的是日志插件以什么格式去解析log4j2.xml, 這個(gè)配置文件.

   知道Html吧, 第一個(gè)encoding和html文件標(biāo)題頭上面的 encoding 是類(lèi)似的.

   關(guān)于這個(gè)地方有個(gè)小Tip, 例如在IDEA里面, 只要你把文件頭的這個(gè)encoding從GBK改成UTF-8, 然后IDEA就會(huì)自然的把你整個(gè)文件的編碼格式給改成UTF-8了.

2. 如上圖中的2處和3處的<PatternLayout charset="GBK" pattern="%m%n" />, 這個(gè)配置管理的才是輸出到你的控制臺(tái)或者是文件的編碼, 當(dāng)然你也可以寫(xiě)成

   <PatternLayout charset="GBK" pattern="%m%n" />

注意這個(gè)配置是log4j2的配置, 如果你使用的是[log4j]或者是logback, 請(qǐng)?jiān)诰W(wǎng)上搜索相應(yīng)的編碼配置.

五拨拓、解決方式

既然如此, 那么解決方案就很明確了, 無(wú)非兩種

1. (不推薦)修改 IDEA 控制臺(tái)顯示編碼為 UTF-8, 以及 tomcat, jvm 輸出的日志編碼也修改為 UTF-8;

   • toncat 安裝路徑下的 conf/logging.properties 配置文件中的 java.util.logging.ConsoleHandler.encoding 改成 UTF-8;

   • jvm 啟動(dòng)參數(shù) VM options 加個(gè)配置 -Dfile.encoding=UTF-8

2. (推薦)直接使用 IDEA 控制臺(tái)顯示的 GBK 編碼, 把 tomcat, jvm 輸出的日志編碼也全部改為 GBK;

   • toncat 安裝路徑下的 conf/logging.properties 配置文件中的 java.util.logging.ConsoleHandler.encoding 改成 GBK;

   • jvm 啟動(dòng)參數(shù) VM options 加個(gè)配置 -Dfile.encoding=GBK.

     如果你沒(méi)有加亂七八糟的配置的話(huà), 這個(gè) jvm -Dfile.encoding 啟動(dòng)參數(shù)直接置空, 就會(huì)自動(dòng)使用系統(tǒng)默認(rèn)編碼 GBK

我為什么推薦控制臺(tái)使用 GBK

上面解決方式中, 第二種反而是我比較推薦的一種方式, 那有人就會(huì)問(wèn)了, 全部改成 UTF-8 編碼不好嗎?

首先看下面的我的編碼對(duì)接思想.

我的編碼設(shè)置思想

第二種方法只要明白原理后, 實(shí)際上配置起來(lái)非常簡(jiǎn)單, 只要注意下控制臺(tái)的編碼是你電腦的默認(rèn)編碼即可.

第一種解決方案的弊端

第一種解決方案有什么弊端呢?

首先即便你更改了 IDEA 的控制臺(tái)編碼, tomcat 什么的也全部改成 UTF-8, 那么當(dāng)你單獨(dú)運(yùn)行 tomcat 的時(shí)候, tomcat 會(huì)使用系統(tǒng)控制臺(tái)打印日志, 那么系統(tǒng)控制臺(tái)使用的編碼是什么呢, 如果你用的是中國(guó)的 window, 那么編碼格式 9 成 9 是 GBK, 因?yàn)檫@是你的系統(tǒng)默認(rèn)編碼, 無(wú)論是 tomcat, jvm, IDEA, 或者是其它開(kāi)發(fā)軟件或者是非開(kāi)發(fā)軟件, 編碼對(duì)標(biāo)的首先是你的電腦系統(tǒng)編碼格式.

那么干脆點(diǎn), 把整臺(tái)電腦的編碼全部改成 UTF-8 編碼怎么樣呢?

這絕對(duì)是個(gè)大工程量, 這不是隨隨便便就改的完的, 其次這會(huì)遇到很多問(wèn)題, 聽(tīng)我一步步分析.

假如你在中國(guó), 使用的是 window, 系統(tǒng)默認(rèn)編碼是 GBK.

1. 首先你過(guò)去的文件, 軟件使用的是 GBK 編碼. 你之前寫(xiě)的文檔, 寫(xiě)的筆記, 以及使用其它軟件保存的文件大多都是 GBK, 改起來(lái)很麻煩.

2. 其次網(wǎng)上的資源大多是 GBK, 或是一本小說(shuō), 一首歌的歌詞, 或是游戲中文翻譯包, 或者是視頻字幕大多也都是 GBK, 這時(shí)候你碰到一個(gè)垃圾閱讀器, 音樂(lè)視頻播放器, 游戲軟體, 它們不去識(shí)別文件 GBK 編碼, 直接通過(guò)系統(tǒng)默認(rèn)編碼 UTF-8 打開(kāi), 然后就會(huì)出現(xiàn)亂碼情況.

3. 然后因?yàn)槟愕耐? 你的朋友它們電腦上大多都是 GBK 編碼格式, 假如你們使用 git 或 svn 管理文檔, 你使用 UTF-8 格式, 你同事大多不修改配置默認(rèn)使用 GBK, 然后你覺(jué)得這樣好嗎? 哪怕你的編輯器能自動(dòng)識(shí)別編碼, 你拉娶個(gè)gbk編碼文件, 改動(dòng)保存后, 再以u(píng)tf-8格式推送出去… 然后一個(gè)文檔項(xiàng)目就出現(xiàn)了兩種編碼. 甚至你做個(gè)設(shè)計(jì)流程圖, 建個(gè)帶中文注釋的數(shù)據(jù)表, 同步到你朋友的電腦上, 打開(kāi), 臥槽, 亂碼了.

4. 最后, GBK 存儲(chǔ)漢字占用空間更小, 非開(kāi)發(fā)工作沒(méi)有必要使用UTF-8.

end

那么一個(gè)公司全部將電腦編碼改成 UTF-8 不行嗎?

可以啊, 只要你們公司要求這樣就可以, 只要電腦是公司統(tǒng)一發(fā)放的就可以, 只要你們公司同事都愿意改系統(tǒng)編碼就可以, 只要整個(gè)電腦全部用來(lái)做開(kāi)發(fā), 不干其它事情就可以.

至于為了開(kāi)發(fā)讓我去更改個(gè)人電腦系統(tǒng)編碼改成 UTF-8, 那還是算了吧, 我個(gè)人的電腦難道僅僅是為了開(kāi)發(fā)嗎? 我還要做其它事情呢.

而且就為了個(gè)控制臺(tái)亂碼更改系統(tǒng)編碼至于嗎? 第二種方式不香嗎, GBK不香嗎?

當(dāng)然具體怎么選擇, 視個(gè)人情況而定

附加技巧

如何找出具體亂碼原因

想要知道你的亂碼為什么亂碼成那樣, 請(qǐng)先在你的程序里面打印輸出 0信1息2信息3,之后看下亂碼情況是以下解碼后顯示的哪一種亂碼, 應(yīng)該就能找到你的亂碼是如何亂碼成你看到的樣子的.

如下第6行, 原信息是0信1息2信息3, 編碼格式是UTF-8編碼, 但是以 GBK的方式對(duì)其進(jìn)行解碼后就變成了0淇?1鎭?2淇℃伅3.

上面的表格只是列舉了我們絕大多數(shù)情況下涉及到的編碼 US-ASCII,UTF-8,GBK,UTF-16, 可能你用了之外的其它編碼, 另外上面也僅僅是展示了一層轉(zhuǎn)換而已, 可能有以錯(cuò)誤編碼解碼后再次被引用之后再次解碼的多次錯(cuò)誤轉(zhuǎn)換的情況, 例如UTF編碼的信息f以GBK的方式解碼后變成了淇℃伅之后再以UTF-8的形式存儲(chǔ)后, 再以GBK方式打開(kāi), 就變成了娣団剝浼???.