共計 3787 個字符，預計需要花費 10 分鐘才能閱讀完成。
這期內容當中丸趣 TV 小編將會給大家帶來有關如何進行 mysql 亂碼產生的探討，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
實驗一
1。首先，在下面情況下：
mysql show variables like character_set_%
+————————–+—————————————+
| Variable_name | Value |
+————————–+—————————————+
| 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 |
| character_sets_dir | D:\Programs\mysql5045\share\charsets\ |
+————————–+—————————————+
建表，并加入 3 個記錄：大，阿，愛
2。set character_set_results=utf8;
則顯示：(cmd 窗口中，cmd 窗口代碼頁 936)
大 - 麓貿
阿 - 擄壟
愛 - 擄廬
分析編碼：
大 U：5927，GBK：B4F3
麓 U：9E93，GBK：C2B4
貿 U：8D38，GBK：C3B3
阿 U：963F，GBK：B0A2
擄 U：63B3，GBK：C2B0
壟 U：5784，GBK：C2A2
愛 U：7231，GBK：B0AE
擄 U：63B3，GBK：C2B0
廬 U：5E90，GBK：C2AE
3。改成 set character_set_results=gb2312;
一樣是亂碼
4。結論：
亂碼的產生，是由于單字節向多字節擴展引起的。B0A2 如果作為單字節存儲（雖然表示的是 1 個漢字，但是因為是 latin1 單字節，所以認為 B0A2 是不相關的兩個字符），此時如果把 character_set_results 變成 utf8 多字節，那么數據庫 mysql 會試圖把每個單字節擴展成近似的（不知道具體的算法）雙字節。所以亂碼
反之，多字節向單字節轉換時，不會有變動，僅僅是原來 2 各字節表示的一個字符 lsquo;B0A2 rsquo; 變成了表示兩個字符而已。—- 這個說法經驗證是錯誤的。
數據庫存儲的內容（磁盤上，內存里）不會受 character_set_的影響，只是提交，查詢的過程中，受到字符集轉換的影響。
實驗二
1。
create table y (id int, name char(4)) default charset gb2312；
2。在不改變默認 character_set_ 是 latin1 的情況下，如果插入一個漢字，則顯示亂碼
3。改成 set names gb2312，顯示沒問題 (cmd 窗口中，cmd 窗口代碼頁 936)
4。我原以為如上述實驗 1 種的結論 2，“多字節向單字節轉換時，不會有變動”。所以我開始以為，set names gb2312 后，把 character_set_results 改成 latin1，顯示不會出問題。結果，
一個漢字，則顯示一個問號；兩個漢字，則顯示兩個問號的亂碼（估計一個問號代表一個字符）。也就是說，改成 character_set_results = latin1 后，多字節的數據存儲，在向單字節表示轉換時，mysql 把提出的信息“縮水了”，把兩個字節，換算成了一個字節。
5。如何，不讓 mysql 縮水呢，我想到了 character_set_results = binary；結果，果然顯示正常。
PS
開發的使用 mysql 的應用程序，是對應作為獨立的使用自己的 character_set_client 的字符集的
cmd 窗口登陸 mysql，也是作為一個獨立的，擁有自己 character_set_client 變量的應用
同理，打開不同的 cmd 窗口，都擁有獨自的 character_set_client 變量
實驗三 07/16/2010
1。建一個默認字符集 utf8 的表（用 navicat，在 utf8 的界面下 代碼頁 65001），并且插入 utf8 編碼的漢字; 大學;
2。切換到 mysql console（代碼頁 936）
3。set names gbk; 然后顯示剛才所建立的表，能正確現實嗎？—- 能！當然，只把 character_set_results 成 gbk，也能正常顯示
實驗四
1。mysql console（代碼頁 936）建立一個表 x3 (name char(32) )，默認字符集 default charset gbk;
2。默認環境變量
| 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 // 不知道對以下過程、分析是否有影響
character_set_client character_set_connection character_set_results 是 latin1 的情況下，插入數據：insert x3 values(大
顯示：ERROR 1406 (22001): Data too long for column name at row 1
3。set character_set_client=gbk; 然后 insert x3 values(大 插入沒有問題，但顯然，數據經過（character_set_connection=latin1）的轉換，已經是有損了
4。不管 character_set_results 設不設成 gbk，都不能正常顯示結果
5。set names gbk；則插入現實都沒問題。并且此時，一個 uf8 字符集的表的顯示也沒問題（實驗三）。而且進行連接查詢，亦沒問題。
6。當然，set names utf8，如果在一個 utf8 的軟件界面上，顯示輸出也沒問題 (navicat 驗證了)
7。如果設成 set names binary。在 936 代碼頁的顯示界面上，可以看到，x3 依然可以正常現實；但像實驗三那樣建的表就不能正常顯示了。
——–
分析第 2 點：Data too long for column name at row 1
我的 char 夠長，插入數據夠短，所以不是數據太長了。也就是說這個提示是錯誤的。
我知道，如果表 x3 默認字符集 是 latin1 的話，插入是沒問題的（一直以來都是這么玩的）；這是因為，雖然輸入端 mysql console 代碼頁是 936，但因為三個主環境變量 character_set_c% 都是 latin1，所以，mysql 認為 insert x3 values(大) 輸入的是 2 個字符 (當然, 如果從 utf8 界面輸入，可能就認為是輸入 3 個字符)。存儲的自然也是 2 個字符。顯示的時候也是顯示的 2 個字符，只不過 936 代碼頁把這兩個字符自然組合，顯示成漢字了（早期環境常見現象）。
當默認字符集變為 gbk 的時候，發生了什么？不知道。。。。。
實驗五
一個很狗屎的問題出現了：936 console
環境變量如 實驗一.1。
mysql set names latin1;
Query OK, 0 rows affected (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 values(乃
ERROR 1406 (22001): Data too long for column name at row 1
mysql
結論，我實在對實驗四中分析的第 3 點做出結論。character_set_system utf8 有關~~
上述就是丸趣 TV 小編為大家分享的如何進行 mysql 亂碼產生的探討了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注丸趣 TV 行業資訊頻道。
