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