[はじめに] 1 はじめに MySQL をバックアップする際の文字セットの選択は、特に可変文字セットを使用する企業にとっては難しい問題です。 Mysqldump はデフォルトで utf8 を使用し、utf8 も公式に推奨されています。しかし実際には、中国語の場合、かなりの数の gbk エンコード文字に対応する Unicode エンコードがありません。これは、文字セットのこの部分が意味します
MySQL をバックアップする際の文字セットの選択は、特に難しい問題です可変文字セットを使用するビジネス向け。 Mysqldump はデフォルトで utf8 を使用し、utf8 も公式に推奨されています。しかし実際には、中国語の場合、gbk でエンコードされた文字のかなりの部分に、対応する Unicode エンコードがありません。つまり、文字セットのこの部分に utf8 バックアップを使用すると、データ損失が発生します。それで解決策はあるのでしょうか?
もちろん、最も直接的な方法は、エンコーディングのこの部分のマッピングを追加することです。ただし、文字セットのこの部分の数は少なくなく、さらに厄介なのは、文字セットのこの部分に対する信頼できるマッピング標準がないようであることです。それで、他の方法はありますか?
実際、バックアップにバイナリを使用する場合、文字セットの変換プロセスは存在しないため、上記の問題は存在しません。では、バイナリを使用すると gbk の問題はすべて解決されるのでしょうか?答えはいいえだ。
二項問題について話す前に。明確にする必要がある質問が 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 として指定されていますが、collation_connection はバイナリのままです。したがって、デフォルト値を格納する際には、utf8 からテーブルで指定された文字セットへの変換は行われません。テーブルが gbk エンコードとして指定されている場合、インポートは必然的に失敗します。
例:
CREATE TABLE `t1`( `iNetbarId` int(11) NOT NULL DEFAULT '0', `iUin` bigint(20) NOT NULL DEFAULT '0', `vNetbarName` varchar(80) NOT NULL DEFAULT '"-"', PRIMARY KEY (`iNetbarId`) ) ENGINE=InnoDB DEFAULT CHARSET=gbk;
t1 値に挿入(1,1,' xxxx'); |
正常にエクスポートされたテーブルが、1067 Invalid default value のエラーでインポートされたことがわかります。
mysqldumpを使用する場合、create tableステートメントを実行する前にcharacter_set_connectionの設定を追加します。
/*!40101 SETcharacter_set_connection = utf8 */
これもMySQLのバグです。スキーマ情報は最初から最後までutf8を使用しているため、create tableを実行する前に接続文字セットを変更する必要があります。この変数は、クライアントの文字セット変数を設定するだけではなく、utf8 に設定されます。
以上がMySQL バックアップ文字セットに関するディスカッションの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。