字符集轉換概述

我們有必要說明一下，字符其實是面向人類的一個概念，計算機可并不關心字符是什麼，它隻關心這個字符對應的字節編碼是什麼。對于一個字節序列，計算機怎麼知道它是使用什麼字符集編碼的呢？計算機不知道，所以其實在計算機中表示一個字符串時，都需要附帶上它對應的字符集是什麼，就像這樣（以C 語言為例）：

class String {byte* content;CHARSET_INFO* charset;}

比方說我們現在有一個以utf8字符集編碼的漢字'我'，那麼意味着計算機中不僅僅要存儲'我'的utf8編碼0xE68891，還需要存儲它是使用什麼字符集編碼的信息，就像這樣：

{content: 0xE68891;charset: utf8;}

計算機内部包含将一種字符集轉換成另一種字符集的函數庫，也就是某個字符在某種字符集下的編碼可以很順利的轉換為另一種字符集的編碼，我們将這個過程稱之為字符集轉換。比方說我們可以将上述采用utf8字符集編碼的字符'我'，轉換成gbk字符集編碼的形式，就變成了這樣：

{content: 0xCED2;charset: gbk;}

小貼士：我們上邊所說的'編碼'可以當作動詞，也可以當作名詞來理解。當作動詞的話意味着将一個字符映射到一個字節序列的過程，當作名詞的話意味着一個字符對應的字節序列。大家根據上下文理解'編碼'的含義。

mysql客戶端和服務器是怎麼通信的

MySQL客戶端發送給服務器的請求以及服務器發送給客戶端的響應其實都是遵從一定格式的，我們把它們通信過程中事先規定好的數據格式稱之為MySQL通信協議，這個協議是公開的，我們可以簡單的使用wireshark等截包軟件十分方便的分析這個通信協議。在了解了這個通信協議之後，我們甚至可以動手制作自己的客戶端軟件。市面上的MySQL客戶端軟件多種多樣，我們并不想各個都分析一下，現在隻選取在MySQL安裝目錄的bin目錄下自帶的mysql程序（此處的mysql程序指的是名字叫做mysql的一個可執行文件），如圖所示：

我們在計算機的黑框框中執行該可執行文件，就相當于啟動了一個客戶端，就像這樣：

小貼士：我們這裡的'黑框框'指的是Windows操作系統中的cmd.exe或者UNIX系統中的Shell。

我們通常是按照下述步驟使用MySQL的：

1. 啟動客戶端并連接到服務器

2. 客戶端發送請求。

3. 服務器接收到請求

4. 服務器處理請求

5. 服務器處理請求完畢生成對該客戶端的響應

6. 客戶端接收到響應

下邊我們就詳細分析一下每個步驟中都影響到了哪些字符集。

啟動客戶端并連接到服務器過程

每個MySQL客戶端都維護者一個客戶端默認字符集，這個默認字符集按照下邊的套路進行取值：

自動檢測操作系統使用的字符集

MySQL客戶端會在啟動時檢測操作系統當前使用的字符集，并按照一定規則映射成為MySQL支持的一些字符集（通常是操作系統當前使用什麼字符集，就映射為什麼字符集，有一些特殊情況，比方說如果操作系統當前使用的是ascii字符集，會被映射為latin1字符集）。

當我們使用UNIX操作系統；

此時會調用操作系統提供的nl_LANGinfo(CODESET)函數來獲取操作系統當前正在使用的字符集，而這個函數的結果是依賴LC_ALL、LC_CTYPE、LANG這三個環境變量的。其中LC_ALL的優先級比LC_CTYPE高，LC_CTYPE的優先級比LANG高。也就是說如果設置了LC_ALL，不論有沒有設置LC_CTYPE或者LANG，最終都以LC_ALL為準；如果沒有設置LC_ALL，那麼就以LC_CTYPE為準；如果既沒有設置LC_ALL也沒有設置LC_CTYPE，就以LANG為準。比方說我們将環境變量LC_ALL設置為zh_CN.UTF-8，就像這樣：

export LC_ALL=zh_CN.UTF-8

那麼我們在黑框框裡啟動MySQL客戶端時，MySQL客戶端就會檢測到這個操作系統使用的是utf8字符集，并将客戶端默認字符集設置為utf8。當然，如果這三個環境變量都沒有設置，那麼nl_langinfo(CODESET)函數将返回操作系統默認的字符集，比方說在我的macOS 10.15.3操作系統中，該默認字符集為：

US-ASCII

此時MySQL客戶端的默認字符集将會被設置為latin1。另外，我們這裡還需要強調一下，我們使用的黑框框展示字符的時候有一個自己特有的字符集，比如在我的mac上使用iTerm2作為黑框框，我們可以打開：Preferences->Profiles->Terminal選項卡，可以看到iTerm2使用utf8來展示字符：

我們一般要把黑框框展示字符時采用的編碼和操作系統當前使用的編碼保持一緻，如果不一緻的話，我們敲擊的字符可能都無法顯示到屏幕上。比方說如果我此時把LC_ALL屬性設置成GBK，那麼我們再向黑框框上輸入漢字的話，屏幕都不會顯示了，就像這樣（如下圖所示，我敲擊了漢字'我'的效果）：

當我們使用Windows操作系統時

此時會調用操作系統提供的GetConsoleCP函數來獲取操作系統當前正在使用的字符集。在Windows裡，會把當前cmd.exe使用的字符集映射到一個數字，稱之為代碼頁（英文名：code page），我們可以通過右鍵點擊cmd.exe标題欄，然後點擊屬性->選項，如下圖所示，當前代碼頁的值是936，代表當前cmd.exe使用gbk字符集：

更簡便一點，我們可以運行chcp命令直接看到當前code page是什麼：

這樣我們在黑框框裡啟動MySQL客戶端時，MySQL客戶端就會檢測到這個操作系統使用的是gbk字符集，并将客戶端默認字符集設置為gbk。我們前邊提到的utf8字符集對應的代碼頁為65001，如果當前代碼頁的值為65001，之後再啟動MySQL客戶端，那麼客戶端的默認字符集就會變成utf8。如果MySQL不支持自動檢測到的操作系統當前正在使用的字符集，或者在某些情況下不允許自動檢測的話，MySQL會使用它自己的内建的默認字符集作為客戶端默認字符集。這個内建的默認字符集在MySQL 5.7以及之前的版本中是latin1，在MySQL 8.0中修改為了utf8mb4。使用了default-character-set啟動參數如果我們在啟動MySQL客戶端是使用了default-character-set啟動參數，那麼客戶端的默認字符集将不再檢測操作系統當前正在使用的字符集，而是直接使用啟動參數default-character-set所指定的值。比方說我們使用如下命令來啟動客戶端：

mysql --default-character-set=utf8

那麼不論我們使用什麼操作系統，操作系統目前使用的字符集是什麼，我們都将會以utf8作為MySQL客戶端的默認字符集。

在确認了MySQL客戶端默認字符集之後，客戶端就會向服務器發起登陸請求，傳輸一些諸如用戶名、密碼等信息，在這個請求裡就會包含客戶端使用的默認字符集是什麼的信息，服務器收到後就明白了稍後客戶端即将發送過來的請求是采用什麼字符集編碼的，自己生成的響應應該以什麼字符集編碼了（劇透一下：其實服務器在明白了客戶端使用的默認字符集之後，就會将character_set_client、character_set_connection以及character_set_result這幾個系統變量均設置為該值）。

客戶端發送請求

登陸成功之後，我們就可以使用鍵盤在黑框框中鍵入我們想要輸入的MySQL語句，輸入完了之後就可以點擊回車鍵将該語句當作請求發送到服務器，可是客戶端發送的語句（本質是個字符串）到底是采用什麼字符集編碼的呢？這其實涉及到應用程序和操作系統之間的交互，我們的MySQL客戶端程序其實是一個應用程序，它從黑框框中讀取數據其實是要調用操作系統提供的讀取接口。在不同的操作系統中，調用的讀取接口其實是不同的，我們還得分情況讨論一下：

• 對于UNIX操作系統來說

  在我們使用某個輸入法軟件向黑框框中輸入字符時，該字符采用的編碼字符集其實是操作系統當前使用的字符集。比方說當前LC_ALL環境變量的值為zh_CN.UTF-8，那麼意味着黑框框中的字符其實是使用utf8字符集進行編碼。稍後MySQL客戶端程序将調用操作系統提供的read函數從黑框框中讀取數據（其實就是所謂的從标準輸入流中讀取數據），所讀取的數據其實就是采用utf8字符集進行編碼的字節序列，稍後将該字節序列作為請求内容發送到服務器。這樣其實會産生一個問題，如果客戶端的默認字符集和操作系統當前正在使用的字符集不同，那麼将産生比較尴尬的結果。比方說我們在啟動客戶端是攜帶了--default-character-set=gbk的啟動參數，那麼客戶端的默認字符集将會被設置成gbk，而如果操作系統此時采用的字符集是utf8。比方說我們的語句中包含漢字'我'，那麼客戶端調用read函數讀到的字節序列其實是0xE68891，從而将0xE68891發送到服務器，而服務器認為客戶端發送過來的請求都是采用gbk進行編碼的，這樣就會産生問題（當然，這僅僅是發生亂碼問題的前奏，并不意味着産生亂碼，亂碼隻有在最後一步，也就是客戶端應用程序将服務器返回的數據寫到黑框框裡時才會發生）。

• 對于Windows操作系統來說

  在Windows操作系統中，從黑框框中讀取數據調用的是Windows提供的ReadConsoleW函數。在該函數執行後，MySQL客戶端會得到一個寬字符數組（其實就是一組16位的UNICODE），然後客戶端需要把該寬字符數組再次轉換成客戶端使用的默認字符集編碼的字節序列，然後才将該字節序列作為請求的内容發送到服務器。這樣在UNIX操作系統中可能産生的問題，在Windows系統中卻可以避免。比方說我們在啟動客戶端是攜帶了--default-character-set=gbk的啟動參數，那麼客戶端的默認字符集将會被設置成gbk，假如此時操作系統采用的字符集是utf8。比方說我們的語句中包含漢字'我'，那麼客戶端調用ReadConsoleW函數先讀到一個代表着我字的寬字符數組，之後又将其轉換為客戶端的默認字符集，也就是gbk字符集編碼的數據0xCED2，然後将0xCED2發送到服務器。此時服務器也認為客戶端發送過來的請求就是采用gbk進行編碼的，這樣就完全正确了～

服務器接收請求

服務器接收到到的請求本質上就是一個字節序列，服務器将其看作是采用系統變量character_set_client代表的字符集進行編碼的字節序列。character_set_client是一個SESSION級别的系統變量，也就是說每個客戶端和服務器建立連接後，服務器都會為該客戶端維護一個單獨的character_set_client變量，每個客戶端在登錄服務器的時候都會将客戶端的默認字符集通知給服務器，然後服務器設置該客戶端專屬的character_set_client。我們可以使用SET命令單獨修改character_set_client對應的值，就像這樣：

SET character_set_client=gbk;

需要注意的是，character_set_client對應的字符集一定要包含請求中的字符，比方說我們把character_set_client設置成ascii，而請求中發送了一個漢字'我'，将會發生這樣的事情：

mysql> SET character_set_client=ascii;Query OK, 0 rows affected (0.00 sec)mysql> SHOW VARIABLES LIKE 'character%'; -------------------------- ------------------------------------------------------ | Variable_name | Value | -------------------------- ------------------------------------------------------ | character_set_client | ascii || character_set_connection | utf8 || character_set_database | utf8 || character_set_filesystem | binary || character_set_results | utf8 || character_set_server | utf8 || character_set_system | utf8 || character_sets_dir | /usr/local/Cellar/mysql/5.7.21/share/mysql/charsets/ | -------------------------- ------------------------------------------------------ 8 rows in set (0.00 sec)mysql> SELECT '我'; ----- | ??? | ----- | ??? | ----- 1 row in set, 1 warning (0.00 sec)mysql> SHOW WARNINGS\G*************************** 1. row ***************************Level: WarningCode: 1300Message: Invalid ascii character string: '\xE6\x88\x91'1 row in set (0.00 sec)

如圖所示，最後提示了'E6、88、91'并不是正确的ascii字符。

小貼士：可以将character_set_client設置為latin1，看看還會不會報告WARNINGS，以及為什麼～

服務器處理請求

服務器在處理請求時會将請求中的字符再次轉換為一種特定的字符集，該字符集由系統變量character_set_connection表示，該系統變量也是SESSION級别的。每個客戶端在登錄服務器的時候都會将客戶端的默認字符集通知給服務器，然後服務器設置該客戶端專屬的character_set_connection。不過我們之後可以通過SET命令單獨修改這個character_set_connection系統變量。比方說客戶端發送給服務器的請求中包含字節序列0xE68891，然後服務器針對該客戶端的系統變量character_set_client為utf8，那麼此時服務器就知道該字節序列其實是代表漢字'我'，如果此時服務器針對該客戶端的系統變量character_set_connection為gbk，那麼在計算機内部還需要将該字符轉換為采用gbk字符集編碼的形式，也就是0xCED2。

有同學可能會想這一步有點兒像脫了褲子放屁的意思，但是大家請考慮下邊這個查詢語句：

mysql> SELECT 'a' = 'A';

請問大家這個查詢語句的返回結果應該是TRUE還是FALSE？其實結果是不确定。這是因為我們并不知道比較兩個字符串的大小到底比的是什麼！我們應該從兩個方面考慮：

• 考慮一：這些字符串是采用什麼字符集進行編碼的呢？

• 考慮二：在我們确定了編碼這些字符串的字符集之後，也就意味着每個字符串都會映射到一個字節序列，那麼我們怎麼比較這些字節序列呢，是直接比較它們二進制的大小，還是有别的什麼比較方式？比方說'a'和'A'在utf8字符集下的編碼分别為0x61和0x41，那麼'a' = 'A'是應該直接比較0x61和0x41的大小呢，還是将0x61減去32之後再比較大小呢？其實這兩種比較方式都可以，每一種比較方式我們都稱作一種比較規則（英文名：collation）。

MySQL中支持若幹種字符集，我們可以使用SHOW CHARSET命令查看，如下圖所示（太多了，隻展示幾種，具體自己運行一下該命令）：

mysql> SHOW CHARSET; ---------- --------------------------------- --------------------- -------- | Charset | Description | Default collation | Maxlen | ---------- --------------------------------- --------------------- -------- | big5 | Big5 Traditional Chinese | big5_chinese_ci | 2 || latin1 | cp1252 West European | latin1_swedish_ci | 1 || latin2 | ISO 8859-2 Central European | latin2_general_ci | 1 || ascii | US ASCII | ascii_general_ci | 1 || gb2312 | GB2312 Simplified Chinese | gb2312_chinese_ci | 2 || gbk | GBK Simplified Chinese | gbk_chinese_ci | 2 || utf8 | UTF-8 Unicode | utf8_general_ci | 3 || utf8mb4 | UTF-8 Unicode | utf8mb4_general_ci | 4 || utf16 | UTF-16 Unicode | utf16_general_ci | 4 || utf16le | UTF-16LE Unicode | utf16le_general_ci | 4 || utf32 | UTF-32 Unicode | utf32_general_ci | 4 || binary | Binary pseudo charset | binary | 1 || gb18030 | China National Standard GB18030 | gb18030_chinese_ci | 4 | ---------- --------------------------------- --------------------- -------- 41 rows in set (0.04 sec)

其中每一種字符集又對應着若幹種比較規則，我們以utf8字符集為例（太多了，也隻展示幾個）：

mysql> SHOW COLLATION WHERE Charset='utf8'; -------------------------- --------- ----- --------- ---------- --------- | Collation | Charset | Id | Default | Compiled | Sortlen | -------------------------- --------- ----- --------- ---------- --------- | utf8_general_ci | utf8 | 33 | Yes | Yes | 1 || utf8_bin | utf8 | 83 | | Yes | 1 || utf8_unicode_ci | utf8 | 192 | | Yes | 8 || utf8_icelandic_ci | utf8 | 193 | | Yes | 8 || utf8_latvian_ci | utf8 | 194 | | Yes | 8 || utf8_romanian_ci | utf8 | 195 | | Yes | 8 | -------------------------- --------- ----- --------- ---------- --------- 27 rows in set (0.00 sec)

其中utf8_general_ci是utf8字符集默認的比較規則，在這種比較規則下是不區分大小寫的，不過utf8_bin這種比較規則就是區分大小寫的。在我們将請求中的字節序列轉換為character_set_connection對應的字符集編碼的字節序列後，也要配套一個對應的比較規則，這個比較規則就由collation_connection系統變量來指定。我們現在通過SET命令來修改一下和collation_connection的值分别設置為utf8和utf8_general_ci，然後比較一下'a'和'A'：

mysql> SET character_set_connection=utf8;Query OK, 0 rows affected (0.00 sec)mysql> SET collation_connection=utf8_general_ci;Query OK, 0 rows affected (0.00 sec)mysql> SELECT 'a' = 'A'; ----------- | 'a' = 'A' | ----------- | 1 | ----------- 1 row in set (0.00 sec)

可以看到在這種情況下這兩個字符串就是相等的。

我們現在通過SET命令來修改一下和collation_connection的值分别設置為utf8和utf8_bin，然後比較一下'a'和'A'：

mysql> SET character_set_connection=utf8;Query OK, 0 rows affected (0.00 sec)mysql> SET collation_connection=utf8_bin;Query OK, 0 rows affected (0.00 sec)mysql> SELECT 'a' = 'A'; ----------- | 'a' = 'A' | ----------- | 0 | ----------- 1 row in set (0.00 sec)

可以看到在這種情況下這兩個字符串就是不相等的。

當然，如果我們并不需要單獨指定将請求中的字符串采用何種字符集以及比較規則的話，并不用太關心character_set_connection和collation_connection設置成啥，不過需要注意一點，就是character_set_connection對應的字符集必須包含請求中的字符。

服務器處理請求完畢生成對該客戶端的響應

為了故事的順利發展，我們先創建一個表：

CREATE TABLE t (c VARCHAR(100)) ENGINE=INNODB CHARSET=utf8;

然後向這個表插入一條記錄：

INSERT INTO t VALUE('我');

現在這個表中的數據就如下所示：

mysql> SELECT * FROM t; ------ | c | ------ | 我 | ------ 1 row in set (0.00 sec)

我們可以看到該表中的字段其實是使用utf8字符集編碼的，所以底層存放格式是：0xE68891，将它讀出後需要發送到客戶端，是不是直接将0xE68891發送到客戶端呢？這可不一定，這個取決于character_set_result系統變量的值，該系統變量也是一個SESSION級别的變量。服務器會将該響應轉換為character_set_result系統變量對應的字符集編碼後的字節序列發送給客戶端。每個客戶端在登錄服務器的時候都會将客戶端的默認字符集通知給服務器，然後服務器設置該客戶端專屬的character_set_result。我們也可以使用SET命令來設置character_set_result的值。不過也需要注意，character_set_result對應的字符集應該包含響應中的字符。這裡再強調一遍，character_set_client、character_set_connection和character_set_result這三個系統變量是服務器的系統變量，每個客戶端在與服務器建立連接後，服務器都會為這個連接維護這三個變量，如圖所示（我們假設連接1的這三個變量均為utf8，連接1的這三個變量均為gbk，連接1的這三個變量均為ascii，）：

一般情況下character_set_client、character_set_connection和character_set_result這三個系統變量應該和客戶端的默認字符集相同，SET names命令可以一次性修改這三個系統變量：

SET NAMES 'charset_name'

該語句和下邊三個語句等效：

SET character_set_client = charset_name;SET character_set_results = charset_name;SET character_set_connection = charset_name;

不過這裡需要大家特别注意，SET names語句并不會改變客戶端的默認字符集！

客戶端接收到響應

客戶端收到的響應其實仍然是一個字節序列。客戶端是如何将這個字節序列寫到黑框框中的呢，這又涉及到應用程序和操作系統之間的一次交互。

• 對于UNIX操作系統來說，MySQL客戶端向黑框框中寫入數據使用的是操作系統提供的fputs、putc或者fwrite函數，這些函數基本上相當于直接就把接收到的字節序列寫到了黑框框中（請注意我們用詞：'基本上相當于'，其實内部還會做一些工作，但是我們這裡就不想再關注這些細節了）。此時如果該字節序列實際的字符集和黑框框展示字符所使用的字符集不一緻的話，就會發生所謂的亂碼（大家注意，這個時候和操作系統當前使用的字符集沒啥關系）。比方說我們在啟動MySQL客戶端的時候使用了--default-character-set=gbk的啟動參數，那麼服務器的character_set_result變量就是gbk。然後再執行SELECT * FROM t語句，那麼服務器就會将字符'我'的gbk編碼，也就是0xCDE2發送到客戶端，客戶端直接把這個字節序列寫到黑框框中，如果黑框框此時采用utf8字符集展示字符，那自然就會發生亂碼。
• 對于Windows操作系統來說，MySQL客戶端向黑框框中寫入數據使用的是操作系統提供的WriteConsoleW函數，該函數接收一個寬字符數組，所以MySQL客戶端調用它的時候需要顯式地将它從服務器收到的字節序列按照客戶端默認的字符集轉換成一個寬字符數組。正因為這一步驟的存在，所以可以避免上邊提到的一個問題。比方說我們在啟動MySQL客戶端的時候使用了--default-character-set=gbk的啟動參數，那麼服務器的character_set_result變量就是gbk。然後再執行SELECT * FROM t語句，那麼服務器就會将字符'我'的gbk編碼，也就是0xCDE2發送到客戶端，客戶端将這個字節序列先從客戶端默認字符集，也就是gbk的編碼轉換成一個寬字符數組，然後再調用WriteConsoleW函數寫到黑框框，黑框框自然可以把它顯示出來。

亂碼問題應該如何分析

好了，介紹了各個步驟中涉及到的各種字符集，大家估計也看的眼花缭亂了，下邊總結一下我們遇到亂碼的時候應該如何分析，而不是胡子眉毛一把抓，随便百度一篇文章，然後修改某個參數，運氣好修改了之後改對了，運氣不好改了一天也改不好。知其然也要知其所以然，在學習了本篇文章後，大家一定要有節奏的去分析亂碼問題：

我使用的是什麼操作系統

對于UNIX系統用戶來說，要搞清楚我使用的黑框框到底是使用什麼字符集展示字符，就像是iTerm2中的character encoding屬性：同樣還要搞清楚操作系統當前使用什麼字符集，運行locale命令查看：王大爺喊你輸入呢，跟這兒>locale

LANG=""

LC_COLLATE="zh_CN.UTF-8"

LC_CTYPE="zh_CN.UTF-8"

LC_MESSAGES="zh_CN.UTF-8"

LC_MONETARY="zh_CN.UTF-8"

LC_NUMERIC="zh_CN.UTF-8"

LC_TIME="zh_CN.UTF-8"

LC_ALL="zh_CN.UTF-8"

王大爺喊你輸入呢，跟這兒>沒有什麼特别極端的特殊需求的話，一定要保證上述兩個字符集是相同的，否則可能連漢字都輸入不進去！對于Windows用戶來說搞清楚自己使用的黑框框的代碼頁是什麼，也就是操作系統當前使用的字符集是什麼。

搞清楚客戶端的默認字符集是什麼

啟動MySQL客戶端的時候有沒有攜帶--default-character-set參數，如果攜帶了，那麼客戶端默認字符集就以該參數指定的值為準。否則分析自己操作系統當前使用的字符集是什麼。

搞清楚客戶端發送請求時是以什麼字符集編碼請求的

對于UNIX系統來說，我們可以認為請求就是采用操作系統當前使用的字符集進行編碼的。

對于Windows系統來說，我們可以認為請求就是采用客戶端默認字符集進行編碼的。

通過執行SHOW VARIABLES LIKE 'character%'命令搞清楚：

character_set_client：服務器是怎樣認為客戶端發送過來的請求是采用何種字符集編碼的

character_set_connection：服務器在運行過程中會采用何種字符集編碼請求中的字符

character_set_result：服務器會将響應使用何種字符集編碼後再發送給客戶端的

客戶端收到響應之後：

對于服務器發送過來的字節序列來說：

在UNIX操作系統上，可以認為會把該字節序列直接寫到黑框框裡。此時應該搞清楚我們的黑框框到底是采用何種字符集展示數據。

在Windows操作系統上，該字節序列會被認為是由客戶端字符集編碼的數據，然後再轉換成寬字符數組寫入到黑框框中。

請認真分析上述的每一個步驟，然後發出驚呼：小樣，不就是個亂碼嘛，還治不了個你！

-END-

如果看到這裡，說明你喜歡這篇文章，請轉發。同時标星（置頂）本公衆号可以第一時間接受到博文推送。1.Restful快速開發後端腳手架今天聊聊HashMap和TreeMap的内部結構3.總結一些關于CPU的基本知識Nginx一個牛X的功能，流量拷貝！

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部