MySQL在導入時不會保留字符信息

Question

我試圖導入一個大的SQL文件;由一個服務器上的mysqldump創建，然後使用iconv轉換;使用這些命令：

$ mysqldump -uxxx -p xxx > data.sql 
$ iconv -f UTF-8 -t ISO-8859-1//TRANSLIT data.sql data.iconv.sql 

我注意到， 「\ X91」 數據庫已在轉儲變成 「\ XC3 \ X82 \ XC2 \ X91」，因爲mysqldump的嘗試都轉換爲UTF-8。我用iconv將它轉換回「\ x91」。如果我不轉換它們，它們最終會成爲新服務器上的「\ xc2 \ x3f」;而不僅僅是「\ x3f」，就像我們現在一樣。

因此，如前所述，cp1252編碼有一些獨特的字符，例如「\ x91」和「\ x92」。這兩個字符在新數據庫中都轉爲「\ x3f」;這是我用進口的命令：

$ /opt/mysql5/bin/mysql -uxxx -p -Dxxx < data.iconv.sql 

任何人都知道這是怎麼發生和怎樣做才能預防呢？知道這一點，我應該能夠像原來一樣移植數據。

額外信息：

我用this source了用於iconv-事情。正如你所看到的，在這個頁面上，另外一個人也對cp1252產生了麻煩;也許這是原因。

的serverversion是：

老主持人：版本10.10 DISTRIB 5.0.18，爲PC-Linux的GNU（1486） 新主機：版本10.11 DISTRIB 5.0.51，爲PC-Linux的GNU （i686）

Answer 1

如果你的數據是cp1252你爲什麼要告訴iconv它的utf-8？

Answer 2

我還沒找到工作解決方案;我們將嘗試使用腳本，使2個連接和簡單地從一個連接選擇和更新其他遷移...

Answer 3

嘗試： -

的iconv -f IBM-1252 -t ISO-8859- 1

不知道爲什麼我以前的答覆被標記下來。 utf-8不是ASCII！所有7位utf字符與7位ASCI字符集相同，但第一位b'1000000'在UTF-8中有特殊含義，並表示該字符是一個unicode兩個三字節或四字節字符。

Answer 4

如果MySQL轉換爲UTF-8，然後你想：

iconv -f utf-8 -t IBM-1252 xxxx 

這應該轉換公開報價回X 「91」。 對於公開報價，「xc291」確實是utf-8。

Answer 5

你使用的是什麼版本的mysqldump？

最新版本發佈5裹表與設定的字符集命令轉儲，如：

SET @saved_cs_client  = @@character_set_client; 
SET character_set_client = utf8; 

CREATE TABLE ... 
... 
... 
SET character_set_client = @saved_cs_client; 

可能存在/不存在的，這些是影響您的導入？

Answer 6

在我的系統上，mysqld默認使用瑞典語整理將數據保存在latin1中。同樣，mysql命令行客戶端默認使用latin1提供數據。另一方面，mysqldump默認爲utf-8。

當通過mysqldump導出數據，然後使用mysql命令行客戶端導入時，會導致問題 - 兩個字符集不常見的字符發生變異。

解決辦法是讓mysqldump的使用將正確設置MySQL客戶字符集附加命令來裝點數據：

mysqldump --set-charset ... 

這將默認，加上「set name = utf-8」到轉儲數據。這現在可以通過mysql客戶端乾淨地導入。

附加選項「--default-character-set=xxx」可以與mysqldump一起使用將轉儲轉換爲utf-8以外的其他選項。

使用-set-charset選項應該可以防止您根本不必使用iconv。