本文從關閉資料庫開始講解如何設定mysql的編碼字符集，解決亂碼問題
關於在從客戶端到資料庫伺服器之間編碼轉換的過程可以參考這篇：
設定字符集流程：
1. 關閉資料庫 -> service mysqld stop
2. 修改my.cnf檔案設定預設字符集-> linux該檔案一般在 /etc/my.cnf , 沒有的話手動建立.
default-character-set = utf8
character_set_server = utf8
這種好像是永久修改，重啟也生效，但是我設定了並沒用
3. 設定資料庫的預設編碼：
這個是臨時修改，重啟了就恢復預設了.
關於每個編碼的作用：
最好還是檢視官方文件，別人的部落格感覺都理解的不是很靠譜。
4. 重啟資料庫： service mysql restart
以上步驟很可能是錯誤的！！！！！！！
下面的更靠譜一些：
這篇兩篇部落格講了mysql的在傳輸過程中的編譯碼過程 ：
個人理解 上述第三步中的設定編碼方式 其實只是設定當前客戶端使用的編碼，所以會發現重啟資料庫後再次進入發現又都恢復預設了。
其實還是在建立資料庫和建表的時候記得宣告下編碼格式更靠譜一些：
create database `test2` default character set utf8mb4 collate utf8mb4_general_ci;
create table `plan_notice` (
`id` int(11) not null auto_increment comment '主鍵id',
primary key (`id`)
) engine=innodb default charset=utf8mb4;
看到乙個靠譜的解釋：
編碼字符集
gb2312 全稱中國標準第兩千三百一十二條，其中包含亞裔字符集 南韓文字 缺點不包括正體中文，但是台灣還在使用正體中文，於是就有了 gbk gbk 全稱中國標準第兩千三百一十二條擴充套件版本，就包含正體中文 unicode 全稱萬國碼，各個國家的文字都有 utf 8 最通用的，unicode的公升...
MySQL的編碼字符集問題
在專案裡遇到了插入的中文字元變成亂碼的問題，修改了mysql的字符集相關變數卻沒有解決問題，上網找了下，嘗試了各種方法最終解決。修改global的variable set character set database utf8，卻不能解決某個資料庫建好之後，新建的表的character set da...
編碼字符集與字符集編碼的區別
無論歷史上的ucs還是現如今的unicode，兩者指的都是編碼字符集，而不是字符集編碼。乙個抽象字符集其實就是指字元的集合，例如所有的英文本母是乙個抽象字符集，所有的漢字是乙個抽象字符集，在給乙個抽象字元集合中的每個字元都分配乙個 整數編號之後 注意這個整數並沒有要求大小 這個字符集就有了順序，就成...