MySQL GBK→UTF-8符号化変換

前書き：初めて教程を書きますが、教程とは言えません。ただ転換の手記をまとめたいです。もし途中でミスがあったり、方法が理想的ではなかったら、みんなで研究してみます。その他に、私達のフォーラムが雑談の地方とするだけではないことをも望んで、みんなが私達のフォーラムの学習の雰囲気を活発にすることができることをも望んで、結局私達はすべて1つの知識をあげるべきな地方から来て、あなたはそこからどれだけあなたの必要な知識を獲得しましたかに関わらず。じゃ、本題に戻ります。準備：環境：MySQL 4.1.xおよび以上のバージョン。Convertz――テキストコード変換ツールは、molyxで紹介したものを採用します。実はこのようなものが多いです。第二理論：MySQLは4.1バージョンから内部記憶文字セットをUTF-8にサポートしています。これもこの数日間見ました。アップグレードのためのフォーラムの過程で、サーバーのデータベース環境は4.0.26で、当時はutf-8文字セットをサポートしていなかったことを知らなかった。このようにUTF-8のリポジットに関しては、4.1以上のMySQLバージョンをアップグレードする必要があります。変換の大まかな考え方は、バックアップ（準備の有無）→修復データベース→mysqldump導出→Covertz変換符号化→変換後ファイル→mysqldump導入復旧の3つの実践：1、バックアップ。これは多すぎる必要はありません。いつものバックアップ方式を採用してもいいです。自分で回復したらいいです。2、修復。mysql check -r -u。 user -p 全部OKならOKです。全部OKでないなら、また来ます。まだ全部OKしていません。どうしたらいいか分かりません。3、エクスポートします。latin 1はデフォルトの記憶なので、事前にあなたのデータベースのコードフォーマットを確認してください。例えば、lncz.netはもともとgbkコードであったが、latin 1として記憶されており、このようにエクスポートする時にはlatin 1として指定し、エクスポートしてからはANSI形式でgbkの文字を正しく表示することができる。エクスポートコマンド:mysqldump databasename field > パス --default-character-set=latin 1 -u。 user -pデータベースは大きく分ける必要があります。そうでないと次の操作は大変です。私は単独で各表を導いたのです。当时の考えは比较的に简単で、データベースには悪い表がありますので、复元の际にどの表が间违っているかを知りたいだけです。単独で修复します。4、変換。Convertzはこのソフトを使うのは簡単です。これ以上言う必要はありません。5、修正。私は直接データベースの再導入を試みていますが、何回も失敗しました。毎回文字化けしています。よく考えてみたら、直接誘導したら、データベースはやはりデフォルトのlatin 1で保存します。あなたの今のコードはutf-8です。だから、もう一度変換したらエラーが発生します。ここのMySQLはいったいどう処理しているのかまだよく分かりません。ここでは、変換されたファイルにステートメントを追加する必要があります。 “セット names utf 8;注意はutf-8ではありませんそして文書の中の「CHARSET=latin 1」を必要とします。「CHARSET=utf 8」に変更しました。を選択します。6、回復する。回復過程は道理で簡単なはずです。全部mysqldump処理です。注意すべき点は、あなたのデータベースが大きいとグローバル変数の修正max_を行います。allowed_パッケはデフォルトでは1 Mです。あなたのデータベーステーブルのサイズを見て、それに応じてmy.iniファイルを修正します。導入命令：mysqldump databasename < パス -u。 user -p 導入が順調にいけば、あなたのデータベースコードはすでにutf-8に変換されました。料理を比べていますが、間違いがあったら指摘してください。以上はご参考までに。