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

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

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

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