幾天有OMI的用戶反映,安裝OMI時(shí)有中文亂碼現(xiàn)象,我還說不可能。我們的程序在windows,linux都部署過無數(shù)次了,開發(fā)時(shí)都是UTF8編碼的,咋還會(huì)亂碼呢。結(jié)果看了半天也沒看出個(gè)啥,還是沒解決。
最近新安裝程序時(shí),新下載了一個(gè)tomcat8.5的版本,一跑程序還真是html頁亂碼了,但JSP頁沒事。因?yàn)橹拔覀兊某绦蚨际桥茉趖omcat7,最高是tomcat8.0,沒試過更高的,高版本確實(shí)有問題,且控制臺(tái)中文也是亂碼。
一、嘗試了一些網(wǎng)友給的辦法,下面說一下解決方案:
1、tomcat\bin\catalina.bat 中添加,
set JAVA_OPTS=-Xms512m -Xms1024m -XX:MaxPermSize=1024m -Dfile.encoding=UTF-8
我的添加位置如圖
?前面是正好順便設(shè)置了JVM的內(nèi)存,解決問題的主要后面的部分。
2、修改tomcat\conf\server.xml,加入 URIEncoding="UTF-8"
加入如圖位置
?好象是第一步就可以了,保險(xiǎn)起見第二步也加上吧 。
二、關(guān)于控制臺(tái)亂碼解決辦法:
修改tomcat\conf\logging.properties
#java.util.logging.ConsoleHandler.encoding = UTF-8(GBK)
將UTF-8改為GBK,或者把整行注掉
我是把相關(guān)編碼全注了
以上,如未解決問題可以加QQ群交流,群名:Kettle實(shí)戰(zhàn)。
初學(xué)者在Windows平臺(tái)上進(jìn)行C/C++語言(中文)程序開發(fā)時(shí),有時(shí)會(huì)遇到編譯報(bào)錯(cuò)、在控制臺(tái)運(yùn)行時(shí)顯示中文亂碼的問題。
本文就此類問題進(jìn)行描述、展開原因分析,然后給出解決方法。
本次分享內(nèi)容的目錄如下:
基本概念(字符集、字符編碼、代碼頁、GBK、UTF-8)
問題描述(示例源碼、編譯報(bào)錯(cuò)、中文亂碼)
原因分析(編碼環(huán)節(jié)簡(jiǎn)介、原因分析)
解決方法(解決思路、編譯報(bào)錯(cuò)解決、中文亂碼解決)
結(jié)束語
本文會(huì)涉及到如下基本概念:
Charset(字符集):是一個(gè)系統(tǒng)支持的所有抽象字符的集合。字符是各種文字和符號(hào)的總稱,包括各國(guó)家文字、標(biāo)點(diǎn)符號(hào)、圖形符號(hào)、數(shù)字等。常見的字符集有:ASCII字符集、Unicode字符集等。
計(jì)算機(jī)要準(zhǔn)確的處理各種字符集文字,需要進(jìn)行字符編碼,以便計(jì)算機(jī)能夠識(shí)別和存儲(chǔ)各種文字。
Character Encoding(字符編碼)用于為指定集合中某一對(duì)象(如電脈沖、比特模式等),以便文本在計(jì)算機(jī)中存儲(chǔ)和通過通信網(wǎng)絡(luò)的傳遞。字符編碼就是將符號(hào)轉(zhuǎn)換為計(jì)算機(jī)可以接受的數(shù)字系統(tǒng)的數(shù)。常見的例子:將拉丁字母表編碼成ASCII。
注:術(shù)語字符編碼(Character Encoding)、字符映射(Character Map)或者代碼頁(CodePage),在歷史上往往是同義概念,即字符表(repertoire)中的字符如何編碼為碼元的流(stream of code units)–通常每個(gè)字符對(duì)應(yīng)單個(gè)碼元。
CodePage(代碼頁)是字符編碼的別名,也稱內(nèi)碼表,是特定語言的字符集的一張表。
注:Windows代碼頁最初是根據(jù)ANSI草案實(shí)現(xiàn)的,這個(gè)草案最終成為ISO 8859-1。這是Windows代碼頁被稱作ANSI的緣由。
本文涉及到的兩個(gè)重要代碼頁介紹如下:
Windows平臺(tái)上的GUI程序使用ANSI代碼頁,而在控制臺(tái)程序使用OEM代碼頁(以便向后兼容)。
在Windows系統(tǒng)中的命令行窗口可以通過chcp命令來顯示當(dāng)前代碼頁(如Windows 7 簡(jiǎn)體中文操作系統(tǒng)上默認(rèn)的代碼頁是936):
C:\> chcp
活動(dòng)代碼頁: 936
也可以通過在chcp命令后帶一個(gè)具體整數(shù)參數(shù)(代碼頁數(shù)值)來臨時(shí)改變命令行窗口的當(dāng)前代碼頁(如臨時(shí)修改為UTF-8對(duì)應(yīng)的65001):
C:\> chcp 65001
Active code page: 65001
GBK(英文全稱:Chinese Internal Code Extension Specification,中文全稱:漢字內(nèi)碼擴(kuò)展規(guī)范)是對(duì)GB2312-80的擴(kuò)展,也就是代碼頁936的擴(kuò)展(之前代碼頁936和GB2312-80一模一樣),最早實(shí)現(xiàn)于Windows 95簡(jiǎn)體中文版。
GBK總體編碼范圍為0x8140~0xFEFE,首字節(jié)在 0x81~0xFE 之間,尾字節(jié)在 0x40~0xFE 之間,剔除 xx7F 一條線。GBK共收錄21886個(gè)漢字和圖形符號(hào),其中漢字(包括部首和構(gòu)件)21003個(gè),圖形符號(hào)883個(gè)。
后續(xù)國(guó)家標(biāo)準(zhǔn)GB18030技術(shù)上兼容GBK。
注:微軟Windows安排給GBK的代碼頁是936,所以編碼格式WINDOWS-936其實(shí)就是GBK。
UTF-8(8-bit Unicode Transformation Format)是一種針對(duì) Unicode 的可變長(zhǎng)度字符編碼。它可以用一至四個(gè)字節(jié)對(duì) Unicode字符集中的所有有效編碼點(diǎn)進(jìn)行編碼,屬于Unicode 標(biāo)準(zhǔn)的一部分。
自2009年以來 UTF-8一直是互聯(lián)網(wǎng)上使用最廣的一種編碼方式。
初學(xué)者在Windows平臺(tái)上進(jìn)行C/C++語言(中文)程序編程開發(fā)時(shí),有時(shí)會(huì)遇到編譯報(bào)錯(cuò)、在控制臺(tái)執(zhí)行時(shí)顯示中文亂碼的問題。
下面用于示例的一個(gè)C語言源代碼文件(功能:從控制臺(tái)顯示一段中英文信息。)
#include <stdio.h>
int main(void)
{
printf("+++++++++++++++++++++++++++\n");
printf("++ Hello, C語言開發(fā)者! ++\n");
printf("+++++++++++++++++++++++++++\n");
return 0;
}
第一類問題是:在編譯時(shí)發(fā)現(xiàn)報(bào)錯(cuò),報(bào)錯(cuò)信息如下:
hello.c: In function 'main':
hello.c:6:12: error: converting to execution character set: Illegal byte sequence
printf("++ Hello, C語言開發(fā)者! ++\n");
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
第二類問題是:能順利通過編譯生成可執(zhí)行文件,但該可執(zhí)行文件在Windows控制臺(tái)上運(yùn)行時(shí)顯示中文亂碼,如下圖示:
控制臺(tái)顯示中文亂碼1
或:
控制臺(tái)顯示中文亂碼2
Windows平臺(tái)C/C++語言(中文)程序編譯報(bào)錯(cuò)、在控制臺(tái)執(zhí)行時(shí)顯示中文亂碼一般都是由于編碼不一致所引起的。
首先,我們來看看在 Windows 平臺(tái)上開發(fā)運(yùn)行一個(gè)C/C++語言程序的全過程(源文件編輯、編譯、運(yùn)行)中主要涉及的編碼環(huán)節(jié)有哪些?
C語言開發(fā)全過程涉及的編碼環(huán)節(jié)
環(huán)節(jié)一、源代碼保存時(shí)的字符編碼
環(huán)節(jié)二、編譯器編譯時(shí)的輸入文件(源文件)字符編碼
環(huán)節(jié)三、編譯器編譯好的輸出文件(可執(zhí)行文件)字符編碼
環(huán)節(jié)四、控制臺(tái)使用的字符編碼
Windows平臺(tái)C/C++語言(中文)程序編譯報(bào)錯(cuò)、在控制臺(tái)執(zhí)行時(shí)顯示中文亂碼一般都是由于編碼不一致所引起的。
原因分析
從上圖可以很清晰的看出編譯報(bào)錯(cuò)的原因是在環(huán)節(jié)一與環(huán)節(jié)二兩處的編碼不一致(如下)所引起的:
(一)上圖中的1與4的組合(源文件保存為UTF-8編碼,但GCC編譯器對(duì)輸入文件-源文件設(shè)置的是按GBK編碼解析)
(二)上圖中的2與3的組合(源文件保存為GBK編碼,但GCC編譯器對(duì)輸入文件-源文件設(shè)置的是按UTF-8編碼解析)
從上圖可以很清晰的看出中文亂碼的原因是在環(huán)節(jié)三與環(huán)節(jié)四兩處的編碼不一致(如下)所引起的:
(一)上圖中的5與8的組合(GCC編譯器對(duì)輸出執(zhí)行文件設(shè)置的是UTF-8編碼,但Windows控制臺(tái)是GBK編碼)
(二)上圖中的6與7的組合(GCC編譯器對(duì)輸出執(zhí)行文件設(shè)置的是GBK編碼,但Windows控制臺(tái)是UTF-8編碼)
通過上述原因分析,已經(jīng)發(fā)現(xiàn)了編譯報(bào)錯(cuò)和中文亂碼的問題根源所在:前后環(huán)節(jié)的編碼不一致造成。
既然問題根源找到了,那么解決思路也就迎刃而解了(如下圖示):
解決思路
一、在環(huán)節(jié)一和環(huán)節(jié)二之間保持兩者編碼的一致性(1和3組合,或2和4組合)進(jìn)而解決編譯報(bào)錯(cuò)問題;
二、在環(huán)節(jié)三和環(huán)節(jié)四之間保持兩者編碼的一致性(5和7組合,或6和8組合)進(jìn)而解決中文亂碼問題。
針對(duì)編譯報(bào)錯(cuò)的兩種情形(1和4組合、2和3組合)具體解決辦法是:
修改源文件編碼為UTF-8編碼,以跟GCC編譯器對(duì)輸入文件-源文件默認(rèn)UTF-8編碼解析保持一致。
修改源文件編碼為UTF-8編碼的具體步驟如下:
修改源文件編碼為UTF-8編碼
修改源文件編碼為GBK編碼,將GCC編譯器對(duì)輸入文件-源文件設(shè)置為是按GBK編碼解析。
一、修改源文件編碼為GBK編碼的具體步驟
與上面類似(在下拉框中把UTF-8改為WINDOWS-936即可)。
修改源文件編碼為GBK編碼
二、修改編譯器對(duì)輸入源文件的解析編碼為GBK編碼的具體步驟如下:
修改編譯器輸入編碼設(shè)置
驗(yàn)證:經(jīng)過前面兩種方法的設(shè)置,完成編碼一致性后,再次進(jìn)行編譯,就已經(jīng)可以成功通過了(如下圖示)。
編譯成功但顯示亂碼
但是你會(huì)發(fā)現(xiàn)程序運(yùn)行在控制臺(tái)時(shí)顯示中文亂碼了。
此時(shí)再回想一下:源文件編碼(GBK)+ 編譯器輸入設(shè)置編碼(GBK) = 編譯通過。但因?yàn)镚CC編譯器默認(rèn)輸出執(zhí)行文件編碼為UTF-8編碼,同時(shí)Windows控制臺(tái)默認(rèn)是GBK編碼,所以此時(shí)程序運(yùn)行在控制臺(tái)顯示中文亂碼邏輯上是正常的。
針對(duì)中文亂碼的兩種情形(5和8組合、6和7組合)具體解決辦法是:
設(shè)置GCC編譯器對(duì)輸出執(zhí)行文件是GBK編碼,跟Windows控制臺(tái)默認(rèn)GBK編碼保持一致。
修改編譯器對(duì)輸出執(zhí)行文件編碼為GBK編碼的具體步驟如下:
修改編譯器輸出編碼設(shè)置
修改Windows控制臺(tái)編碼為UTF-8編碼,以跟GCC編譯器對(duì)輸出執(zhí)行文件默認(rèn)UTF-8編碼保持一致。
修改Windows控制臺(tái)編碼為UTF-8編碼的具體步驟如下:
運(yùn)行regedit命令
進(jìn)入注冊(cè)表編輯器查找
修改注冊(cè)表項(xiàng)
修改注冊(cè)表完成
注1:如果要恢復(fù)原數(shù)值只需重復(fù)同樣的步驟,把65001修改為936即可。
注2:上面方法面向所有的控制臺(tái)(如:Windows默認(rèn)CMD控制臺(tái)、CodeBlocks控制臺(tái)、DevCpp控制臺(tái)、Git CMD控制臺(tái)等)生效。
注3:如果只需針對(duì)特定控制臺(tái)生效,可以在本步驟基礎(chǔ)上,再往下一層,選中具體控制臺(tái)(如【C:_Develop_CodeBlocks_cb_console_runner.exe】),然后通過鼠標(biāo)右鍵菜單新建一個(gè)【DWORD(32位)值】,該數(shù)值名稱設(shè)為【CodePage】,數(shù)值數(shù)據(jù)設(shè)為【65001】(十進(jìn)制)。然后【F5】刷新即可生效。
驗(yàn)證:經(jīng)過上面兩種方法的設(shè)置,完成編碼一致性后,再次在控制臺(tái)運(yùn)行軟件時(shí)就已經(jīng)是正常顯示中英文了(如下圖示):
編譯、運(yùn)行顯示正常
注:本文雖是以Code::Blocks集成開發(fā)環(huán)境為例進(jìn)行講解,但其原理針對(duì)Windows平臺(tái)上C語言程序運(yùn)行的其他控制臺(tái)(如Windows默認(rèn)CMD控制臺(tái)、Git CMD控制臺(tái)等)也是適用的。
相信各位 C 語言初學(xué)者們閱讀完本文后,應(yīng)該已經(jīng)對(duì) Windows 平臺(tái)C語言(中文)程序在編譯時(shí)報(bào)錯(cuò)的原因及解決辦法、在控制臺(tái)運(yùn)行時(shí)顯示中文亂碼的原因及解決辦法已經(jīng)有了比較基本的了解掌握,此類問題將不再困擾,接下來就可以愉快地學(xué)習(xí)其他 C 語言知識(shí)了。
希望本文能對(duì)您有所幫助!喜歡的話就點(diǎn)個(gè)贊加關(guān)注支持一下哈:)
Jenkins+Newman+Postman自動(dòng)化集成構(gòu)建時(shí),Console Output輸出亂碼如下
image.png
解決方案如下:
1、在tomcat的catalina.sh里配置環(huán)境變量
在文件的末尾新增 export JAVA_TOOL_OPTIONS="-Dfile.encoding=UTF-8"
image.png
2、啟動(dòng)tomcat,進(jìn)入jenkins 系統(tǒng)管理-->系統(tǒng)設(shè)置,在全局變量中增加環(huán)境變量
鍵:LANG 值:zh_CN.UTF-8
然后點(diǎn)擊應(yīng)用,再點(diǎn)擊保存
image.png
3、重啟tomcat,即可進(jìn)入jenkins的后臺(tái)查看配置參數(shù)file.encoding為utf8編碼格式
系統(tǒng)管理-->系統(tǒng)信息
image.png
4、再次重新構(gòu)建,亂碼問題解決
竟然都看到最后了,給小編點(diǎn)個(gè)關(guān)注吧,小編還會(huì)持續(xù)更新的,只收藏不點(diǎn)關(guān)注的都是在耍流氓!
*請(qǐng)認(rèn)真填寫需求信息,我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。