如何解決MySQL對JSON類型UTF-8編碼導致中文亂碼問題

如何解決MySQL對JSON類型UTF-8編碼導致中文亂碼問題，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

我們來學習字符編碼，在學習的過程中，我發現對于MySQL中JSON類型的編碼導致數據中文出現亂碼還有可深挖之處，接下來我們來分析一下，若有錯誤之處，還請批評指出。

評論中指出任何不在基本多文本平面的Unicode字符，都無法使用MySQL的utf8字符集存儲，包括 Emoji 表情(Emoji 是一種特殊的Unicode 編碼，常見于 IOS 和 Android 手機上)和很多不常用的漢字，以及任何新增的 Unicode 字符等等(utf8的缺點)。

首先我們了解下什么是Unicode，Unicode是通用字符集，它是一種標準，該標準在一處定義了編寫在計算機上使用的大多數活動語言所需的所有字符，它的目標是成為并且在很大程度上已經是已編碼的所有其他字符集的超集。在計算機或網絡中的文本我們通過字符組成，字符代表字母、標點符號或其他符號。不同的組織收集了不同的字符集并為其創建了編碼-一個字符集可能僅覆蓋基于拉丁語的西歐語言（不包括保加利亞或希臘等歐盟國家），另一個可能覆蓋特定的遠東語言（例如（例如日語），其他語言可能是以特殊方式設計的，代表世界上某處其他語言的眾多語言之一。但是我們并不能保證應用程序將支持所有編碼，也不能保證給定的編碼將滿足我們代表給定語言的所有需求，另外，通常不可能在同一網頁或數據庫中組合不同的編碼，因此使用“傳統”編碼方法來支持多語言頁面通常非常困難

Unicode協會提供了一個大的，單字節字符集，旨在包括所有需要的世界上任何書寫系統，包括古老的腳本（如楔形文字，哥特式和埃及的象形文字）的字符，所以統一字符編碼，將其作為Web和操作系統體系結構的基礎，并且得到所有主要Web瀏覽器和應用程序的支持。當前的Unicode字符分為17組編排，每組被稱之為一個平面（Plane），所以將字符劃分為0-16號的平面，而每平面擁有65536（即2¹⁶）個代碼點即范圍區間在0x000到0xFFFF之間，而0號平面就是基本多語言平面（BMP：Basic Mutiingual Plane）。在基本多文本平面上針對每一種文字或者其補充或者其擴展都給出了一個編碼范圍，比如拉丁文【0000-007F】，拉丁文-補充【0080-00FF】等等。說了這么多，我們只需要記住一點即可：在Unicode字符集中前65536個代碼點構成了基本多語言平面簡稱BMP，BMP中包含了大多常用的字符，另外Unicode字符集還包含了一百萬個其他代碼點的位置空間，我們稱之為補充字符。

我們需要區分字符集、編碼字符集和編碼的概念，字符集或字符串包含可能用于特定目的的字符集，它是支持計算機上的西歐語言所需的字符集，與計算機完全無關，而編碼字符集是一組用于該唯一的號碼被分配給每個字符的字符，有時候我們將編碼字符集也可稱作為代碼頁，編碼字符集的單位稱為代碼點，代碼點值表示字符在編碼字符集中的位置。例如，Unicode編碼字符集中字母á的代碼點為十進制225，十六進制表示法為0xE1。而字符編碼反映編碼字符集被映射到用于在計算機操縱字節的方式。一個字符集可以有多種編碼，許多字符編碼標準，例如ISO 8859系列中定義的標準，都為給定字符使用單個字節，并且編碼是對編碼字符集中字符標量位置的直接映射。例如，ISO 8859-1編碼字符集中的字母A在第65個字符位置（從零開始），并且使用值為65的字節進行編碼并以此在計算機中表示，對于ISO 8859-1而言，這將永遠不會再改變

但是，對于Unicode，事情并沒有如此簡單，盡管Unicode編碼字符集中字母á的代碼點始終為225（十進制），但在UTF-8中，它在計算機中由兩個字節表示，換句話說，在此字符的編碼字符集值和編碼值之間不是簡單的一對一映射，另外，在Unicode中，針對同一字符可以有多種編碼的方式。例如，字母á可以用一種編碼形式的兩個字節表示，而用另一種編碼形式的四個字節表示。可以與Unicode一起使用的編碼形式稱為UTF-8，UTF-16和UTF-32。

UTF-8使用1個字節表示ASCII集中的字符，使用2個字節表示其他幾個字母塊中的字符，使用3個字節表示BMP的其余部分，補充字符使用4個字節。UTF-16對BMP中的任何字符使用2個字節，對補充字符使用4個字節。UTF-32對所有字符使用4個字節。基本多語言平面對應代碼點存儲的是常用字符，上述針對不同字符在其對應代碼點，然后計算出該字符的16進制的字符串，舉個栗子，將【好】字進行UTF-8編碼看看該字符的字節值和字節數，如下：

到此我們大概了解完了字符編碼，接下來我們再次回到上一節的問題，上一節將我姓名作為JSON存儲到數據庫中去，但是最終獲取數據時，將出現亂碼，因為其表編碼為utf8，最終將表編碼修改為utf8mb4才好使，為啥utf8就不行呢？通過上述對utf8的定義最多可以有4個字節，支持補充字符，所以MySQL根本就沒有實現標準的utf8編碼，換句話說只是部分實現了utf8編碼，MySQL中的utf8又名為utf8mb3，也就是一個字符最多可通過3個字節表示且包含BMP字符，而不包含補充字符。所以無論是我的姓還是名雖然是3個字節，但是并非常用BMP字符導致。但是針對列類型為JSON類型，事實是對于獲取中文真的會亂碼嗎？上文我用到的MySQL版本為5.7+，如下：

接下來我們利用MySQL 8.0再來進行測試發現不會亂碼，創建類和表配置編碼如下：

隨著移動端的興起，有了表情的出現，所以從MySQL 5.5.3開始，引入utf8mb4字符集每個字符最多可使用4個字節，支持補充字符，對于BMP字符，utf8 [utf8mb3]和utf8mb4具有相同的存儲特征：相同的代碼值，相同的編碼，相同的長度，對于補充字符，utf8 [utf8mb3]根本無法存儲該字符，而utf8mb4需要4個字節來存儲它，由于utf8 [utf8mb3]根本無法存儲字符，因此在utf8 [utf8mb3]列中沒有任何補充字符。接下來我們在針對JSON類型配置為utf8編碼的情況下，我們來插入表情，此時會發現也是可以的。我們是可以獲取對應字符的字節數，比如如下哭笑不得的表情為4個字節：

其實針對JSON類型獲取數據亂碼的情況早就有人提出過相關bug，詳見地址《https://bugs.mysql.com/bug.php?id=81677》，不過官方一直沒有任何回復，至少通過上述測試出來的結果對于utf8存儲表情也可以，到底具體情況咋回事，我們還是看看8.0版本以對utf8編碼描述為準，詳情請見《https://dev.mysql.com/doc/refman/8.0/en/charset-unicode.html》，對于utf8編碼的描述依然還是最多可存儲3個字節，如下：

別忘記，還有注意：utf8[utf8mb3]字符集已被棄用，并會在將來的MySQL版本中移除，請改用utf8mb4，盡管utf8當前是utf8mb3的別名，但在某些時候utf8將成為對utf8mb4的引用，為避免對utf8的含義含糊不清，請考慮為字符集引用顯式指定utf8mb4而不是utf8。

所以到此我們已明了，針對8.0版本中的utf8編碼雖說最多可支持3個字節，但是，會將utf8成為utf8mb4的引用，如此就不難理解為何上述將表配置為utf8編碼時，對于JSON類型的不在常用BMP字符進行數據存儲和表情皆沒問題

關于如何解決MySQL對JSON類型UTF-8編碼導致中文亂碼問題問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。