錯誤的字符串值：'\ xC2 \ x9Fe 10 ...'列

我們在服務器2003上運行一箇舊的5.1 Mysql服務器。最近我們轉移到一個更新的環境，使用Mysql 5.6和server 2008.現在，插入特殊字符如'Ã'時，我們不斷收到錯誤。錯誤的字符串值：' xC2 x9Fe 10 ...'列

現在我已檢查了源編碼，它是UTF-8。但舊的Mysql服務器被配置爲拉丁文1（服務器/表/殖民地）與整理latin_swedish_ci，我們沒有收到舊環境的任何錯誤。

現在我已經做了一些測試，因爲我們沒有生活在新的環境。我曾嘗試將所有表設置爲表/殖民地以及latin1。在這兩種情況下，我都會收到這些錯誤。

我注意到，在舊服務器上，服務器默認char-set是latin1，在新服務器上是utf-8。這可能是問題嗎？我覺得這很奇怪，因爲源代碼是utf-8。

是否有一些選項可以處理這個可以在舊環境中打開的選項？我不確定這樣的事情是否存在。我沒有比較mysql管理工具中的設置，除了默認的字符集外，它看起來是一樣的。

編輯：

SHOW VARIABLES LIKE '％炭';

舊服務器：

+--------------------------+-----------------------------------------------+ 
| 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           |

新服務器：

+--------------------------+-----------------------------------------------+ 
| Variable_name   | Value           | 
+--------------------------+-----------------------------------------------+ 
| character_set_client  | utf8mb4          | * 
| character_set_connection | utf8mb4          | * 
| character_set_database | utf8           | 
| character_set_filesystem | binary          | 
| character_set_results | utf8mb4          | * 
| character_set_server  | utf8           | 
| character_set_system  | utf8           |

據我從MySQL網站utf8mb4文章在明白的是一個超級組合utf8這不應該造成編碼問題，我認爲，因爲它們在編碼上基本相同嗎？

來源

2015-06-23 Florian Schaal

是的，utf8mb4比utf8更好。不過，還是需要在整個MySQL中保持一致。 'Ã'的背景是什麼？「C29Fe」？那裏可能有更多的線索。（仍然'Ã'在兩個字符集中都是有效的，C29F（我認爲）兩者都是無效的。） –

old UTF-8 of MySQL不是真正的UTF-8。如果您嘗試使用「特殊」字符（日文或中文），則可能最終會在舊服務器上留下方格或問號。

您的新服務器現在真正使用UTF-8（mb4代表多字節4）。服務器接收UTF-8字符，但顯然不能存儲UTF-8字符，因爲您的表不使用UTF-8。將所有表格轉換爲UTF-8和數據庫爲UTF-8，您就可以解決您的問題。

你可以這樣做：

ALTER DATABASE databasename CHARACTER SET utf8 COLLATE utf8_unicode_ci; 
ALTER TABLE tablename CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;

先別忘記備份。

來源：https://stackoverflow.com/a/6115705/1980659

來源

2015-07-03 15:02:18 ForguesR

據我可以看到這在新的服務器上工作。但是仍然沒有解決的問題是爲什麼它在舊服務器上工作。在我說的腳本中使用與源相同的設置。因此，我認爲它會和舊的一樣？還是有差異提到的編碼之間的版本？ –

當我將應用程序移動到新的env時，獲得了一個有經驗的人。當插入與要插入到表中的數據相關的數據時，我得到了一些奇怪的東西，我的情況它抱怨日期是空的，所以它不能被插入到表中（源代碼沒有變化，只有新的env（Mysql服務器從5.1到5.6下，Tomcat 6到Tomcat 7，新的Suse服務器版本）。

我試圖取代MySQL連接器的驅動程序到新版本我的應用程序，它解決了問題。

來源

2015-06-23 14:37:23

我剛剛檢查過，但是我們已經安裝了最新的mysql連接器odbc 5.3.4。 –

首先，由於舊的環境是第一個選擇是在新的環境中使用相同的「字符集」設置。如果仍然可以訪問5.0服務器，請抓取SHOW VARIABLES;。

5.0默認爲latin1; 5.6默認爲utf8。這主要在

mysql> SHOW VARIABLES LIKE 'char%'; 
+--------------------------+-----------------------------------------------+ 
| 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           |

SET NAMES utf8;設置三個標記的線。

Ã十六進制爲C3 in latin1和C383 in utf8。More encodings here。這樣做是爲了看看什麼是目前的一個表：

SELECT col, HEX(col) FROM table WHERE ...

另一種可能性是，「移動」缺胳膊少腿的數據。如果你可以在兩臺機器上執行相同的SELECT，如果它們出來的方式不同，那麼遷移是不好的。由於移動數據的方式很多，請提供移植的詳細信息，以便我們可以分析可能出現的問題。

在標題中，您有C29F。這是一個奇怪的 - 它是一個控制代碼APPLICATION PROGRAM COMMAND，我從來沒有聽說過。（注意：這與您後面提到的Ã無關。）請提供更多問題示例;這些線索都沒有幫助。

來源

2015-06-29 16:38:45

看我的編輯。我已經添加了兩臺服務器的輸出。我有一個新的測試數據庫，並會插入一些測試數據，爲您獲得更多的結果/案例。 –

這樣做的顯著的部分是你的舊服務器有：

| character_set_database | latin1

而新服務器有

| character_set_database | utf8

不要緊，連接和客戶端使用utf8如果數據庫使用latin1，表將默認爲latin1，因此數據將存儲在latin1中，您將得到您的錯誤。當然，您可以明確地將任何表的字符集和排序規則設置爲非數據庫默認值。

我猜，當您遷移數據庫模式時，您並未在運行遷移腳本之前編輯數據庫或表的編碼。

現在您可以手動更改數據庫和每個表，也可以編輯遷移腳本並重新運行它。大多數遷移腳本和數據庫轉儲將包括每個表以及數據庫的特定字符集，即使它們完全相同。

來源

2015-07-05 01:53:25

錯誤的字符串值：'\ xC2 \ x9Fe 10 ...'列

回答

相關問題