MySQL GBK→UTF-8エンコード変換_PHPチュートリアル

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

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

最初の準備:
環境: 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 データベース名フィールド > パス --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 を変更する必要があることです。データベース テーブルのサイズに応じて、my.ini ファイルを変更します。デフォルトは 1M です。
インポート コマンド: mysqldump データベース名 < path -u user -p インポートがスムーズに完了すると、データベースのエンコーディングは utf-8 に変換されます。


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