整合營銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
天突然想到之前的一個項(xiàng)目，是和另一個公司合作，我提供后臺，對方寫小程序調(diào)用我的接口，我本地測試好接口后，是沒有問題的，然后部署到對方服務(wù)器（windows系統(tǒng)），接著就是出先各種各樣的亂碼問題，在這里匯總記錄下，以便后面學(xué)習(xí)。
java亂碼出現(xiàn)的問題有很多，這里主要記錄下tomcat，log4j,mysql,jsp,html,http(get,post請求亂碼處理)。常見的問題可能是tomcat，http請求亂碼問題了，至于jsp和html的亂碼問題就很簡單了，相信大家也知道，我也就不多說了，首先來說下tomcat的亂碼問題，
一個是程序需要發(fā)送http GET請求到服務(wù)器，請求的參數(shù)中包含了中文字符。程序中參數(shù)為UTF-8格式，且經(jīng)過了UTF-8 URL編碼再發(fā)送。使用的tomcat服務(wù)器，但服務(wù)器端后臺程序中取到的參數(shù)的中文是亂碼。
解決辦法：修改Tomcat的Server.xml，在Connector標(biāo)簽中加上URLEncoding參數(shù)。
<Connector port="8080" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" redirectPort="8443" acceptCount="100" debug="99" connectionTimeout="20000" disableUploadTimeout="true" URIEncoding="UTF-8"/>
另一個是tomcat控制臺打印亂碼，程序中輸出到tomcat控制臺的中文信息亂碼了，
解決辦法：打開文件/tomcat/bin/catalina.bat，然后設(shè)置set JAVA_OPTS=的內(nèi)容中添加選項(xiàng)-Dfile.encoding=UTF-8即可，當(dāng)然，我不敢包證，但是我的就是這么處理然后就可以了。
然后是log4j的日志打印亂碼，這個亂碼也是打印在tomcat控制臺的時候亂碼，但是日志文件卻不會，而且我本地測試的時候打印也不會亂碼
而且我配置的也是utf-8，這個曾經(jīng)讓我惱火好久，后面我偶然在一篇博客上發(fā)現(xiàn)，說有些服務(wù)器你配utf-8是不行的，他的是編碼就是GBK，我就權(quán)當(dāng)試試，沒想到還真是這個問題，這也是讓我很無語，，，，
然后就是http請求的亂碼，我這個亂碼問題是我在shiro判斷是否登錄的時候，因?yàn)槲沂乔昂蠖朔蛛x，所以我shiro判斷未登錄的時候，是返回狀態(tài)碼和提示信息，而不是跳轉(zhuǎn)登錄頁面，我用response返回中文提示信息是，結(jié)果返回的是亂碼，可是我明明設(shè)置了
res.setCharacterEncoding("utf-8");
可是到前端頁面的時候還是亂碼了，這讓我很費(fèi)解，后面我仔細(xì)想了下，我服務(wù)端是設(shè)置了返回utf-8的編碼,但是瀏覽器是用utf-8去解析的嗎？后面去查了下還要加一條配置，
res.setContentType("text/html;charset=utf-8");
之前知道有這個配置，但是一直不知道有什么區(qū)別，今天算是明白了一點(diǎn)，這個就是告訴瀏覽器，你要用什么編碼去解析這個數(shù)據(jù)。
最后一個是mysql 中文的亂碼了，這個著實(shí)讓我煩惱了好久，我去網(wǎng)上查了，說建表的時候要設(shè)置utf-8的編碼，可是我在新建數(shù)據(jù)庫的時候就設(shè)置了默認(rèn)就是utf-8的編碼，然后我說要配置數(shù)據(jù)庫的默認(rèn)編碼，修改mysql配置文件/etc/my.cnf。
[mysqld] character-set-server=utf8 [client] default-character-set=utf8 [mysql] default-character-set=utf8
我設(shè)置好這個以后，終于不會亂了，但是，，保存進(jìn)去的中文居然全部變成了？？？號，于是又去奔波了，
通過這個命令，我們可以看到，我們服務(wù)端居然還不是utf-8？？？
這讓我很傷，終于，尋的良方，
只要在數(shù)據(jù)庫properties文件的連接信息里加兩個參數(shù)
?useUnicode=true&characterEncoding=utf-8
就可以了，唉，真是一波三折啊，
真是與服務(wù)器斗，其樂無窮；與數(shù)據(jù)庫斗，其樂無窮；與瀏覽器斗，其樂無窮啊
pache Derby 是一個開源的完全使用 Java 語言實(shí)現(xiàn)的嵌入式關(guān)系型數(shù)據(jù)庫。JDK歷史版本中曾經(jīng)包含了 Derby 版本，叫做 Java DB，但目前 JDK 中已經(jīng)不再默認(rèn)包含了。
官網(wǎng)主頁：https://db.apache.org/derby/
在更新JDK到21/22版本后，同樣也是出現(xiàn)使用控制臺執(zhí)行SQL腳本出現(xiàn)漢字亂碼。
D:\db-derby-10\bin>sysinfo
------------------ Java 信息 ------------------
Java 版本： 21.0.2
Java 供應(yīng)商： Oracle Corporation
Java 主目錄： D:\JDK21
Java 類路徑： D:\db-derby-10/lib/derbyshared.jar;D:\db-derby-10/lib/derby.jar;D:\db-derby-10/lib/de
rbynet.jar;D:\db-derby-10/lib/derbyclient.jar;D:\db-derby-10/lib/derbytools.jar;D:\db-derby-10/lib/derby
optionaltools.jar
OS 名： Windows 10
OS 體系結(jié)構(gòu)： amd64
OS 版本： 10.0
Java 用戶名： chenxd
Java 用戶主目錄：C:\Users\chenxd
Java 用戶目錄： D:\db-derby-10\bin
java.specification.name: Java Platform API Specification
java.specification.version: 21
java.runtime.version: 21.0.2+13-LTS-58
--------- Derby 信息 --------
[D:\db-derby-10\lib\derby.jar] 10.17.1.0 - (1913217)
[D:\db-derby-10\lib\derbytools.jar] 10.17.1.0 - (1913217)
[D:\db-derby-10\lib\derbynet.jar] 10.17.1.0 - (1913217)
[D:\db-derby-10\lib\derbyclient.jar] 10.17.1.0 - (1913217)
[D:\db-derby-10\lib\derbyshared.jar] 10.17.1.0 - (1913217)D:\db-derby-10\bin>startNetworkServer
Tue May 14 10:47:20 CST 2024 : Apache Derby 網(wǎng)絡(luò)服務(wù)器 - 10.17.1.0 - (1913217) 已啟動并準(zhǔn)備接受端口 1527
上的連接運(yùn)行ij，插入記錄，出現(xiàn)亂碼（JDK19及之前未曾出現(xiàn)這個問題）：
D:\db-derby-10\bin>ij -p ij.properties
ij>connect 'chendb';
ij> drop table zipcodes;
ij> create table zipcodes(zipcode varchar(6), university varchar(20), city varchar(10));
ij> insert into zipcodes values ('100044', '北京交通大學(xué)', '北京');
ij> insert into zipcodes values ('200030', '上海交通大學(xué)', '上海');
ij> select * from zipcodes;
ZIPCO&|UNIVERSITY |CITY
--------------------------------------
100044|?????????? |????
200030|????????? |???基于上回Java輸入輸出文件亂碼的經(jīng)驗(yàn)，基本確定就是控制臺字符集（GBK）和數(shù)據(jù)庫字符集（UTF-8）編碼不一致，需要修改ij運(yùn)行時的字符集為GBK。由于ij運(yùn)行時，實(shí)際是用java命令指定類名運(yùn)行的，可以使用運(yùn)行時指定 ”-Dderby.ui.codeset=GBK“ 來修改字符集為“GBK”。為了方便使用，直接使用配置文件ij.propertis，在其中加入字符集相關(guān)的屬性定義：
ij.driver=org.apache.derby.jdbc.ClientDriver
ij.protocol=jdbc:derby://localhost:1527/
#解決JDK21后，命令行漢字輸入亂碼問題
#默認(rèn)命令行字符集為GBK（代碼頁936）而非UTF-8（代碼頁 65001）
#https://www.rfc-editor.org/rfc/rfc5646.html
derby.ui.locale=zh-Hans
derby.ui.codeset=GBK重新運(yùn)行ij：
D:\db-derby-10\bin>ij -p ij.properties
ij 版本 10.17
ij> connect 'chendb';
ij> insert into zipcodes values ('100044', '北京交通大學(xué)', '北京');
已插入/更新/刪除 1 行
ij> select * from zipcodes;
ZIPCO&|UNIVERSITY |CITY
--------------------------------------
100044|?????????? |????
200030|????????? |???
100044|北京交通大學(xué) |北京
已選擇 3行
ij>至此成功解決亂碼問題。
14_HttpRunner中文亂碼問題_01_悟空CRM 斷言中文失敗顯示亂碼_原因分析
測試目的：
通過瀏覽器登錄成功后，進(jìn)入系統(tǒng)首頁，查看源代碼，準(zhǔn)備把標(biāo)題文字作為斷言用例執(zhí)行是否成功的標(biāo)志。
編寫測試用例如下：
- config:
name: 悟空CRM
- test:
name: 登錄
request:
url: http://192.168.1.102/72crm/index.html#/workbench/index
method: POST
data:
username: 13888888888
password: 123456
validate:
- eq: [status_code, 200]
- eq: [<title>(.*)CRM</title>, 悟空]
執(zhí)行測試用例，直接失敗 :(
看看錯誤提示，發(fā)現(xiàn)是第二個斷言，即標(biāo)題的斷言失敗了。
再仔細(xì)看輸出，實(shí)際結(jié)果提取出來的是亂碼，到這里就基本清楚了，字符編碼問題！！
我們編寫用例使用的是 UTF-8 字符編碼方式，這種方式下對常見中文的編碼規(guī)律是，每個漢字被編碼為三個字節(jié)，“悟空”是兩個漢字，編碼后對應(yīng)六個字節(jié)，數(shù)數(shù)亂碼的字符數(shù)量，正好也是六個。
這六個亂碼是什么鬼。別著急，我們詳細(xì)分析一下。
這里我使用的常見的 EditPlus 文本編輯工具，新建一個空白文本文件，輸入“悟空”二字，并保存為“UTF-8”編碼方式（注意：這是重點(diǎn)！ 重點(diǎn)！）
保存成功后，直接查看文件內(nèi)容的十六進(jìn)制編碼。
“悟空”二字的 UTF-8 編碼是： E6 82 9F E7 A9 BA 共六個字節(jié)
正常情況下，用UTF-8方式進(jìn)行編碼，則解碼也必須是UTF-8方式，即編碼和解碼一致，否則就會出現(xiàn)亂碼。我們通過HttpRunner執(zhí)行測試用例，返回的HTTP響應(yīng)數(shù)據(jù)（即HTML文件）中，標(biāo)題位置直接就輸出了亂碼（見截圖中劃綠線的紅色錯誤提示部分）。那么HttpRunner到底用的什么方式進(jìn)行解碼呢？一般情況下，尤其是英文的軟件，都默認(rèn)習(xí)慣使用ISO8859-1的字符編碼方式。
我們知道最早的字符編碼是 ASCII 碼，共表示128個字符，每個字符占用1B（1個字節(jié)）的大小，但實(shí)際只使用了其中的7位，高位補(bǔ)了0，如字符 'A'的編碼是 '0100 0001'，最高位是一個0來占位的。
后續(xù)有些國家和地區(qū)對 ASCII 碼進(jìn)行了擴(kuò)展，即把最高位的0給使用了，這樣就可以表示256個字符。但是這些擴(kuò)展互相間不兼容。
在 Windows 中運(yùn)行命令：charmap ，打開字符映射工具，字符集分別選中“Windows 西歐”和“Windows中歐”，可以清楚的看到，從 0X80 編碼以后（即擴(kuò)展出來的字符內(nèi)容），二者出現(xiàn)很大的不同，西歐字符集中的一些字符，在中歐字符集中就根本沒有出現(xiàn)。也就是說，同樣的編碼如果使用不同的字符集解碼，可能產(chǎn)生不同的字符顯示，這就是亂碼形成的很大根源，說白了就是一句話：編碼和解碼不一致。
于是大牛出現(xiàn)了- ISO（國際標(biāo)準(zhǔn)化組織），他制定了一套統(tǒng)一的標(biāo)準(zhǔn)，即 ISO8859 字符集系列，分別把西歐、東歐、南歐、北歐等字符集分別編號為 ISO8859-1、ISO8859-2、ISO8859-3、ISO8859-4等。其中，最常用的就是 ISO8859-1 西歐這個標(biāo)準(zhǔn)，也稱Latin-1。
由于“悟空”二字的 UTF-8 編碼是： E6 82 9F E7 A9 BA ，這六個字節(jié)如果用西歐的 ISO8859-1來一個字節(jié)一個字節(jié)的解碼，每個字節(jié)就對應(yīng)了一個西歐的字符。這些字符就是我們從錯誤提示信息中所看到的亂碼了。
*請認(rèn)真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
