本文介紹了UTF-8字符有問題；我看到的不是我存儲的內容的處理方法，對大家解決問題具有一定的參考價值，需要的朋友們下面隨著小編來一起學習吧！
問題描述
我嘗試使用UTF-8，但遇到了問題。
我嘗試了很多方法，以下是我得到的結果：
????而不是亞洲字符。即使是歐洲文本，我也得到了Se?or。
奇怪的胡言亂語(Mojibake？)例如Se?±or或?–°?μa?–°é—?。
黑色鉆石，如Se?或.
最后，我遇到了數據丟失或至少被截斷的情況：SeforSe?or。
即使我將文本放在外觀正確時，它也無法正確地排序。
我做錯了什么？我如何修復代碼？我是否可以恢復數據，如果可以，如何恢復？
推薦答案
此問題困擾著此網站的參與者以及其他許多人。
您已經列出了CHARACTER SET故障的五個主要案例。
最佳實踐
接下來，最好使用CHARACTER SET utf8mb4和COLLATION utf8mb4_unicode_520_ci。(有較新版本的Unicode排序規則正在進行中。)
utf8mb4是utf8的超集，因為它處理的是4字節的UTF8代碼，這是Emoji和一些中文用戶需要的。
在MySQL之外，”UTF-8″是指所有大小的編碼，因此實際上與MySQL的utf8mb4相同，而不是utf8。
在下面的內容中，我將嘗試使用這些拼寫和大寫來區分MySQL內部和外部。
應做的內容概述
將您的編輯器等設置為UTF-8。
HTML表單的開頭應類似<form accept-charset="UTF-8">。
將您的字節編碼為UTF-8。
將UTF-8設置為客戶端中使用的編碼。
聲明列/表CHARACTER SET utf8mb4(與SHOW CREATE TABLE核對。)
<meta charset=UTF-8>在HTML開頭
存儲的例程獲取當前的字符集/排序規則。它們可能需要重建。
UTF-8 all the way through
More details for computer languages(及其后續章節)
測試數據
不能使用工具或SELECT查看數據。
太多這樣的客戶端，尤其是瀏覽器，試圖補償不正確的編碼，并向您顯示正確的文本，即使數據庫已損壞。
因此，選擇一個包含一些非英文文本的表和列，并執行
SELECT col, HEX(col) FROM tbl WHERE ...
正確存儲的UTF-8的十六進制將為
表示空格(任何語言)：20
英文：4x、5x、6x或7x
對于大多數西歐國家，重音字母應為Cxyy
西里爾語、希伯來語和波斯語/阿拉伯語：Dxyy
亞洲大部分地區：Exyyzz
表情符號和一些中文：F0yyzzww
More details
所見問題的具體原因和修復
截斷文本(Se用于Se?or)：
要存儲的字節未編碼為utf8mb4。解決此問題。
還要檢查閱讀過程中的連接是否為UTF-8。
黑色鉆石，帶問號(Se?or表示Se?or)；
存在以下情況之一：
情況1(原始字節不是UTF-8)：
要存儲的字節未編碼為UTF8。解決此問題。
INSERT和SELECT的連接(或SET NAMES)不是utf8/utf8mb4。解決此問題。
另外，檢查數據庫中的列是否為CHARACTER SET utf8(或utf8mb4)。
案例2(原始字節為UTF-8)：
SELECT的連接(或SET NAMES)不是utf8/utf8mb4。解決此問題。
另外，檢查數據庫中的列是否為CHARACTER SET utf8(或utf8mb4)。
僅當瀏覽器設置為<meta charset=UTF-8>時才會出現黑色菱形。
問號(普通問號，不是黑色方塊)(Se?or表示Se?or)：
要存儲的字節未編碼為utf8/utf8mb4。解決此問題。
數據庫中的列不是CHARACTER SET utf8(或utf8mb4)。解決這個問題。(使用SHOW CREATE TABLE。)
還要檢查閱讀過程中的連接是否為UTF-8。
Mojibake(Se?±orforSe?or)：
(此討論也適用于雙重編碼，但不一定可見。)
要存儲的字節需要進行UTF-8編碼。解決此問題。
INSERTing和SELECTing文本時的連接需要指定utf8或utf8mb4。解決此問題。
該列需要聲明為CHARACTER SET utf8(或utf8mb4)。解決此問題。
HTML應以<meta charset=UTF-8>開頭。
如果數據看起來正確，但排序不正確，則
要么你選擇了錯誤的校對，
或者沒有符合您需要的排序規則，
或者您有雙重編碼。
重復編碼可以通過執行上述SELECT .. HEX ..進行確認。
é should come back C3A9, but instead shows C383C2A9
The Emoji
