2011-10-19 8 views
1

私はデータマイグレーションを不正にしてしまいました。mysqlダンプ内の非常に奇妙な文字 - 何をするか?


北京东方å›悦大酒店<br />\n<br />\n“The impetus 

私はその中の文字のこれらの種類でMySQLデータのダンプを与えてきた。これらの奇妙な文字は、実際のMySQLのダンプファイルであるように埋め込まれています。私は最初にmysqlテーブルを作り直し、DrupalのMigrateモジュールを使ってそれらに対してクエリを実行することで、Drupalにデータをインポートします。

コードは次のようになります。

DROP TABLE IF EXISTS `news`; 
SET @saved_cs_client  = @@character_set_client; 
SET character_set_client = utf8; 
CREATE TABLE `news` (
    `id` int(11) NOT NULL auto_increment, 
    `uid` int(11) NOT NULL, 
    `pid` int(11) default NULL, 
    `puid` int(11) default NULL, 
    `headline` varchar(255) NOT NULL, 
    `teaser` varchar(500) NOT NULL, 
    `status` char(1) default NULL, 
    `date` datetime NOT NULL, 
    `url` varchar(255) default NULL, 
    `url_title` varchar(255) default NULL, 
    `body` text, 
    `caption` varchar(255) default NULL, 
    `gid` int(11) default NULL, 
    `feature` text, 
    `related` varchar(255) default NULL, 
    `change1_time` int(11) default NULL, 
    `change2_time` int(11) default NULL, 
    `change1_user` varchar(255) default NULL, 
    `change2_user` varchar(255) default NULL, 
    `expires` datetime default NULL, 
    `rank` char(1) default NULL, 
    PRIMARY KEY (`id`), 
    KEY `uid` (`uid`), 
    KEY `status` (`status`), 
    KEY `expires` (`expires`), 
    KEY `rank` (`rank`), 
    KEY `puid` (`puid`), 
    FULLTEXT KEY `headline` (`headline`,`teaser`,`body`) 
) ENGINE=MyISAM AUTO_INCREMENT=6976 DEFAULT CHARSET=utf8; 
SET character_set_client = @saved_cs_client; 

最速のソリューションがここに勝者である - 私はタイトな締め切りによ、本当にこっちに苦しんで!私は検索とソリューションの置き換えを試みましたが、奇妙なデータが多すぎるように見えます。何を伝えるべきか分かっていれば、新しいデータダンプをオーケストレーションすることができます(データダンプのやり方)。

おかげで、 ジョン

+1

上記の例の平文が分かりますか? Otあなたはこれらの文字を削除するためのソリューションを探していますか? – 0xCAFEBABE

+1

データがエンコードA(おそらくUTF-8)を使用してエクスポートされ、エンコードB(おそらくISO-8859-1)を使用して読み込まれているとします。受信データをUTF-8として扱うには、インポートを指示する必要があります。 – Jon

+0

実際のmysqlダンプファイルのような奇妙な文字だけが埋め込まれています。 – user2890

答えて

4

これは、あなたの質問に直接答えではないですが、私はあなたがあなたの記事で引用されmojibakeでビットを果たしました。最初はUTF-8エンコーディングの中国語テキストのようで、Windows-1252エンコーディングのでラテン語テキストとして解釈され、がUTF-8で再エンコードされ、Windows-1252として再度解釈されました(最後にもう一度UTF-8としてエンコードされますここにそれを掲示した)。だからそれはちょうどmojibakeではない、ダブル mojibakeです。

また、文字列の途中からバイトが失われました(おそらく、Windows-1252の未定義コードポイントの1つであったため)、元の文字の1つをマングリングします。逆にエンコーディングチェーン(Windowsの-1252としてエンコード、UTF-8としてデコード、リピート)を通じてテキストを実行すると、私は出力を得る:

北京东方�悦大酒店<br />\n<br />\n“The impetus 

マングルされた文字を表し置換文字。

+0

あなたの調査はどうやって行ったのですか?スクリプト?あなたはこの混乱からの道として何を提案しますか? – user2890

+0

変換のためにPerl [Encode module](http://perldoc.perl.org/Encode.html)を使用しました。 ( 'iconv'もおそらくうまくいったでしょう)。最初は、ISO Latin 1としてデコードされたUTF-8だと思っていましたが、私はそれを試してみたところ、' ''と ''€ ' ISO Latin 1レパートリーには属していなかったので、おそらくWindows-1252だったはずです。その後、私はそれを試してみましたが、私はmojibakeを出力として得ましたので、もう一度試しました。それを修正するために、欠けているそれらのバイトが、(ここで切り取って貼り付けたサンプルからではなく)データ自体から欠落しているため、修正不可能な場合があります。 –

+0

Gulp。ありがとうございました。 PHPと同等のことを知っていますか?私は何千ものページのデータを移行しているので、いくつかの壊れた文字列はここで、そして、そこには取引を破ることはありません。 – user2890