項目因為歷史原因使用了 GBK編碼，遇到非GBK編碼字元時出現亂碼問題，情況比較嚴重，暫時先打算修改 列的字元編碼為 utf8mb4. 查看 mysql 手冊： 用 GBK 編碼轉 utf8 進行說明： 他的大概意思是，如果 是 char varchar text 等類型的，並且這些列的內容也是採用 ...
項目因為歷史原因使用了 GBK編碼，遇到非GBK編碼字元時出現亂碼問題，情況比較嚴重，暫時先打算修改 列的字元編碼為 utf8mb4.
查看 mysql 手冊：
用 GBK 編碼轉 utf8 進行說明：
他的大概意思是，如果 是 char varchar text 等類型的，並且這些列的內容也是採用的正確的編碼(GBK)，也就是列的內容的編碼和列的定義中指定的編碼一致時，可以直接使用類似下麵的語句進行處理：
ALTER TABLE t MODIFY COLUMN col_name varchar(60) CHARACTER SET utf8mb4;
如果 列的內容和列定義中指定的編碼不一致時，需要先 轉成 binary, 在轉出自己想要的字元集 utf8mb4.
但是實際測試發現，這裡表達有誤。如果按照他這個說明進行轉的話，100%會亂碼！ 這裡的: with the desird character set 應該改成：with the right charcter set, then to the desired character set.
如果列的內容和列定義中指定的編碼不一致時，需要先轉出 binary, 再轉成 內容編碼的那個編碼字元集(the right charcter set) , 然後再轉成 自己想要的 utf8mb4( the desired character set)。這樣才不會亂碼。
總結一下：
1）如果你能確保你 gbk 編碼的列中的內容也是gkb編碼格式存儲的那麼，轉utf8mb4時，很簡單，直接轉就可以了：
alter table t modify column col varchar(60) character set utf8mb4;
2) 如果你不能確定 你 gbk 編碼的列中的內容不是 gbk 編碼格式存儲的時，你需要先轉成 binary, 再 轉出 內容實際編碼的字元集, 最後轉出 utf8mb4:
alter table t modify column col binary;
alter table t modify column col varchar(60) character set 內容實際編碼的字元集;
alter table t modify column col varchar(60) character set utf8mb4;
3) 不亂碼還有一個前提，就是 子集轉超集。比如 GBK 轉 utf8. 也就是GBK 編碼的字元，UTF8都可以編碼。
如果是 utf8 轉 GBK，那麼那些 utf8可以編碼的，GBK不能編碼的字元就會亂碼了，就會丟失內容。
