1、先來查看一個建表語句

create table student(
  sid int primary key aotu_increment,
  sname varchar(20) not null,
  age int
)charset=utf8;

思考一個問題：

• 當我們建表時，不指定charset=utf8的時候，此時插入中文，為什么會報錯呢？
• 當指定charset=utf8后，再次插入中文，為什么又可以插入中文，并且不亂碼呢？

2、查看CMD黑窗口的字符集

打開CMD黑窗口–>鼠標放在窗口最上方–>點擊鼠標右鍵–>屬性–>點擊選項

通過上圖可以知道：CMD中輸入文字使用的字符編碼是GBK。同時你在保存文件的時候，經(jīng)常會看到ANSI字符集，這個代表的是本地字符集，我們在中國，本地字符集使用的就都是GBK編碼。

3、你注意這個問題了嗎？

客戶端client輸入的字符，都是采用GBK編碼的。mysql服務器存儲的字符又是UTF8編碼的。那么，我們對數(shù)據(jù)庫、表進行增刪改查，最后返回到客戶端界面中，要想保證字符不亂碼，肯定是經(jīng)過了"編碼轉(zhuǎn)換過程的"。我要問的是，究竟是什么東西完成了這個編碼的轉(zhuǎn)換過程的？

4、你不熟悉的幾個mysql操作命令

-- 查看數(shù)據(jù)庫支持的所有的字符集(這句命令自己下去操作)。
mysql> show character set;
-- 查看系統(tǒng)當前狀態(tài)，里面可以看到部分字符集設置。
mysql> status;
-- 查看系統(tǒng)字符集設置，包括所有的字符集設置
mysql> show variables like '%char%';

操作結果如下：

通過上圖我們可以看到有一個叫做"connection"的東西，中文名叫做"連接器"。"連接器"就是用來進行"編碼轉(zhuǎn)換過程"的。

1）連接器的特性

① “連接器的作用”：

連接客戶端與服務端，進行字符集的轉(zhuǎn)換。連接器有這種自動轉(zhuǎn)換的功能。

② “連接器的工作流程”：
Ⅰ首先，客戶端的字符先發(fā)給連接器，連接器選擇一種編碼將其轉(zhuǎn)換(轉(zhuǎn)換之后的編碼， 與連接器的編碼格式一致)，進行臨時存儲。
Ⅱ 接著，連接器再次轉(zhuǎn)換成與服務器一致的編碼，并最終存儲在服務器中。
Ⅲ 然后，服務器返回的結果，再次先通過連接器，連接器仍然是選擇一種編碼將其轉(zhuǎn)換(轉(zhuǎn)換之后的編碼， 與連接器的編碼格式一致)，進行臨時存儲。
Ⅳ 最后，連接器再將結果轉(zhuǎn)化為與客戶端一致的字符集，就可以在客戶端正常顯示了。

2）圖示說明連接器connection的作用

圖一：

圖一說明如下：

圖二：

圖二說明如下：

5、對上述兩個圖的實戰(zhàn)演示

1）首先，了解如下幾個代碼。

-- 1）設置客戶端的字符集。
set character_set_client=gbk;
-- 2）設置連接器的字符集。
set character_set_connection=utf8;
-- 3）設置返回結果的字符集。
set character_set_results=gbk;

2）代碼演示過程，詳細地寫在如下鏈接中的sql文件中，可以自行下載，查看。

http://note.youdao.com/noteshare?id=3fe60a490637d1a51ac78bf4a9e7e4d0&sub=511D73BDDEA34D9BAC565249035D74A8

6、產(chǎn)生亂碼的兩個原因

解碼與實際編碼，不一致導致的亂碼，可修復。

在傳輸過程中，由于編碼不一致，導致部分字節(jié)丟失，造成的亂碼，不可修復。

1）編碼和解碼不一致導致的亂碼

2）傳輸過程中，丟失字節(jié)導致的亂碼。

7、對實際情況的分析(什么都不設置，系統(tǒng)默認是如何呢？)

1）仔細查看如下圖片

根據(jù)上圖可以知道(好好理解下面的文字說明)：

圖二：

2）set names gbk的含義

-- 當客戶端、連接器、返回值的字符集相同，并且都是gbk的時候，我們可以采取如下的簡寫方式：
 set names gbk;
 -- 上述sql語句其實包含了如下三層意思：
 set character_set_client=gbk;
 set character_set_connection=gbk;
 set character_set_results=gbk;

以上就是本文的全部內(nèi)容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家

最新評論