原文：https://www.cnblogs.com/CreateMyself/p/12587426.html

前言

繼上文發(fā)表之后，結(jié)合評論意見并親自驗(yàn)證最終發(fā)現(xiàn)是編碼的問題，但是對于字符編碼還是有點(diǎn)不解，于是乎，有了本文，我們來學(xué)習(xí)字符編碼，在學(xué)習(xí)的過程中，我發(fā)現(xiàn)對于MySQL中JSON類型的編碼導(dǎo)致數(shù)據(jù)中文出現(xiàn)亂碼還有可深挖之處，接下來我們來分析一下，若有錯(cuò)誤之處，還請批評指出。

字符編碼

評論中指出任何不在基本多文本平面的Unicode字符，都無法使用MySQL的utf8字符集存儲，包括Emoji 表情(Emoji 是一種特殊的Unicode 編碼，常見于IOS和Android 手機(jī)上)和很多不常用的漢字，以及任何新增的 Unicode 字符等等(utf8的缺點(diǎn))，然而啥是多文本平面，詳情維基百科《https://en.wikipedia.org/wiki/Plane_(Unicode)》。首先我們了解下什么是Unicode，Unicode是通用字符集，它是一種標(biāo)準(zhǔn)，該標(biāo)準(zhǔn)在一處定義了編寫在計(jì)算機(jī)上使用的大多數(shù)活動語言所需的所有字符，它的目標(biāo)是成為并且在很大程度上已經(jīng)是已編碼的所有其他字符集的超集。在計(jì)算機(jī)或網(wǎng)絡(luò)中的文本我們通過字符組成，字符代表字母、標(biāo)點(diǎn)符號或其他符號。不同的組織收集了不同的字符集并為其創(chuàng)建了編碼-一個(gè)字符集可能僅覆蓋基于拉丁語的西歐語言(不包括保加利亞或希臘等歐盟國家)，另一個(gè)可能覆蓋特定的遠(yuǎn)東語言(例如(例如日語)，其他語言可能是以特殊方式設(shè)計(jì)的，代表世界上某處其他語言的眾多語言之一。但是我們并不能保證應(yīng)用程序?qū)⒅С炙芯幋a，也不能保證給定的編碼將滿足我們代表給定語言的所有需求，另外，通常不可能在同一網(wǎng)頁或數(shù)據(jù)庫中組合不同的編碼，因此使用“傳統(tǒng)”編碼方法來支持多語言頁面通常非常困難，所以Unicode協(xié)會提供了一個(gè)大的，單字節(jié)字符集，旨在包括所有需要的世界上任何書寫系統(tǒng)，包括古老的腳本(如楔形文字，哥特式和埃及的象形文字)的字符，所以統(tǒng)一字符編碼，將其作為Web和操作系統(tǒng)體系結(jié)構(gòu)的基礎(chǔ)，并且得到所有主要Web瀏覽器和應(yīng)用程序的支持。當(dāng)前的Unicode字符分為17組編排，每組被稱之為一個(gè)平面(Plane)，所以將字符劃分為0-16號的平面，而每平面擁有65536(即216)個(gè)代碼點(diǎn)即范圍區(qū)間在0x000到0xFFFF之間，而0號平面就是基本多語言平面(BMP：Basic Mutiingual Plane)。在基本多文本平面上針對每一種文字或者其補(bǔ)充或者其擴(kuò)展都給出了一個(gè)編碼范圍，比如拉丁文【0000-007F】，拉丁文-補(bǔ)充【0080-00FF】等等。說了這么多，我們只需要記住一點(diǎn)即可：在Unicode字符集中前65536個(gè)代碼點(diǎn)構(gòu)成了基本多語言平面簡稱BMP，BMP中包含了大多常用的字符，另外Unicode字符集還包含了一百萬個(gè)其他代碼點(diǎn)的位置空間，我們稱之為補(bǔ)充字符。我們需要區(qū)分字符集、編碼字符集和編碼的概念，字符集或字符串包含可能用于特定目的的字符集，它是支持計(jì)算機(jī)上的西歐語言所需的字符集，與計(jì)算機(jī)完全無關(guān)，而編碼字符集是一組用于該唯一的號碼被分配給每個(gè)字符的字符，有時(shí)候我們將編碼字符集也可稱作為代碼頁，編碼字符集的單位稱為代碼點(diǎn)，代碼點(diǎn)值表示字符在編碼字符集中的位置。例如，Unicode編碼字符集中字母á的代碼點(diǎn)為十進(jìn)制225，十六進(jìn)制表示法為0xE1。而字符編碼反映編碼字符集被映射到用于在計(jì)算機(jī)操縱字節(jié)的方式。一個(gè)字符集可以有多種編碼，許多字符編碼標(biāo)準(zhǔn)，例如ISO 8859系列中定義的標(biāo)準(zhǔn)，都為給定字符使用單個(gè)字節(jié)，并且編碼是對編碼字符集中字符標(biāo)量位置的直接映射。例如，ISO 8859-1編碼字符集中的字母A在第65個(gè)字符位置(從零開始)，并且使用值為65的字節(jié)進(jìn)行編碼并以此在計(jì)算機(jī)中表示，對于ISO 8859-1而言，這將永遠(yuǎn)不會再改變，但是，對于Unicode，事情并沒有如此簡單，盡管Unicode編碼字符集中字母á的代碼點(diǎn)始終為225(十進(jìn)制)，但在UTF-8中，它在計(jì)算機(jī)中由兩個(gè)字節(jié)表示，換句話說，在此字符的編碼字符集值和編碼值之間不是簡單的一對一映射，另外，在Unicode中，針對同一字符可以有多種編碼的方式。例如，字母á可以用一種編碼形式的兩個(gè)字節(jié)表示，而用另一種編碼形式的四個(gè)字節(jié)表示。可以與Unicode一起使用的編碼形式稱為UTF-8，UTF-16和UTF-32。

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

var bytes = Encoding.UTF8.GetBytes("好");var hexString = BitConverter.ToString(bytes);

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

接下來我們利用MySQL 8.0再來進(jìn)行測試發(fā)現(xiàn)不會亂碼，創(chuàng)建類和表配置編碼如下：

public classt1

{public int id { get; set; }public string jdoc { get; set; }

}

static void Main(string[] args)

{

SetDialect(Dialect.MySQL);var con = new MySqlConnection(@"Server=localhost;Database=user;Uid=root;Pwd=root;");var id = con.Insert(new t1() { jdoc = JsonConvert.SerializeObject(new { Data = "汪鵬"}) });var result = con.QueryFirstOrDefault("select * from t1 where id = @id", new{ id });

Console.ReadKey();

}

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

var emotion = Encoding.UTF8.GetByteCount("");

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

別忘記，還有注意：utf8[utf8mb3]字符集已被棄用，并會在將來的MySQL版本中移除，請改用utf8mb4，盡管utf8當(dāng)前是utf8mb3的別名，但在某些時(shí)候utf8將成為對utf8mb4的引用，為避免對utf8的含義含糊不清，請考慮為字符集引用顯式指定utf8mb4而不是utf8。所以到此我們已明了，針對8.0版本中的utf8編碼雖說最多可支持3個(gè)字節(jié)，但是，會將utf8成為utf8mb4的引用，如此就不難理解為何上述將表配置為utf8編碼時(shí)，對于JSON類型的不在常用BMP字符進(jìn)行數(shù)據(jù)存儲和表情皆沒問題。

總結(jié)

通過此文對utf8編碼的JSON類型的數(shù)據(jù)出現(xiàn)中文亂碼的問題的學(xué)習(xí)才算告一段落， 原來版本問題使得utf8存在對utf8mb4編碼的引用，知其然，知其所以然，嗯，大概是這么個(gè)道理。發(fā)表博客的好處就在這里，沒有批評和指正，哪來的更進(jìn)一步呢。

總結(jié)

以上是生活随笔為你收集整理的mysql存json将utf8编码 去掉,MySQL对JSON类型UTF-8编码导致中文乱码探讨的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。