資料庫utf8

1. 如何修改資料庫的字元集utf8

在使用可視化操作界面時，修改資料庫的字元集變得非常簡單。例如，在使用Navicat for MySQL時，只需右鍵點擊目標資料庫，然後選擇「資料庫屬性」選項。在彈出的窗口中，找到「字元集」一欄，將其設置為「utf8」或「utf8_unicode_ci」，這是最常用的排序規則。

如果你更傾向於通過命令行來操作，可以使用以下SQL語句來修改字元集。首先，你需要登錄到MySQL伺服器，然後執行以下命令：

ALTER DATABASE 資料庫名 CHARACTER SET utf8 COLLATE utf8_unicode_ci;

這條命令會將指定的資料庫的字元集和排序規則更改為utf8。

值得注意的是，在修改資料庫字元集之前，最好先備份相關數據，以防萬一出現意外情況。同時，確認你所使用的MySQL版本支持utf8字元集。一些較早的MySQL版本可能不支持。

此外，如果需要修改表的字元集，可以通過以下命令實現：

ALTER TABLE 表名 CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;

這條命令會將指定表的字元集和排序規則更改為utf8。

在完成上述操作後，記得檢查所有相關表和欄位的字元集設置是否正確。確保所有數據都能正確顯示和存儲。

最後，建議定期檢查資料庫的字元集設置，確保其符合當前項目的需求。隨著項目的擴展和數據的增長，字元集設置可能會變得不再合適，因此定期檢查和調整是必要的。

在修改字元集的過程中，務必小心謹慎，以免影響資料庫的正常運行。

2. 為什麼不建議在 MySQL 中使用 UTF-8

MySQL中的UTF-8編碼問題分析與解決方案

一、報錯回顧

在嘗試將包含emoji文字直接寫入SQL中時，執行INSERT語句後，出現了錯誤提示：「Incorrect string value: 'xF0x9Fx98x93' for column 'NAME' at row 1」。這表明MySQL在處理包含emoji符號的字元串時遇到了問題。修改資料庫編碼、系統編碼以及表欄位的編碼格式為utf8mb4後，問題得以解決。

二、MySQL中utf8的趣事

MySQL的「utf8」編碼實際上與標准UTF-8並不完全相同。在MySQL中，「utf8」編碼只支持每個字元最多三個位元組，而標准UTF-8編碼每個字元最多四個位元組。中文在utf8中佔用3個位元組，其他數字、英文、符號佔用1個位元組。由於emoji符號和某些復雜文字在標准UTF-8中佔用4個位元組，而MySQL的「utf8」編碼僅支持3個位元組，因此直接插入會導致錯誤。

三、UTF-8編碼選擇與理解

在使用MySQL時，應當選擇「utf8mb4」作為編碼，以支持真正的UTF-8編碼。MySQL的「utf8」編碼被設計為一種「專屬的編碼」，其能夠編碼的Unicode字元數量有限，且在處理包含4位元組字元的emoji時存在限制。因此，所有在使用「utf8」的MySQL和MariaDB用戶都應該改用「utf8mb4」，以避免潛在的編碼問題。

四、編碼與Unicode字元集

理解編碼與Unicode字元集對於正確使用MySQL至關重要。Unicode字元集包含上百萬個字元，UTF-32是最簡單且直接的編碼方式，每個字元使用32位存儲，但這可能導致空間浪費。相比之下，UTF-8編碼可以節省空間，字元「C」只需要8位，而一些不常用的字元如「 」則可能需要32位。使用UTF-8編碼，一篇類似本文的文章，佔用的空間僅為UTF-32的四分之一左右。

五、utf8編碼的歷史

MySQL從4.1版本開始支持UTF-8編碼，當時使用的標準是舊版的RFC 2279，該標准最多支持每個字元6個位元組。然而，在2002年，MySQL開發者將「utf8」編碼的字元序列限制為最多3個位元組。這一變更的原因尚不明確，但推測可能是為了在性能與空間效率之間做出權衡，以適應特定的用戶需求。

六、總結

在當前網路上，幾乎所有的文章都將MySQL的「utf8」編碼當作真正的UTF-8，包括作者之前的文章和項目。為了幫助更多朋友了解這一關鍵信息，本文旨在強調在MySQL資料庫中使用「utf8mb4」編碼的重要性，以避免遇到編碼相關的錯誤和問題。在搭建資料庫時，記得將編碼設置為「utf8mb4」，以確保能夠正確處理包含emoji、復雜文字以及各種Unicode字元的數據。

3. UTF8與GBK資料庫字元集

現有資料庫A與資料庫B，資料庫A服務端由GBK編碼，資料庫B服務端由UTF8編碼，需完成資料庫A至資料庫B的數據導入。測試中發現A庫數據在插入B資料庫時，部分數據查詢時存在編碼轉換報錯。影響字元編碼的幾個要素如下：

首先闡述影響字元編碼的幾個要素：Terminal-encoding、Client-encoding與Database-encoding。Terminal-encoding負責將一個字元串映射成字元編碼，如'鎵'在GBK解析為0xE689，在UTF8解析為0xE98EB5。Client-encoding是資料庫識別編碼格式的參考，資料庫中二進制編碼的原本格式由Client-encoding標識。Database-encoding是資料庫伺服器編碼，對資料庫B來說是UTF8模式，不支持GBK格式。資料庫在處理非UTF8編碼時，會轉義成UTF8編碼入庫；讀出時，如果client_encoding不是UTF8，會轉義成其他二進制編碼。

具體場景如下：

場景a：終端字元集為GBK，資料庫client_encoding為GBK，database_encoding為UTF8。鎵弿被還原出正確原編碼，但因轉義錯誤導致轉義失敗。

場景b：終端字元集為UTF8，資料庫client_encoding為UTF8，database_encoding為UTF8。鎵弿被正確還原並入庫，按照UTF8讀取可以得到原字元，但按照GBK讀取時失敗。

場景c：終端字元集為GBK，資料庫client_encoding為UTF8，database_encoding為UTF8。鎵弿被正確還原並入庫，無論按照UTF8或GBK讀取均可讀出正確字元串。

問題原因在於A庫中的GBK范圍大於B庫中設置的GBK，A庫所謂「GBK」實際上為GB18030編碼集。編碼背景資料如下：

GB2312、GBK與GB18030是中國國家標准簡體中文字元集，GB2312通行於中國大陸，GBK包含GB2312全部漢字、非漢字元號及BIG5全部漢字，GB18030包含所有漢字、部首、符號，且兼容GB2312及GBK，收錄漢字70244個。

解決方法是在導入與導出數據時，如果A庫為「GBK」或類「GBK」字元集傳輸或存儲數據，B庫需設置客戶端字元集為「GB18030」。