MySQL バックアップ文字セットの問題に関する簡単な説明

[はじめに] 1 はじめに MySQL をバックアップする際の文字セットの選択は、特に可変文字セットを使用する企業にとっては難しい問題です。 Mysqldump はデフォルトで utf8 を使用し、utf8 も公式に推奨されています。しかし実際には、中国語の場合、かなりの数の gbk エンコード文字に対応する Unicode エンコードがありません。これは、文字セットのこの部分が意味します

1 はじめに

MySQL をバックアップする際の文字セットの選択は、特に難しい問題です可変文字セットを使用するビジネス向け。 Mysqldump はデフォルトで utf8 を使用し、utf8 も公式に推奨されています。しかし実際には、中国語の場合、gbk でエンコードされた文字のかなりの部分に、対応する Unicode エンコードがありません。つまり、文字セットのこの部分に utf8 バックアップを使用すると、データ損失が発生します。それで解決策はあるのでしょうか？

もちろん、最も直接的な方法は、エンコーディングのこの部分のマッピングを追加することです。ただし、文字セットのこの部分の数は少なくなく、さらに厄介なのは、文字セットのこの部分に対する信頼できるマッピング標準がないようであることです。それで、他の方法はありますか？

実際、バックアップにバイナリを使用する場合、文字セットの変換プロセスは存在しないため、上記の問題は存在しません。では、バイナリを使用すると gbk の問題はすべて解決されるのでしょうか?答えはいいえだ。

2 二項問題

二項問題について話す前に。明確にする必要がある質問が 2 つあります。 MySQL バックアップの場合、スキーマ情報と実際のデータの 2 つの部分に分かれています。スキーマ情報は、デフォルト値を除き、常に utf8 でエンコードされます。問題はここからです。

2.1 utf8 バックアップ

(1) ファイル .frm はテーブルのスキーマ情報を保存し、実際のレコードを通じて各フィールドのデフォルト値を保存します。スキーマに相当する情報（コメント含む）はutf8で格納されますが、デフォルト値はテーブルで指定された文字セットで格納されます。

(2) show create table ステートメントを実行すると、mysqld は frm のデフォルト値をテーブルで指定されたエンコーディングから utf8 エンコーディングに変換します。

(3) mysqld が create table ステートメントを実行すると、デフォルト値が utf8 からテーブルで指定された文字セットに変換されます。

2.2 バイナリバックアップ

バックアップにバイナリが指定されている場合。インポート時、テーブルを作成する前に、character_set_client は utf8 として指定されていますが、collat​​ion_connection はバイナリのままです。したがって、デフォルト値を格納する際には、utf8 からテーブルで指定された文字セットへの変換は行われません。テーブルが gbk エンコードとして指定されている場合、インポートは必然的に失敗します。

例:

リーリー

正常にエクスポートされたテーブルが、「1067 Invalid default value」というエラーとともにインポートされたことがわかります。

3 解決策

mysqldumpを使用する場合、create tableステートメントを実行する前にcharacter_set_connectionの設定を追加します。

/*!40101 SETcharacter_set_connection = utf8 */

これもMySQLのバグです。スキーマ情報は最初から最後までutf8を使用しているため、create tableを実行する前に接続文字セットを変更する必要があります。この変数は、クライアントの文字セット変数を設定するだけではなく、utf8 に設定されます。

上記は、MySQL バックアップ文字セットの問題に関する簡単な説明です。その他の関連コンテンツについては、PHP 中国語 Web サイト (www.php.cn) に注目してください。