MySQL的字符編碼機制在複雜性和不透明性方面都具有傳奇色彩,我對如何正確解釋從MySQL連接器/ C查詢返回的字符串數據有疑問。連接器/ C的MySQL字符編碼
如果我的連接器/ C++代碼設置爲UTF-8
(使用mysql_set_character_set()
),將MySQL庫(和/或服務器)這是存儲在服務器UTF-8
還是我仍然需要在使用mysql_fetch_field
在latin1
轉碼數據基於每個字段來確定任何字符串數據的字符集?
MySQL的字符編碼機制在複雜性和不透明性方面都具有傳奇色彩,我對如何正確解釋從MySQL連接器/ C查詢返回的字符串數據有疑問。連接器/ C的MySQL字符編碼
如果我的連接器/ C++代碼設置爲UTF-8
(使用mysql_set_character_set()
),將MySQL庫(和/或服務器)這是存儲在服務器UTF-8
還是我仍然需要在使用mysql_fetch_field
在latin1
轉碼數據基於每個字段來確定任何字符串數據的字符集?
給這個頁面的讀取:http://dev.mysql.com/doc/refman/5.7/en/charset-connection.html
由於mysql_set_character_set()
作品像SET NAMES
聲明,它會修改字符集服務器發送回客戶端。
SET NAMES指示客戶端將用於發送SQL語句到服務器的字符集。因此,SET NAMES的'cp1251'告訴服務器,「來自這個客戶端的未來傳入消息使用字符集cp1251」。它還指定了服務器用於將結果發送回客戶端的字符集。 (例如,如果使用SELECT語句,它指示要使用哪些字符集作爲列值。)
在Latin1和UTF-8中正確編碼的字符串之間發生衝突極其不可能。您可以檢查正確的UTF-8編碼,並假設Latin1爲嚴重編碼的字符串,並根據具體情況自行轉換它們。假設正確的配置和編碼處處都是有風險的。
因此,沒有必要做任何「每場」。在'SELECT'期間,所有文本列都從列的字符集轉碼爲由'mysql_set_character_set()'指定的字符集。 –