mysql存儲的中文亂碼
A. 解決Mysql中文亂碼問題的實用方法mysql中使用中文亂碼
解決MySQL中文亂碼問題的實用方法
MySQL是一種流行的關系型資料庫管理系統，可用於存儲和管理各種類型的數據。但是，在MySQL中使用中文時可能會遇到亂碼問題。這可能會導致數據無法正確地存儲和檢索，這對於中文網站或應用程序來說是一個災難。
在本文中，我們將介紹一些解決MySQL中文亂碼問題的實用方法。
1. 設置字元集
您需要確保MySQL伺服器、客戶端、表和列都使用正確的字元集。常用字元集包括UTF-8、GBK和GB2312。為此，您需要使用ALTER命令設置表和列的字元集。以下是一個示例：
ALTER TABLE 表名 CONVERT TO CHARACTER SET utf8;
ALTER TABLE 表名 CHANGE 列名 欄位類型 CHARACTER SET utf8 COLLATE utf8_general_ci;
注意：這些命令僅修復表和列級別的問題。
2. 修改配置文件
如果MySQL伺服器安裝在Linux上，您可以編輯MySQL配置文件my.cnf來設置全局字元集。打開/etc/my.cnf文件，並在[mysqld]節下添加以下行：
[mysqld]
# 設置字元集為utf8
character-set-server = utf8
default-character-set = utf8
重啟MySQL服務以使更改生效。
3. 使用SET NAMES命令
SET NAMES命令用於更改客戶端連接的默認字元集。在應用程序代碼中，您可以將SET NAMES命令插入連接到MySQL的代碼中，以確保正確的字元集。以下是一個示例：
$conn = mysql_connect($db_host, $db_user, $db_pass);
mysql_select_db($db_name);
mysql_query(“SET NAMES ‘utf8′”);
4. 在代碼中指定字元集
在應用程序代碼中，您可以在MYSQL連接語句中指定字元集。以下是一個示例：
$db = new mysqli($db_host, $db_user, $db_pass, $db_name);
$db->query(“SET NAMES ‘utf8′”);
5. 使用轉換函數
如果您的MySQL中存在亂碼數據，可以使用MySQL內置的轉換函數將其轉換為正確的字元集。以下是一些MySQL函數：
– CONVERT(str，char_set)：將str轉換為char_set字元集
– CAST(str AS char(n))：將str強制轉換為特定的字元集
– BINARY(str)：在比較和排序時將str視為二進制字元串
這些方法旨在解決MySQL中文亂碼問題，如果您還遇到其他問題，請查詢MySQL官方文檔或使用其他解決方案。
結論
中文亂碼是MySQL常見的問題，但是可以使用上述方法解決。最重要的是要確保正確的字元集在MySQL伺服器、客戶端、表和列中啟用，並且使用SET NAMES命令或在代碼中指定字元集。
示例代碼：
$conn = new mysqli($host, $user, $password, $database);
if ($conn->connect_errno) {
echo “資料庫鏈接失敗”;
exit;
}
$conn->query(“SET NAMES utf8”);
$res = $conn->query(“SELECT * FROM `users`”);
while ($row = $res->fetch_assoc()) {
echo $row[‘name’];
}
$res->close();
$conn->close();
記住，正確的字元集是確保MySQL正確工作的關鍵！
B. mysql資料庫中存進的是中文，為什麼查出來的亂碼
一、轉碼失敗
在數據寫入到表的過程中轉碼失敗，資料庫端也沒有進行恰當的處理，導致存放在表裡的數據亂碼。
針對這種情況，前幾篇文章介紹過客戶端發送請求到服務端。
其中任意一個編碼不一致，都會導致表裡的數據存入不正確的編碼而產生亂碼。
比如下面簡單一條語句：
set @a = "文本字元串";
insert into t1 values(@a);
變數 @a 的字元編碼是由參數 CHARACTER_SET_CLIENT 決定的，假設此時編碼為 A，也就是變數 @a 的編碼。
2. 寫入語句在發送到 MySQL 服務端之前的編碼由 CHARACTER_SET_CONNECTION 決定，假設此時編碼為 B。
3. 經過 MySQL 一系列詞法，語法解析等處理後，寫入到表 t1，表 t1 的編碼為 C。
那這里編碼 A、編碼 B、編碼 C 如果不兼容，寫入的數據就直接亂碼。
二、客戶端亂碼
表數據正常，但是客戶端展示後出現亂碼。
這一類場景，指的是從 MySQL 表裡拿數據出來返回到客戶端，MySQL 里的數據本身沒有問題。客戶端發送請求到 MySQL，表的編碼為 D，從 MySQL 拿到記錄結果傳輸到客戶端，此時記錄編碼為 E（CHARACTER_SET_RESULTS）。
那以上編碼 E 和 D 如果不兼容，檢索出來的數據就看起來亂碼了。但是由於數據本身沒有被破壞，所以換個兼容的編碼就可以獲取正確的結果。
這一類又分為以下三個不同的小類：
1)欄位編碼和表一致，客戶端是不同的編碼
比如下面例子， 表數據的編碼是 utf8mb4，而 SESSION 1 發起的連接編碼為 gbk。那由於編碼不兼容，檢索出來的數據肯定為亂碼。
2）表編碼和客戶端的編碼一致，但是記錄之間編碼存在不一致的情形
比如表編碼是 utf8mb4，應用端編碼也是 utf8mb4，但是表裡的數據可能一半編碼是 utf8mb4，另外一半是 gbk。那麼此時表的數據也是正常的，不過此時採用哪種編碼都讀不到所有完整的數據。這樣數據產生的原因很多，比如其中一種可能性就是表編碼多次變更而且每次變更不徹底導致（變更不徹底，我之前的篇章里有介紹）。舉個例子，表 t3 的編碼之前是 utf8mb4，現在是 gbk，而且兩次編碼期間都被寫入了正常的數據。
3）每個欄位的編碼不一致，導致亂碼和第二點一樣的場景。不同的是：非記錄間的編碼不統一，而是每個欄位編碼不統一。舉個例子，表 c1 欄位 a1,a2。a1 編碼 gbk，a2 編碼是 utf8mb4。那每個欄位單獨讀出來數據是完整的，但是所有欄位一起讀出來，數據總會有一部分亂碼。
三、LATIN1
還有一種情形就是以 LATIN1 的編碼存儲數據
估計大家都知道字元集 LATIN1，LATIN1 對所有字元都是單位元組流處理，遇到不能處理的位元組流，保持原樣，那麼在以上兩種存入和檢索的過程中都能保證數據一致，所以 MySQL 長期以來默認的編碼都是 LATIN1。這種情形，看起來也沒啥不對的點，數據也沒亂碼，那為什麼還有選用其他的編碼呢？原因就是對字元存儲的位元組數不一樣，比如 emoji 字元 "❤"，如果用 utf8mb4 存儲，佔用 3 個位元組，那 varchar(12) 就能存放 12 個字元，但是換成 LATIN1，只能存 4 個字元。