mysql亂碼問題分析與解決方法
更新時間:2012年11月29日 11:18:15 作者:
開發(fā)過程中總避免不了遇到惡心的亂碼,或者由亂碼引發(fā)的一系列問題,這里簡要介紹一下自己遇到的亂碼問題和解決問題的過程中的想法以及大致的操作
開發(fā)過程中總避免不了遇到惡心的亂碼,或者由亂碼引發(fā)的一系列問題。出現(xiàn)亂碼是字符集的原因一般而言和邏輯沒有太大關(guān)系,也就是說整個系統(tǒng)大的方向沒有問題,小的地方出現(xiàn)了漏洞,進(jìn)而導(dǎo)致程序不能正常運行,所以說出現(xiàn)亂碼是一件令人非常很惡心的事情。這里簡要介紹一下自己遇到的亂碼問題和解決問題的過程中的想法以及大致的操作,我們要學(xué)會的是如何分析問題進(jìn)而解決問題,而不僅僅是照著網(wǎng)上的操作去一次次的解決眼前的困難,“魚”與“漁”的區(qū)別就在于此。
交代背景:
要實現(xiàn)的功能很簡單,用dom4J讀取XML文件然后借助Spring以及Hibernate將數(shù)據(jù)寫入到MySql數(shù)據(jù)庫(多表)中,當(dāng)然整個過程是由Spring控制事務(wù)一次性完成,有異常進(jìn)行回滾。
現(xiàn)象:在往數(shù)據(jù)庫里寫數(shù)據(jù)寫到一半的時候報錯,大致的錯誤信息是:記錄不是唯一。
分析和操作:
檢查了一遍自己的代碼,用Spring當(dāng)中的HibernateTemplete保存數(shù)據(jù),應(yīng)該沒有問題。
再次觀察現(xiàn)象:好像是外鍵約束的問題,因為每當(dāng)插入到帶有外鍵的表的時候數(shù)據(jù)死活錄入不進(jìn)去。
分析和操作:
既然是外鍵表的問題,首先應(yīng)該確定外鍵表中的內(nèi)容是什么,于是手動改數(shù)據(jù)庫隔離等級查看數(shù)據(jù),果然里面是亂碼!
問題:亂碼是怎么進(jìn)入數(shù)據(jù)庫的?
分析和操作:
要么讀取xml的時候就是亂碼,要么在往數(shù)據(jù)庫里寫的時候變成亂碼。再次斷點調(diào)試測試在程序中是否亂碼。
現(xiàn)象:在eclipse當(dāng)中打印出來信息沒有出現(xiàn)亂碼問題
分析與操作:
這就說明在程序中一切沒有問題,是數(shù)據(jù)庫的問題。于是先改數(shù)據(jù)庫鏈接字符串指定編碼,再改數(shù)據(jù)庫的編碼,再次斷點調(diào)試。
現(xiàn)象:數(shù)據(jù)庫中依然是亂碼,但是亂碼的形式換了,之前全是“?”現(xiàn)在是一些亂七八糟的文字。
分析和操作:
很明顯上面一系列修改編碼格式的操作起作用了,只是沒有修改對而已。再次檢查各項的編碼格式,沒有發(fā)現(xiàn)問題
問題一度陷入僵局……
尋求幫助:秋提出別用命令窗口了,太麻煩了,用第三方客戶端吧,于是換用第三方客戶端,奇怪的是客戶端顯示沒有問題!
分析和操作:
客戶端沒有問題命令窗口有問題,那就說明數(shù)據(jù)庫里已經(jīng)不是亂碼,亂碼可能是命令行顯示的問題。設(shè)置命令行顯示字符,果然顯示正常!再次測試數(shù)據(jù)導(dǎo)入----一切OK。
思考與總結(jié):
現(xiàn)象:其實在第一次修改完各項編碼的時候這個問題已經(jīng)算是解決了,但是由于當(dāng)時自己斷點調(diào)試的時候沒有讓程序執(zhí)行完所以一直認(rèn)為數(shù)據(jù)庫中依然是亂碼。
總結(jié):
應(yīng)該在每次調(diào)試的時候讓程序跑完,將錯誤的上下文環(huán)境模擬出來,而不是只關(guān)注錯誤本身。
現(xiàn)象:在這里涉及到編碼的地方有XML的編碼、dom4j的讀取編碼、數(shù)據(jù)庫編碼、數(shù)據(jù)庫連接字符串指定編碼、命令行窗口顯示編碼。這其中哪個沒有注意到問題也解決不了(這里自己沒有意識到最后一個)。
總結(jié):
全局觀的意思是把握每個控制變量,從開始到結(jié)束,有意識的跳出環(huán)境來做假設(shè)。
交代背景:
要實現(xiàn)的功能很簡單,用dom4J讀取XML文件然后借助Spring以及Hibernate將數(shù)據(jù)寫入到MySql數(shù)據(jù)庫(多表)中,當(dāng)然整個過程是由Spring控制事務(wù)一次性完成,有異常進(jìn)行回滾。
現(xiàn)象:在往數(shù)據(jù)庫里寫數(shù)據(jù)寫到一半的時候報錯,大致的錯誤信息是:記錄不是唯一。
分析和操作:
檢查了一遍自己的代碼,用Spring當(dāng)中的HibernateTemplete保存數(shù)據(jù),應(yīng)該沒有問題。
再次觀察現(xiàn)象:好像是外鍵約束的問題,因為每當(dāng)插入到帶有外鍵的表的時候數(shù)據(jù)死活錄入不進(jìn)去。
分析和操作:
既然是外鍵表的問題,首先應(yīng)該確定外鍵表中的內(nèi)容是什么,于是手動改數(shù)據(jù)庫隔離等級查看數(shù)據(jù),果然里面是亂碼!
問題:亂碼是怎么進(jìn)入數(shù)據(jù)庫的?
分析和操作:
要么讀取xml的時候就是亂碼,要么在往數(shù)據(jù)庫里寫的時候變成亂碼。再次斷點調(diào)試測試在程序中是否亂碼。
現(xiàn)象:在eclipse當(dāng)中打印出來信息沒有出現(xiàn)亂碼問題
分析與操作:
這就說明在程序中一切沒有問題,是數(shù)據(jù)庫的問題。于是先改數(shù)據(jù)庫鏈接字符串指定編碼,再改數(shù)據(jù)庫的編碼,再次斷點調(diào)試。
現(xiàn)象:數(shù)據(jù)庫中依然是亂碼,但是亂碼的形式換了,之前全是“?”現(xiàn)在是一些亂七八糟的文字。
分析和操作:
很明顯上面一系列修改編碼格式的操作起作用了,只是沒有修改對而已。再次檢查各項的編碼格式,沒有發(fā)現(xiàn)問題
問題一度陷入僵局……
尋求幫助:秋提出別用命令窗口了,太麻煩了,用第三方客戶端吧,于是換用第三方客戶端,奇怪的是客戶端顯示沒有問題!
分析和操作:
客戶端沒有問題命令窗口有問題,那就說明數(shù)據(jù)庫里已經(jīng)不是亂碼,亂碼可能是命令行顯示的問題。設(shè)置命令行顯示字符,果然顯示正常!再次測試數(shù)據(jù)導(dǎo)入----一切OK。
思考與總結(jié):
現(xiàn)象:其實在第一次修改完各項編碼的時候這個問題已經(jīng)算是解決了,但是由于當(dāng)時自己斷點調(diào)試的時候沒有讓程序執(zhí)行完所以一直認(rèn)為數(shù)據(jù)庫中依然是亂碼。
總結(jié):
應(yīng)該在每次調(diào)試的時候讓程序跑完,將錯誤的上下文環(huán)境模擬出來,而不是只關(guān)注錯誤本身。
現(xiàn)象:在這里涉及到編碼的地方有XML的編碼、dom4j的讀取編碼、數(shù)據(jù)庫編碼、數(shù)據(jù)庫連接字符串指定編碼、命令行窗口顯示編碼。這其中哪個沒有注意到問題也解決不了(這里自己沒有意識到最后一個)。
總結(jié):
全局觀的意思是把握每個控制變量,從開始到結(jié)束,有意識的跳出環(huán)境來做假設(shè)。
相關(guān)文章
Mysql大數(shù)據(jù)量查詢優(yōu)化思路詳析
這篇文章主要介紹了Mysql大數(shù)據(jù)量查詢優(yōu)化思路,Mysql大表查詢優(yōu)化,理論上千萬級別以下的數(shù)據(jù)量Mysql單表查詢性能處理都是可以的。下文我們就來看看具體得思路解析2022-01-01mysql 5.7 數(shù)據(jù)庫安裝步驟個人總結(jié)
這篇文章主要介紹了mysql 數(shù)據(jù)庫安裝步驟個人總結(jié),需要的朋友可以參考下2017-09-09MySQL優(yōu)化之如何寫出高質(zhì)量sql語句
在數(shù)據(jù)庫日常維護(hù)中,最常做的事情就是SQL語句優(yōu)化,因為這個才是影響性能的最主要因素。這篇文章主要給大家介紹了關(guān)于MySQL優(yōu)化之如何寫出高質(zhì)量sql語句的相關(guān)資料,需要的朋友可以參考下2021-05-05