昨天通過mysqldump，將數據庫字符集轉換到gbk，過程算得上頗為順利。但再次意外的是，居然沒有解決問題。當數據量比較多的時侯，mysqldump轉換字符集不太可靠，特別是采用外部工具修改大文件里面的字符名稱，可能會導致一些不該改的也改了，結果幾萬條sql在插入過程中，可能就會出錯。空的小的數據庫很容易處理，大的話，文件達到一個G以上，不可能作任何編輯。所以要分兩步走，先將它dump出表文件，然后再dump出數據。表文件容易修改，數據文件不用修改。

這樣處理后，重新生成數據庫，mysql < .sql文件，就搞完了。原來的latin1的原庫仍然備份著，以備解決可能出現的問題。沒想到真出了問題。如同上一次一樣，手工檢驗mysql --default_charater_set=字符集，證明是gbk，可以在CRT中檢索。　上一次是可以檢索的字符集是latin1。

然后采用測試頁面jdbc:uri檢索，同樣的編碼，上一次是需要將<%contentype%>設為latin1，才能讀出了正確的latin1字符，同時卻把瀏覽器搞糊涂了，需要手工指定簡體中文，——這不可接受。因此預計如果完全是gbk，就不需要修改contentype，這樣就可以直接顯示中文。誰知道，顯示出來是問號！前后完全不一致。很大的疑問是，如果我手工可以訪問正常，不能證明j正常，那又說明了什么？1+1被發現不等于2，就會有點投降的感覺，檢索網上資料，從來沒有人碰到過這種情況。

一次次地試，修改這里，修改那里，查找網上所有資料，無一對頭。不過也漸漸更深入地了解到內部的過程。以前都沒有怎么注意，也發現網上很多人的經驗，也是知其然“忽然行了”，不知其所以然。無意中想到，“defaultset那里改一改，看看會不會出奇跡？”，改到utf-8，忽然好了。useUnicode=true&characterEncoding=utf-8原因呢？需要重新組織起來。