mysql 亂碼產(chǎn)生探討

1、mysql 亂碼產(chǎn)生探討亂碼的產(chǎn)生，是因?yàn)閱巫止?jié)向多字節(jié)擴(kuò)展引起的。b0a2 假如作為單字節(jié)存儲(chǔ)（雖然表示的是1個(gè)漢字，但是由于是latin1單字節(jié)，所以認(rèn)為b0a2是不相關(guān)的兩個(gè)字符），此時(shí)假如把character_set_results變成utf8多字節(jié)，那么數(shù)據(jù)庫(kù)mysql 會(huì)試圖把每個(gè)單字節(jié)擴(kuò)展成近 的（不知道詳細(xì)的算法）雙字節(jié)。所以亂碼 反之，多字節(jié)向單字節(jié)轉(zhuǎn)換時(shí)，不會(huì)有變動(dòng)，僅僅是本來(lái)2各字節(jié)表示的一個(gè)字符b0a2變成了表示兩個(gè)字符而已。- 這個(gè)說(shuō)法閱歷證是錯(cuò)誤的。 數(shù)據(jù)庫(kù)存儲(chǔ)的內(nèi)容（磁盤上，內(nèi)存里）不會(huì)受character_set_的影響，只是提交，查詢的過(guò)程中，受到字符集轉(zhuǎn)換的

2、影響。 試驗(yàn)二 1。 create table y ( int, name char(4) default charset gb2312； 2。在不轉(zhuǎn)變默認(rèn)character_set_ 是 latin1的狀況下，假如插入一個(gè)漢字，則顯示亂碼 3。改成 set names gb2312，顯示沒(méi)問(wèn)題(cmd窗口中，cmd窗口代碼頁(yè)936) 4。我原以為如上述試驗(yàn)1種的結(jié)論2，“多字節(jié)向單字節(jié)轉(zhuǎn)換時(shí)，不會(huì)有變動(dòng)”。所以我開(kāi)頭以為，set names gb2312 后，把 character_set_results 改成latin1，顯示不會(huì)出問(wèn)題。結(jié)果， 一個(gè)漢字，則顯示一個(gè)問(wèn)號(hào)；兩個(gè)漢字，則顯示兩

3、個(gè)問(wèn)號(hào)的亂碼（估量一個(gè)問(wèn)號(hào)代表一個(gè)字符）。也就是說(shuō)，改成character_set_results = latin1后，多字節(jié)的數(shù)據(jù)存儲(chǔ)，在向單字節(jié)表示轉(zhuǎn)換時(shí)，mysql把提出的信息“縮水了”，把兩個(gè)字節(jié)，換算成了一個(gè)字節(jié)。 。如何，不讓mysql縮水呢，我想到了character_set_results = binary；結(jié)果，果真顯示正常。 ps 開(kāi)發(fā)的用法mysql的應(yīng)用程序，是對(duì)應(yīng)作為自立的用法自己的character_set_client的字符集的cmd 窗口登陸mysql，也是作為一個(gè)自立的，擁有自己character_set_client變量的應(yīng)用同理，打開(kāi)不同的cmd窗口，都擁

4、有獨(dú)自的character_set_client變量 試驗(yàn)三 07/16/2010 1。建一個(gè)默認(rèn)字符集utf8的表（用navi ，在utf8的界面下 代碼頁(yè)65001），并且插入utf8編碼的漢字高校 2。切換到mysql console（代碼頁(yè)936） 3。set names gbk; 然后顯示剛才所建立的表，能正確現(xiàn)實(shí)嗎？ - 能！固然，只把character_set_results 成 gbk，也能正常顯示 試驗(yàn)四 1。mysql console（代碼頁(yè)936）建立一個(gè)表x3 ( name char(32) )，默認(rèn)字符集 default charset gbk; 2。默認(rèn)環(huán)境變量 |

5、 character_set_client | latin1 | character_set_connection | latin1 | character_set_database | latin1 | character_set_filesystem | binary | character_set_results | latin1 | character_set_server | latin1 | character_set_system |utf8 /不知道對(duì)以下過(guò)程、分析是否有影響 character_set_client character_set_connection chara

6、cter_set_results 是latin1的狀況下，插入數(shù)據(jù)：insert x3 values('大'); 顯示：error 1406 (22001): data too long for umn 'name' at row 1 3。set character_set_client=gbk;然后 insert x3 values('大');插入沒(méi)有問(wèn)題，但明顯，數(shù)據(jù)經(jīng)過(guò) （character_set_connection=latin1）的轉(zhuǎn)換，已經(jīng)是有損了 4。不管 character_set_results 設(shè)不設(shè)成 gbk，都不能正常顯

7、示結(jié)果 5。set names gbk；則插入現(xiàn)實(shí)都沒(méi)問(wèn)題。并且此時(shí)，一個(gè)uf8字符集的表的顯示也沒(méi)問(wèn)題（試驗(yàn)三）。而且舉行銜接查詢，亦沒(méi)問(wèn)題。 6。固然，set names utf8，假如在一個(gè)utf8的軟件界面上，顯示輸出也沒(méi)問(wèn)題(navicat 驗(yàn)證了) 7。假如設(shè)成 set names binary。在936代碼頁(yè)的顯示界面上，可以看到，x3依舊可以正?，F(xiàn)實(shí)；但像試驗(yàn)三那樣建的表就不能正常顯示了。 - 分析第2點(diǎn)：data too long for column 'name' at row 1 我的char 夠長(zhǎng)，插入數(shù)據(jù)夠短，所以不是數(shù)據(jù)太長(zhǎng)了。也就是說(shuō)這個(gè)提醒是錯(cuò)誤

8、的。我知道，假如表x3 默認(rèn)字符集 是latin1的話，插入是沒(méi)問(wèn)題的（向來(lái)以來(lái)都是這么玩的）；這是由于，雖然輸入端mysql console 代碼頁(yè)是936，但由于三個(gè)主環(huán)境變量character_set_c%都是latin1，所以，mysql 認(rèn)為insert x3 values('大') 輸入的是2個(gè)字符(固然,假如從utf8界面輸入，可能就認(rèn)為是輸入3個(gè)字符)。存儲(chǔ)的自然也是2個(gè)字符。顯示的時(shí)候也是顯示的2個(gè)字符，只不過(guò)936代碼頁(yè)把這兩個(gè)字符自然組合，顯示成漢字了（早期dos環(huán)境常見(jiàn)現(xiàn)象）。當(dāng)默認(rèn)字符集變?yōu)間bk的時(shí)候，發(fā)生了什么？不知道。 試驗(yàn)五 一個(gè)很狗屎的問(wèn)題浮

9、現(xiàn)了：936 mysql console 環(huán)境變量如 試驗(yàn)一.1。 mysql set names latin1; query ok, 0 rows affect (0.00 sec) mysql create table x4 ( - name char(32) primary key); query ok, 0 rows affected (0.09 sec) mysql drop table x4; query ok, 0 rows affected (0.06 sec) mysql create table x4 ( - name char(32) primary key) default charset utf8; query ok, 0 rows affected (0.10 sec) mysql insert x4 values('乃'); query ok, 1 row affected (0.04 sec) mysql create table x5 ( - name char(32) primary key) default charset gbk; query ok, 0 rows affected (0.09 sec) mysql insert x5 val