快捷導航

JDBC連接mysql亂碼異常問題處理總結(jié)

更新時間：2017年12月08日 09:49:15 作者：追求技術(shù)的萌新

這篇文章主要介紹了JDBC連接mysql亂碼異常問題處理的辦法和思路，有需要的朋友參考學習下。

前段時間學習JDBC，要連接mysql獲取數(shù)據(jù)。按照老師的樣例數(shù)據(jù)，要存一些名字之類的信息，用的都是英文名，我當時就不太想用英文，就把我室友的名字存了進去，嘿嘿，結(jié)果，出問題了。

連接數(shù)據(jù)庫語句：

static final String DB_URL = "jdbc:mysql://localhost/filemanagement";

查詢語句：

private static final String theUserQuery = "SELECT name, password, role FROM userinfo WHERE name = ?";

我是用我的名字做的查詢，NullPointerException，很明顯，沒有用我的名字查到對應(yīng)的數(shù)據(jù)，而數(shù)據(jù)庫中是存在的。這是為什么呢？

百度到的答案是中文亂碼，解決方案是，修改連接數(shù)據(jù)庫語句為：

static final String DB_URL = "jdbc:mysql://localhost/filemanagement?useUnicode=true&characterEncoding=GBK";

重試！

可以了！但這是為什么呢？那兩個參數(shù)是什么？為什么加上之后就解決問題了？

這兩個參數(shù)解釋如下：

兩個參數(shù)的缺省值都是false。也就是說我們在連接mysql的時候指定了連接使用的字符集后，一切就正常了。但我還是不太了解其中的機制，所以繼續(xù)查。

原來Mysql連接進行查詢等操作時存在一個字符集轉(zhuǎn)換過程：

1. MySQL Server收到請求時將請求數(shù)據(jù)從character_set_client轉(zhuǎn)換為character_set_connection；

2. 進行內(nèi)部操作前將請求數(shù)據(jù)從character_set_connection轉(zhuǎn)換為內(nèi)部操作字符集，其確定方法如下：

• 使用每個數(shù)據(jù)字段的CHARACTER SET設(shè)定值；

• 若上述值不存在，則使用對應(yīng)數(shù)據(jù)表的DEFAULT CHARACTER SET設(shè)定值(MySQL擴展，非SQL標準)；

• 若上述值不存在，則使用對應(yīng)數(shù)據(jù)庫的DEFAULT CHARACTER SET設(shè)定值；

• 若上述值不存在，則使用character_set_server設(shè)定值。

3. 將操作結(jié)果從內(nèi)部操作字符集轉(zhuǎn)換為character_set_results。

這些character set代表什么呢？

character_set_server：默認的內(nèi)部操作字符集

character_set_client：客戶端來源數(shù)據(jù)使用的字符集

character_set_connection：連接層字符集

character_set_results：查詢結(jié)果字符集

character_set_database：當前選中數(shù)據(jù)庫的默認字符集

character_set_system：系統(tǒng)元數(shù)據(jù)(字段名等)字符集

還查到了一些常見問題，雖然和我的問題不太一樣，但很有參考意義。

• 向默認字符集為utf8的數(shù)據(jù)表插入utf8編碼的數(shù)據(jù)前沒有設(shè)置連接字符集，查詢時設(shè)置連接字符集為utf8

– 插入時根據(jù)MySQL服務(wù)器的默認設(shè)置，character_set_client、character_set_connection和character_set_results均為latin1；

– 插入操作的數(shù)據(jù)將經(jīng)過latin1=>latin1=>utf8的字符集轉(zhuǎn)換過程，這一過程中每個插入的漢字都會從原始的3個字節(jié)變成6個字節(jié)保存；

– 查詢時的結(jié)果將經(jīng)過utf8=>utf8的字符集轉(zhuǎn)換過程，將保存的6個字節(jié)原封不動返回，產(chǎn)生亂碼……

• 向默認字符集為latin1的數(shù)據(jù)表插入utf8編碼的數(shù)據(jù)前設(shè)置了連接字符集為utf8

– 插入時根據(jù)連接字符集設(shè)置，character_set_client、character_set_connection和character_set_results均為utf8；

– 插入數(shù)據(jù)將經(jīng)過utf8=>utf8=>latin1的字符集轉(zhuǎn)換，若原始數(shù)據(jù)中含有\(zhòng)u0000~\u00ff范圍以外的Unicode字符，會因為無法在latin1字符集中表示而被轉(zhuǎn)換為“?”(0x3F)符號，以后查詢時不管連接字符集設(shè)置如何都無法恢復(fù)其內(nèi)容了。

（此部分摘自鳥哥的blog，稍后附上鏈接）

我數(shù)據(jù)庫的表都是設(shè)置的utf8編碼，但我第一次連接的時候沒有設(shè)置連接字符集，所以默認為latin1，經(jīng)過了從utf8=>latin1的轉(zhuǎn)換，所以產(chǎn)生亂碼。我第二次用的GBK編碼，也沒用utf8編碼，為什么也可以了呢？其實是一個道理，中文不在latin1的編碼中可是在GBK和utf8中，所以不會出問題。

以上就是為大家整理的關(guān)于JDBC連接mysql亂碼異常的解決辦法，如果大家還有任何不明白的地方可以在下方的留言區(qū)討論。

您可能感興趣的文章: