本篇文章主要給大家介紹mysql中文數(shù)據(jù)的相關問題，希望對需要的朋友有所幫助！

推薦參考教程：《mysql教程》

中文數(shù)據(jù)問題

中文數(shù)據(jù)問題的本質(zhì)就是字符集的問題。

由于計算機僅識別二進制數(shù)據(jù)，而且人類則更傾向于識別字符（符號），因此就需要一個二進制與字符的對應關系，也就是字符集。

在咱們通過 MySQL 數(shù)據(jù)庫的客戶端向服務器插入中文數(shù)據(jù)的時候，有可能失敗，原因則可能是客戶端和服務器的字符集設置不同導致的，例如：

• 客戶端的字符集為gbk，則一個中文字符，對應兩個字節(jié)；

• 服務器的字符集為utf8，則一個中文字符，對應三個字節(jié)。

這樣顯然會在編碼轉換的過程中出現(xiàn)問題，從而導致插入中文數(shù)據(jù)失敗。

由于所有的數(shù)據(jù)庫服務器表現(xiàn)的一些特性都是通過服務器端的變量來保持的，因此系統(tǒng)會先讀取自己的變量，看看具體的表現(xiàn)形式。這樣的話，咱們就可以通過以下語句查看服務器到底識別哪些字符集：

-- 查看服務器識別的全部字符集show character set;

通過以上查詢，咱們會發(fā)現(xiàn)：服務器是萬能的，其支持所有字符集。

既然服務器支持這么多字符集，總會有一種是服務器默認的和客戶端打交道的字符集。因此，咱們可以通過以下語句查看服務器默認的對外處理的字符集：

-- 查看服務器默認的對外處理的字符集show variables like 'character_set%';

• 標注1：服務器默認的客戶端傳來的數(shù)據(jù)字符集為utf8；

• 標注2：連接層字符集為utf8；

• 標注3：當前數(shù)據(jù)庫的字符集為utf8；

• 標注4：服務器默認的對外處理的字符集utf8.

通過以上查詢，咱們會發(fā)現(xiàn)：服務器默認的對外處理的字符集是utf8.

那么反過來，咱們在通過客戶端的屬性查看客戶端支持的字符集：

顯然，咱們已經(jīng)找到了問題的根源，確實是：客戶端支持的字符集為gbk，而服務器默認的對外處理的字符集為utf8，因此產(chǎn)生矛盾。

既然問題已經(jīng)找到了，那么解決方案就是：修改服務器默認接收的字符集為gbk.

-- 修改服務器默認接收的字符集為 GBK（不區(qū)分大小寫）set character_set_client = gbk;

這樣的話，咱們再插入中文數(shù)據(jù)的時候，就會插入成功啦！But，在咱們查看數(shù)據(jù)的時候，又發(fā)現(xiàn)了一個問題，就是之前咱們插入的中文數(shù)據(jù)顯示亂碼啦！不過這也正常，因為查詢的時候，數(shù)據(jù)的來源是服務器（utf8），解析數(shù)據(jù)的是客戶端，而客戶端僅識別gbk格式的數(shù)據(jù)，顯示亂碼也就在意料之中啦！

因此，解決方案就是：修改服務器給客戶端的數(shù)據(jù)字符集為gbk.

-- 修改服務器給客戶端的數(shù)據(jù)字符集為 GBK（不區(qū)分大小寫）set character_set_results = gbk;

如上圖所示，向服務器插入中文數(shù)據(jù)的問題已經(jīng)解決啦！

此外，咱們之前使用的 SQL 語句：

-- 修改的只是會話級別，即當前客戶端當次連接有效，關閉后失效set 變量 = 值;

這樣的話，每當咱們重啟客戶端的時候，都要依次重新進行設置，比較麻煩，因此咱們可以使用快捷的設置方式，即：

set names 字符集;

例如，

/**
* 恒等于 set character_set_client = gbk;
* 恒等于 set character_set_results = gbk;
* 恒等于 set character_set_connection = gbk;
*/set names gbk;

表示上述一條語句，將同時改變?nèi)齻�變量的值。其中，connection為連接層，是字符集轉換的中間者，如果其和client和results的字符集一致，則效率更高，不一致也沒有關系。

以上就是MySQL 教程之中文數(shù)據(jù)問題的詳細內(nèi)容，更多請關注php中文網(wǎng)其它相關文章！