爲什麼在執行設置名稱utf8mb4後，列名更改爲問號？

爲什麼在執行設置名稱utf8mb4後，列名更改爲問號？見下文：爲什麼在執行設置名稱utf8mb4後，列名更改爲問號？

mysql> show variables like 'character%' ; 
+--------------------------+---------------------------------------+ 
| Variable_name   | Value         | 
+--------------------------+---------------------------------------+ 
| character_set_client  | utf8         | 
| character_set_connection | utf8         | 
| character_set_database | latin1        | 
| character_set_filesystem | binary        | 
| character_set_results | utf8         | 
| character_set_server  | latin1        | 
| character_set_system  | utf8         | 
| character_sets_dir  | /opt/mysql/server-5.6/share/charsets/ | 
+--------------------------+---------------------------------------+ 
mysql> select '\U+1F600'; 
+------+ 
|  | 
+------+ 
|  | 
+------+ 
mysql> set names utf8mb4; 
mysql> select '\U+1F600'; 
+------+ 
| ? | 
+------+ 
|  | 
+------+

在我看來，utf8mb4旨在支持這些表情符號字符。爲什麼更改爲utf8mb4，列名更改爲問號？

此外，我從網站（http://getemoji.com/）複製了表情符號，然後粘貼到終端。如果我只是手動輸入'\ U + 1F600'。見下：

mysql> select '\U+1F600' ; 
+---------+ 
| U+1F600 | 
+---------+ 
| U+1F600 | 
+---------+

所以我想當我把它粘貼在終端有隱含的事情發生。這個隱式轉換（ - >'\ U + 1F600'）也許可以解釋這個現象。

來源

2015-05-04 zhuguowei

根據MySQL文檔的說法，這似乎是預期的行爲，其中元數據被聲明爲存儲在utf8（非4字節版本）中。

它以character_set_result（utf8mb4）的形式返回給客戶端，但很可能您的虛擬列名稱存儲在utf8中，與所有其他元數據兼容且可比，因此字符的4字節部分甚至會丟失儘管它並不是真實的表格。

在這裏看到： https://dev.mysql.com/doc/refman/5.6/en/charset-metadata.html

來源

2015-05-04 05:21:35

謝謝！可能你是對的，但我不太確定。 – zhuguowei

我非常有信心，文檔通常會說所有表元數據都專門存儲爲utf8。所以它非常有意義。 –

嘿，我發現了這個問題的一些新的信息，也許你感興趣。看到我的帖子下面。 – zhuguowei

我已經使用的Wireshark中發現更多的信息。請看下圖：

之前執行組名稱utf8mb4
執行組名稱utf8mb4

enter image description here

在這種情況下，服務器無法找到一個字符集後數字，所以列名成爲問號。而且看起來Charset編號並不重要，只需要它不是未知。如果我執行集名latin1，響應數據包信息是： enter image description here

來源

2015-05-10 12:49:23 zhuguowei

爲什麼在執行設置名稱utf8mb4後，列名更改爲問號？

回答

相關問題