いや、まあ、MySQL に限ったことじゃないけどな。
PostgreSQL にしても、バックアップしてリストアしたデータが化けちゃうってのは良くあることで、まあ、最初の原型作ったヤツらにとっては英語が全てなわけで、その後多言語化のために色々な仕組みが継ぎ足されたわけだから、問題が起こって当たり前って感じもしますが。
日本語だけでも、何個のコード体系があるんだよ、実際。(^^;
今回の MovableType の移行でもハマったぁ!
mysqldump によるバックアップ時と、mysql によるリストア時の、default-character-set の指定だけで何とかならんかいなと色々やったんだけど、結局、
で、文字コード変えずにバックアップして、mtos_20091106.dump を一旦ローカル PC にダウンロード。
で、秀丸エディタを使って中身を修正。
修正箇所は、
この、「ENGINE=MyISAM DEFAULT CHARSET=latin1;」の部分。
ここが、latin1 になってるので、utf8 に修正する(テーブルの数だけ。40箇所くらいかな)。
「ENGINE=MyISAM DEFAULT CHARSET=utf8;」という具合に。
で、これを新サーバにアップして、
とリストアする。
この方法以外ではどうすることも出来なかった。
ああ・・・面倒臭い、面倒臭い。元の MySQL の設定にも依存しちゃうし、なかなかすっきりいかないもんですなあ。
Tweet
PostgreSQL にしても、バックアップしてリストアしたデータが化けちゃうってのは良くあることで、まあ、最初の原型作ったヤツらにとっては英語が全てなわけで、その後多言語化のために色々な仕組みが継ぎ足されたわけだから、問題が起こって当たり前って感じもしますが。
日本語だけでも、何個のコード体系があるんだよ、実際。(^^;
今回の MovableType の移行でもハマったぁ!
mysqldump によるバックアップ時と、mysql によるリストア時の、default-character-set の指定だけで何とかならんかいなと色々やったんだけど、結局、
mysqldump --default-character-set=binary -u hoge -phoge mtos > mtos_20091106.dump
で、文字コード変えずにバックアップして、mtos_20091106.dump を一旦ローカル PC にダウンロード。
で、秀丸エディタを使って中身を修正。
修正箇所は、
DROP TABLE IF EXISTS `mt_ts_job`;
SET @saved_cs_client = @@character_set_client;
SET character_set_client = utf8;
CREATE TABLE `mt_ts_job` (
`ts_job_jobid` int(11) NOT NULL AUTO_INCREMENT,
<略>
KEY `mt_ts_job_funccoal` (`ts_job_funcid`,`ts_job_coalesce`),
KEY `mt_ts_job_funcrun` (`ts_job_funcid`,`ts_job_run_after`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
SET character_set_client = @saved_cs_client;
この、「ENGINE=MyISAM DEFAULT CHARSET=latin1;」の部分。
ここが、latin1 になってるので、utf8 に修正する(テーブルの数だけ。40箇所くらいかな)。
「ENGINE=MyISAM DEFAULT CHARSET=utf8;」という具合に。
で、これを新サーバにアップして、
mysql --default-character-set=utf8 -u hogehoge -p mtos < mtos_20091106.dump
とリストアする。
この方法以外ではどうすることも出来なかった。
ああ・・・面倒臭い、面倒臭い。元の MySQL の設定にも依存しちゃうし、なかなかすっきりいかないもんですなあ。
コメントする