那天，我還在外面吃成都六姐的冒菜。
牛肉丸裹上麻醬后，狠狠嘬一口，都要入嘴了。
產(chǎn)品經(jīng)理突然發(fā)來消息。
"線上有些用戶不能注冊(cè)了"
心想著"關(guān)我x事，又不是我做的模塊"，放下手機(jī)。
不對(duì)，那老哥上禮拜剛離職了，想到這里，夾住毛肚的手微微顫抖。
對(duì)面繼續(xù)發(fā)："還有些用戶不能改名"
"如果用上表情符號(hào)的話，問題必現(xiàn)"
可以了，這下問題幾乎直接定位了。
危，速歸。
有經(jīng)驗(yàn)的兄弟們很容易看出，這肯定是因?yàn)?strong>字符集的緣故。
復(fù)現(xiàn)問題
我們來簡(jiǎn)單復(fù)現(xiàn)下這個(gè)問題。
如果你有一張數(shù)據(jù)庫(kù)表，建表sql就像下面一樣。
建表sql語句
接下來如果你插入的數(shù)據(jù)是
insert成功case
能成功。一切正常。
但如果你插入的是
insert失敗case
就會(huì)報(bào)錯(cuò)。
Incorrect?string?value:?'\xF0\x9F\x98\x81'?for?column?'name'?at?row?1
區(qū)別在于后者多了個(gè)emoji表情。
明明也是字符串，為什么字符串里含有emoji表情，插入就會(huì)報(bào)錯(cuò)呢？
我們從字符集編碼這個(gè)話題開始聊起。
編碼和字符集的關(guān)系
雖然我們平時(shí)可以在編輯器上輸入各種中文英文字母，但這些都是給人讀的，不是給計(jì)算機(jī)讀的，其實(shí)計(jì)算機(jī)真正保存和傳輸數(shù)據(jù)都是以二進(jìn)制0101的格式進(jìn)行的。
那么就需要有一個(gè)規(guī)則，把中文和英文字母轉(zhuǎn)化為二進(jìn)制，比如"debug"，計(jì)算機(jī)就需要把它轉(zhuǎn)化為下圖這樣。
debug的編碼
其中d對(duì)應(yīng)十六進(jìn)制下的64，它可以轉(zhuǎn)換為01二進(jìn)制的格式。
于是字母和數(shù)字就這樣一一對(duì)應(yīng)起來了，這就是ASCII編碼格式。
它用一個(gè)字節(jié)，也就是8位來標(biāo)識(shí)字符，基礎(chǔ)符號(hào)有128個(gè)，擴(kuò)展符號(hào)也是128個(gè)。
也就只能表示下英文字母和數(shù)字。
這哪里夠用。
塞牙縫都不夠。
于是為了標(biāo)識(shí)中文，出現(xiàn)了GB2312的編碼格式。為了標(biāo)識(shí)希臘語，出現(xiàn)了greek編碼格式，為了標(biāo)識(shí)俄語，整了cp866編碼格式。
這百花齊放的場(chǎng)面，顯然不是一個(gè)愛寫if else的程序員想看到的。
為了統(tǒng)一它們，于是出現(xiàn)了Unicode編碼格式，它用了2~4個(gè)字節(jié)來表示字符，這樣理論上所有符號(hào)都能被收錄進(jìn)去，并且它還完全兼容ASCII的編碼，也就是說，同樣是字母d，在ASCII用64表示，在Unicode里還是用64來表示。
但不同的地方是ASCII編碼用1個(gè)字節(jié)來表示，而Unicode用則兩個(gè)字節(jié)來表示。
比如下圖，同樣都是字母d，unicode比ascii多使用了一個(gè)字節(jié)。
unicode比ascii多使用一個(gè)字節(jié)
我們可以注意到，上面的unicode編碼，放在前面的都是0，其實(shí)用不上，但還占了個(gè)字節(jié)，有點(diǎn)浪費(fèi)，完全能隱藏掉。如果我們能做到該隱藏時(shí)隱藏，這樣就能省下不少空間，按這個(gè)思路，就是就有了UTF-8編碼。
編碼格式
來總結(jié)下。
按照一定規(guī)則把符號(hào)和二進(jìn)制碼對(duì)應(yīng)起來，這就是編碼。而把n多這種已經(jīng)編碼的字符聚在一起，就是我們常說的字符集。
比如utf-8字符集就是所有utf-8編碼格式的字符的合集。
字符和字符集的關(guān)系
mysql的字符集
想看下mysql支持哪些字符集?？梢詧?zhí)行?show charset;
數(shù)據(jù)庫(kù)支持哪些字符集
上面這么多字符集，我們只需要關(guān)注utf8和utf8mb4就夠了。
utf8和utf8mb4的區(qū)別
上面提到utf-8是在unicode的基礎(chǔ)上做的優(yōu)化，既然unicode有辦法表示所有字符，那utf-8也一樣可以表示所有字符，為了避免混淆，我在后面叫它大utf8。
而從上面mysql支持的字符集的圖里，我們看到了utf8和utf8mb4。
先說utf8mb4編碼，mb4就是most bytes 4的意思，從上圖最右邊的Maxlen可以看到，它最大支持用4個(gè)字節(jié)來表示字符，它幾乎可以用來表示目前已知的所有的字符。
再說mysql字符集里的utf8，它是數(shù)據(jù)庫(kù)的默認(rèn)字符集。但注意，此utf8非彼utf8，我們叫它小utf8字符集。為什么這么說，因?yàn)閺腗axlen可以看出，它最多支持用3個(gè)字節(jié)去表示字符，按utf8mb4的命名方式，準(zhǔn)確點(diǎn)應(yīng)該叫它utf8mb3。
不好意思，有被嚴(yán)謹(jǐn)?shù)降男值軅?，評(píng)論區(qū)扣個(gè)"嚴(yán)謹(jǐn)"。
它就像是閹割版的utf8mb4，只支持部分字符。比如emoji表情，它就不支持。
utf8mb3和utf8mb4的關(guān)系
而mysql支持的字符集里，第三列，collation，它是指字符集的比較規(guī)則。
比如，"debug"和"Debug"是同一個(gè)單詞，但它們大小寫不同，該不該判為同一個(gè)單詞呢。
這時(shí)候就需要用到collation了。
通過SHOW COLLATION WHERE Charset = 'utf8mb4';可以查看到utf8mb4下支持什么比較規(guī)則。
utf8mb4字符集比較規(guī)則
如果collation = utf8mb4_general_ci，是指使用utf8mb4字符集的前提下，挨個(gè)字符進(jìn)行比較（general），并且不區(qū)分大小寫（_ci，case insensitice）。
這種情況下，"debug"和"Debug"是同一個(gè)單詞。
對(duì)比規(guī)則-大小寫不敏感
如果改成collation=utf8mb4_bin，就是指挨個(gè)比較二進(jìn)制位大小。
于是"debug"和"Debug"就不是同一個(gè)單詞。
對(duì)比規(guī)則-大小寫敏感
那utf8mb4對(duì)比utf8mb3有什么劣勢(shì)嗎？
我們知道數(shù)據(jù)庫(kù)表里，字段類型如果是char(2)的話，里面的2是指字符個(gè)數(shù)，也就是說不管這張表用的是什么編碼的字符集，都能放上2個(gè)字符。
而char又是固定長(zhǎng)度，為了能放下2個(gè)utf8mb4的字符，char會(huì)默認(rèn)保留2*4（maxlen=4）= 8個(gè)字節(jié)的空間。
如果是utf8mb3，則會(huì)默認(rèn)保留?2 * 3 (maxlen=3) = 6個(gè)字節(jié)的空間。也就是說，在這種情況下，utf8mb4會(huì)比utf8mb3多使用一些空間。
但這真的無關(guān)緊要，如果我不用char，用varchar就好了，varchar不是固定長(zhǎng)度，也就沒有上面這些麻煩事了。
所以我個(gè)人認(rèn)為，utf8mb4比起 utf8mb3 幾乎沒有劣勢(shì)。
如何查看數(shù)據(jù)庫(kù)表的字符集
如果我們不知道自己的表是用的哪種字符集，可以通過下面的方式進(jìn)行查看。
查看數(shù)據(jù)庫(kù)表的字符集
再看報(bào)錯(cuò)原因
到這里，我們回到文章開頭的問題。
因?yàn)閿?shù)據(jù)庫(kù)表在建表的時(shí)候使用?DEFAULT CHARSET=utf8， 相當(dāng)于指定了utf8mb3字符集格式。
而在執(zhí)行insert數(shù)據(jù)的時(shí)候，又不講武德，加入了emoji表情這種utf8mb4才能支持的字符，mysql識(shí)別到這是utf8mb3不支持的字符，于是忍痛報(bào)錯(cuò)。
要修復(fù)也很簡(jiǎn)單，執(zhí)行下面的sql語句，就可以把數(shù)據(jù)庫(kù)表的字符集改成utf8mb4。
ALTER?TABLE?user?CONVERT?TO?CHARACTER?SET?utf8mb4?COLLATE?utf8mb4_general_ci;
答應(yīng)我，以后建表，我們都無腦選utf8mb4。
選utf8除了在char字段場(chǎng)景下會(huì)比utf8mb4稍微省一點(diǎn)空間外，幾乎沒任何好處。
這點(diǎn)空間省下來了能提高你的績(jī)效嗎？不能。
但如果因此炸雷了，那你號(hào)就沒了。
總結(jié)
-
ASCII編碼支持?jǐn)?shù)字和字母。大佬們?yōu)榱酥С种形囊肓薌B2312編碼格式，其他國(guó)家的大佬們?yōu)榱酥С指嗾Z言和符號(hào)，也引入了相應(yīng)的編碼格式。為了統(tǒng)一這些各種編碼格式，大佬們又引入了unicode編碼格式，而utf-8則在unicode的基礎(chǔ)上做了優(yōu)化，壓縮了空間。
-
mysql默認(rèn)的utf8字符集，其實(shí)只是utf8mb3，并不完整，當(dāng)插入emoji表情等特殊字符時(shí)，會(huì)報(bào)錯(cuò)，導(dǎo)致插入、更新數(shù)據(jù)失敗。改成utf8mb4就好了，它能支持更多字符。
-
mysql建表時(shí)如果不知道該選什么字符集，無腦選utf8mb4就行了，你會(huì)感謝我的。
?文章來源地址http://www.zghlxwxcb.cn/news/detail-446109.html文章來源：http://www.zghlxwxcb.cn/news/detail-446109.html
?
到了這里，關(guān)于mysql插入數(shù)據(jù)會(huì)失??？為什么？的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
