前段時間學習JDBC，要連接mysql獲取數據。按照老師的樣例數據，要存一些名字之類的信息，用的都是英文名，我當時就不太想用英文，就把我室友的名字存了進去，嘿嘿，結果，出問題了。
連接數據庫語句：
static final String DB_URL = "jdbc:mysql://localhost/filemanagement";
查詢語句：
private static final String theUserQuery = "SELECT name, password, role FROM userinfo WHERE name = ?";
我是用我的名字做的查詢，NullPointerException，很明顯，沒有用我的名字查到對應的數據，而數據庫中是存在的。這是為什麼呢？
百度到的答案是中文亂碼，解決方案是，修改連接數據庫語句為：
static final String DB_URL = "jdbc:mysql://localhost/filemanagement?useUnicode=true&characterEncoding=GBK";
重試！
可以了！但這是為什麼呢？那兩個參數是什麼？為什麼加上之後就解決問題了？
這兩個參數解釋如下：
兩個參數的缺省值都是false。也就是說我們在連接mysql的時候指定了連接使用的字符集後，一切就正常了。但我還是不太了解其中的機制，所以繼續查。
原來Mysql連接進行查詢等操作時存在一個字符集轉換過程：
1. MySQL Server收到請求時將請求數據從character_set_client轉換為character_set_connection；
2. 進行內部操作前將請求數據從character_set_connection轉換為內部操作字符集，其確定方法如下：
• 使用每個數據字段的CHARACTER SET設定值；
• 若上述值不存在，則使用對應數據表的DEFAULT CHARACTER SET設定值(MySQL擴展，非SQL標準)；
• 若上述值不存在，則使用對應數據庫的DEFAULT CHARACTER SET設定值；
• 若上述值不存在，則使用character_set_server設定值。
3. 將操作結果從內部操作字符集轉換為character_set_results。
這些character set代表什麼呢？
character_set_server：默認的內部操作字符集
character_set_client：客戶端來源數據使用的字符集
character_set_connection：連接層字符集
character_set_results：查詢結果字符集
character_set_database：當前選中數據庫的默認字符集
character_set_system：系統元數據(字段名等)字符集
還查到了一些常見問題，雖然和我的問題不太一樣，但很有參考意義。
• 向默認字符集為utf8的數據表插入utf8編碼的數據前沒有設置連接字符集，查詢時設置連接字符集為utf8
插入時根據MySQL服務器的默認設置，character_set_client、character_set_connection和character_set_results均為latin1；
插入操作的數據將經過latin1=>latin1=>utf8的字符集轉換過程，這一過程中每個插入的漢字都會從原始的3個字節變成6個字節保存；
查詢時的結果將經過utf8=>utf8的字符集轉換過程，將保存的6個字節原封不動返回，產生亂碼……
• 向默認字符集為latin1的數據表插入utf8編碼的數據前設置了連接字符集為utf8
插入時根據連接字符集設置，character_set_client、character_set_connection和character_set_results均為utf8；
插入數據將經過utf8=>utf8=>latin1的字符集轉換，若原始數據中含有/u0000~/u00ff範圍以外的Unicode字符，會因為無法在latin1字符集中表示而被轉換為“?”(0x3F)符號，以後查詢時不管連接字符集設置如何都無法恢復其內容了。
（此部分摘自鳥哥的blog，稍後附上鍊接）
我數據庫的表都是設置的utf8編碼，但我第一次連接的時候沒有設置連接字符集，所以默認為latin1，經過了從utf8=>latin1的轉換，所以產生亂碼。我第二次用的GBK編碼，也沒用utf8編碼，為什麼也可以了呢？其實是一個道理，中文不在latin1的編碼中可是在GBK和utf8中，所以不會出問題。
以上就是為大家整理的關於JDBC連接mysql亂碼異常的解決辦法，如果大家還有任何不明白的地方可以在下方的留言區討論。