mysql中文亂碼問題，phpmyadmin操作解決方案

標籤：

　　mysql中文亂碼問題一直每次遷移一次資料庫就要從頭解決一遍，因為資料庫建好以後就不會怎麼動了，一直沒當回事兒，反正就麻煩一次嗎。最近伺服器遇到了點問題，重裝了幾次，結果每次都要重新設定這個問題，索性就總結一下。

 

　　首先中文亂碼的根本問題就是編碼問題：我們把中文輸入到資料庫中再從資料庫中取出來顯式在瀏覽器上分為幾個過程，這些過程中要求每一個處理過程的編碼都是要支援中文的，而且如果前後兩個過程如果編碼方式不一樣的話，必須要有轉碼的手段。比如說你用gbk的編碼方式在本地寫好了一段中文，或者說是.sql指令碼，上傳伺服器後執行，如果你的mysql預設以utf8的編碼讀取你的sql語句的話，那麼中文就是亂碼了。（沒有測試過，說不準gbk和utf8是相容的或者是mysql預設會通過unicode轉碼。不過大致就是這個意思）。可以想象如果所有的過程之間都要檢查編碼問題是非常繁瑣的，所以最好的解決方案，就是選擇一種編碼，然後在所有的過程中都使用這種編碼，這樣就不用擔心編碼轉換問題了。

　　然後說一下mysql中關於編碼的規則，mysql中對每個資料庫，每個資料庫中的每個表，每個表中的每個欄位都有關於編碼的設定變數，（記得好像是可以在mysql中用sql語句：show variables like “%char%”）查到。這些變數的優先順序是從小到大排列的。也就是說如果你設定一個testdb資料庫的預設編碼是latin的，那麼在你建立一個表（不聲明編碼方式）以後，這個表的所有欄位的編碼都是latin的，但是你可以建立一個其他編碼方式（比如說utf8）的表，做法就是在建表的時候顯式的聲明用的是什麼編碼。這樣就可以再一個資料庫中同時存在latin編碼的和utf8編碼方式的表了。同樣的規則也可以應用在表和表中的欄位上。

　　最開始就是這裡耽誤了很長時間，因為自己明明已經把資料庫的編碼方式改為utf8的了，但還是顯示亂碼，一直以為是哪裡編碼不統一，檢查了好幾遍。問題是因為這個表是在修改資料庫預設編碼之前建立的，所以這個表的預設編碼還是latin的，同樣這個表中的欄位也是預設為latin的。所以除了需要修改資料庫的預設編碼以外還需要修改表的預設編碼，然後還需要修改欄位的預設編碼。當然如果你的資料庫中只有一個表是需要中文的，那麼你只要在建立表的時候修改它的預設編碼就好了。但是如果你先建立的這個表再去修改表的預設編碼是沒有用的，因為表中的欄位的編碼是根據表建立的時候所確定的。所以說對於已經建立好的表，想要修改其中欄位的編碼不僅需要修改表的預設編碼，還需要修改具體欄位的編碼。

　　這裡我用phpmyadmin作為例子來說明一下對於已經建立好的表怎麼讓其支援中文：

在phpmyadmin中，“預設排序方式”就是預設編碼的意思，我也不知道為什麼這麼說。。。

首先我們看到mysql的預設編碼是什麼，關於編碼有好幾個變數，每個變數負責的功能不一樣，具體的介紹點擊那個問號就可以有mysql的官方解釋了，或者自己去查一下mysql的手冊就好了

在這種預設編碼的情況下我們建立一個資料庫test：

我們這裡不選擇編碼方式也就是“定序”

然後建立一個表：

同樣也不選擇編碼方式

然後插入一條有中文的記錄：

就會出現亂碼了：

原因是預設情況下name欄位的編碼是這種：

我也不清楚為什麼從latin1變成了cp1250_bin可能是mysql中其他的設定裡有規定吧。。。。。。

我們改掉這個編碼：

再插入一條中文的記錄：

可以看到解決了。

現在我們換個思路：改掉test資料庫的預設編碼：

重建立立一個表testtable2：

可以看到這個testtable2的編碼已經變成utf8的了。

同樣插入一條中文記錄，可以看到問題也解決了：

 

總結一下吧：雖然現在很多資料庫管理工具都可以支援邊開發，邊修改資料庫。但是在建立資料庫的時候還是應該大致思考一下資料庫的性質，表之間的依賴關係等等。否則以偵錯工具的方式來調試資料庫效率太低。

mysql中文亂碼問題，phpmyadmin操作解決方案