相信大家在開發(fā)后臺(tái)的過程中都遇到過中文亂碼的問題，今天我就來講講其中的原因。 我這建了3張表，test_latin1,test_utf8,test_gbk,表結(jié)構(gòu)如下 +-------+----------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra |
+-------+----------+------+-----+---------+-------+
| name | char(32) | YES | | NULL | |
+-------+----------+------+-----+---------+-------+
我的前端是gbk的編碼
執(zhí)行下面的語句
set names 'latin1'
insert into test_latin1 set name='王';('王'字是GBK編碼)
select name from test_latin1;
結(jié)果是否為亂碼？
執(zhí)行下面的語句
set names 'gbk' insert into test_latin1 set name='王';('王'字是GBK編碼) select name from test_latin1; 結(jié)果是否為亂碼？ 執(zhí)行下面的語句 set names 'latin1' insert into test_utf8 set name='王';('王'字是GBK編碼) select name from test_utf8 ; 結(jié)果是否為亂碼？ 我們舉個(gè)例子，假設(shè)一個(gè)漢字的字符編碼為0xFFFF，它在屏幕上能夠正常顯示，如果漢字存入數(shù)據(jù)庫的時(shí)候和從數(shù)據(jù)庫中取出的時(shí)候，編碼一致，那么它肯定不是亂碼。反過來，如果輸出的時(shí)候是亂碼，那么它肯定被轉(zhuǎn)碼了，至于為什么被轉(zhuǎn)碼了，我們得看看mysql里面做了什么(mysql難道會(huì)把無碼片變成了有碼片？) 首先mysql里面有2個(gè)概念，一個(gè)叫character set,一個(gè)叫collation。我們先說說character set。字符集就是數(shù)字，英文字符，漢字等編碼格式，我們常見的是utf8,gbk,gb2312。mysql里面比較復(fù)雜，有4個(gè)東西跟它有關(guān)，分別是character_set_client，character_set_connection，character_set_database，character_set_results。set names (latin1)其實(shí)就是character_set_client=latin1，character_set_connection=latin1，character_set_results=latin1，它的流程是character_set_client ==> character_set_connection ==> Table Character ==> character_set_results。 我們按照上面的流程，來分析第一個(gè)問題。 set names 'latin1'----執(zhí)行了character_set_client=latin1，character_set_connection=latin1，character_set_results=latin1; insert into test_latin1 set name='王';這句話，mysql做了什么事呢？首先，character_set_client,它會(huì)把王字的編碼當(dāng)成latin1的編碼傳遞給character_set_connection（此時(shí)不會(huì)轉(zhuǎn)碼），character_set_connection會(huì)把編碼傳遞給Table Character,因?yàn)楸肀旧硎莑atin1，所以此時(shí)也不需要轉(zhuǎn)碼，select name from test_latin1;mysql會(huì)把test_latin1中的編碼傳遞給前端，此時(shí)也不需要轉(zhuǎn)碼，所以，走個(gè)流程下來，我們輸入的是什么編碼，輸出的還是相同的編碼，因此，第一個(gè)問題的答案是不會(huì)是亂碼。我畫個(gè)流程圖latin1==>latin1==>latin1==>latin1,沒有轉(zhuǎn)碼的過程 我們在來看第二個(gè)問題。 set names 'test_gbk'----執(zhí)行了character_set_client=gbk，character_set_connection=gbk，character_set_results=gbk; insert into test_latin1 set name='王';character_set_client,它會(huì)把王字的編碼當(dāng)成gbk的編碼傳遞給character_set_connection（此時(shí)不會(huì)轉(zhuǎn)碼）,character_set_connection會(huì)把編碼傳遞給Table Character,因?yàn)楸硎莑anti1的編碼格式，這個(gè)過程的時(shí)候就會(huì)進(jìn)行轉(zhuǎn)碼，但是latin1的字符集小于gbk的字符集，所以它會(huì)找不到對應(yīng)字符的編碼，此時(shí)會(huì)以？代替。select name from test_latin1，此時(shí)會(huì)從latin1轉(zhuǎn)碼成gbk,但是此時(shí)latin1已經(jīng)是錯(cuò)誤的數(shù)據(jù)了，所以得到的gbk編碼也是錯(cuò)誤的了。流程gbk==>gbk==>latin1==>gbk,其中g(shù)bk==>latin1出了問題，我們select出來的數(shù)據(jù)也就不可能是輸入時(shí)候的數(shù)據(jù)了。因此，這個(gè)問題的答案是亂碼。 第三個(gè)。 set names 'test_latin1' insert into test_utf8 set name='王';character_set_client,它會(huì)把王字的編碼當(dāng)成latin1的編碼傳遞給character_set_connection（此時(shí)不會(huì)轉(zhuǎn)碼）,character_set_connection會(huì)把編碼傳遞給Table Character,此時(shí)表是utf8的格式，因此會(huì)進(jìn)行轉(zhuǎn)碼，latin1==>utf8,因?yàn)閡tf8的字符集>latin1字符集，因此，轉(zhuǎn)碼正常。select name from test_utf8;會(huì)從utf8轉(zhuǎn)碼成latin1,此時(shí)可以轉(zhuǎn)碼成功，因此我們最終得到的和輸入的時(shí)候是一致的，因此答案不是亂碼。流程latin1==>latin1==>utf8==>latin1,從小的字符集到大的字符集再到小的字符集，轉(zhuǎn)碼是不會(huì)有問題的。 屁話了這么多，無非想告訴大家一個(gè)萬精油方法，表創(chuàng)建的字符集和set names都設(shè)置成同一個(gè)字符集，就基本可以滿足輸入數(shù)據(jù)不會(huì)在轉(zhuǎn)換過程中失真，也就是說輸入是什么，輸出就是什么。建議有中文的都設(shè)置成utf8字符集，一勞永逸。
posted on 2012-11-26 19:56
梨樹陽光 閱讀(2538)
評論(2) 編輯 收藏 引用 所屬分類:
數(shù)據(jù)庫