MySQL GBK→UTF-8エンコード変換

まえがき:
これは初めてチュートリアルを書くもので、実際にはチュートリアルではなく、変換メモを要約したいだけです。途中で間違いがあったり、やり方が理想的ではなかったりする場合は、返信して勉強してください。
さらに、私たちのフォーラムが単なるおしゃべりの場ではなく、誰もが私たちのフォーラムの学習雰囲気を活性化できることを願っています。結局のところ、私たちは皆、私たちに知識を与えるべき場所の出身です。そこからどれだけ得ることができたとしても、知識が必要です。

さて、本題に取り掛かりましょう。

最初の準備:
環境: MySQL4.1.x 以降。
Convertz - テキストエンコーディング変換ツール、molyx で紹介されており、私はそれを使用しています。実際、そのようなツールはたくさんあります。

2 番目の理論:
MySQL の内部ストレージ文字セットは、バージョン 4.1 から UTF-8 をサポートします。これはここ数日で見たばかりです。というのは、フォーラムをアップグレードする過程でサーバーのデータベース環境が 4.0.26 だったのですが、当時はそれが UTF-8 文字セットをサポートしていないことを知らなかったので、紆余曲折を経なければなりませんでした。このように、UTF-8 ダンプが関係する場合は、MySQL のバージョンを 4.1 以降にアップグレードする必要があります。
変換の一般的な考え方は - バックアップ (準備の有無にかかわらず) → データベースの修復 → mysqldump エクスポート → Convertz 変換エンコーディング → 変換されたファイルの変更 → mysqldump インポートのリカバリ

3 つの実践方法:
1バックアップ。これについてはあまり説明する必要はありませんが、自分で復元する限り、従来のバックアップ方法を使用できます。
2.修理。 mysqlcheck -r -u user -p すべてがOKであれば、OKです。そうでない場合は、再試行してください。まだ大丈夫ではないので、どうすればいいのかわかりません。
3. エクスポートします。 latin1 がデフォルトのストレージであるため、データベースのエンコード形式を事前に決定する必要があります。たとえば、lncz.net は元々 gbk としてエンコードされていましたが、latin1 として保存されました。この場合、エクスポート後に gbk テキストが ANSI 形式で正しく表示されるように、エクスポート時にエンコードを latin1 として指定する必要があります。
エクスポート コマンド: mysqldump データベース名フィールド > path --default-character-set=latin1 -u user -p
大規模なデータベースはセグメント化する必要があります。そうしないと、次の操作が非常に面倒になります。各テーブルを個別にエクスポートしました。当時のアイデアは比較的単純でした。データベース内に不良テーブルがあり、リカバリ中にどのテーブルにエラーがあるのか​​を知り、それを個別に修正したいだけだったからです。
4. 変換。 Convertz の使い方は非常に簡単で、これ以上言う必要はありません。
5. 修正。リカバリデータベースを直接インポートしようとしたところ、N回失敗して毎回文字化けしてしまいました。よく考えた結果、直接インポートし直すと、データベースは引き続きストレージにデフォルトの latin1 を使用し、現在のエンコーディングは utf-8 であるため、別の変換が実行され、エラーが発生することに気付きました。 MySQL がこれをどのように処理するのか正確にはわかりません。知っている人がいたら教えてください。このとき、変換されたファイルに「set names utf8;」という文を追加する必要があり、ファイル内の「CHARSET=latin1;」を「CHARSET=utf8」に変更する必要があります。 ;" テーブルのストレージエンコーディングを指定します。
6. 回復。論理的に言えば、リカバリプロセスは非常に単純であるはずで、すべて mysqldump によって処理されます。注意すべき点は、データベースが大きい場合は、グローバル変数 max_allowed_pa​​cket を変更する必要があることです。デフォルトは 1M です。データベース テーブルのサイズに応じて、my.ini ファイルを変更します。
インポート コマンド: mysqldump データベース名

以下の料理を比較してください。間違いがあれば修正して笑ってください。上記は参考用です。