Mysql中国語文字化け解決策集

最初の方法:
MySQL 4.1 における中国語の文字化けの問題
最近 MySQL 4.0 を MySQL 4.1 にアップグレードしたところ、中国語の文字化けの問題を発見しました。以下の洞察が皆様のお役に立てば幸いです。
1. MySQL 4.1 では、文字セットと照合順序の概念が大幅に改善されました。
2. MySQL 4.0 では、一般的なプログラムはテキストをラテン語で保存します。これは、MySQL 4.0 と MySQL 4.0 のプログラムでは異なります。 、 問題はない。
3. ただし、MySQL 4.1 のシステムエンコーディングはデフォルトでは UTF-8 になっており、MySQL 4.0 のバックアップファイルを MySQL 4.1 に復元しようとすると文字化けが発生します。その理由は、MySQL 4.1 がラテン語コードを変換するため、その変換が完全ではなく、その結果、少量のテキストが文字化けするためです。
MySQL 4.1 にアクセスする PHP の文字化け問題を解決します
引用:
MySQL 4.1 から導入された多言語サポートは非​​常に優れており、いくつかの機能は他のデータベース システムを上回っています。ただし、テスト中に、MySQL 4.1 より前の MySQL に該当する PHP ステートメントを使用して MySQL データベースを操作すると、テーブルの文字セットが設定されていても文字化けが発生することがわかりました。新しい MySQL オンライン マニュアルの第 10 章「文字セットのサポート」を読んだ後、ついに解決策を見つけてテストに合格しました。
MySQL 4.1 の文字セット サポート (Character Set Support) には、文字セット (Character set) とソート方法 (照合順序) の 2 つの側面があります。文字セットのサポートは、サーバー、データベース、テーブル、接続の 4 つのレベルに細分化されています。
システムの文字セットとソート設定を表示するには、次の 2 つのコマンドを使用できます:
CODE:
mysql> SHOW VARIABLES LIKE 'character_set_%';
​​+------------- -- ----------+----------------------------+
| 値 | ------------------------+---------------------- -- ---+ 文字セット_接続
| 文字セット_ディレクトリ | mysql/charsets/
+ | ------------------------+--------------- ---------- ---+ セット内の 7 行 (0.00 秒)
mysql> 'collat​​ion_%' のような変数を表示
+--------------- --------+-- ----------+
| 変数名 |
+--------------- ----------+- -------+ 照合_接続 | 照合_データベース
| ------------+---------------+
3行セット(0.00秒)
上記の値はシステムのデフォルト値。なぜシステムがデフォルトでスウェーデン語のソート方法 latin1 を使用するのか疑問に思われる場合は、MySQL がスウェーデンの企業 T.c. によって開発されたからです。
本来の方法で PHP 経由で MySQL データベースにアクセスすると、テーブルのデフォルトの文字セットを utf8 に設定し、UTF-8 エンコードでクエリを送信したとしても、データベースに保存されているデータは依然として文字化けしていることがわかります。 。問題はこの接続層にあります。解決策は、クエリを送信する前に次の文を実行することです:
SET NAMES 'utf8';
CODE:
SET Character_set_client = utf8;
SET Character_set_connection = utf8; ;
もう一度試してください。これは正常ですか?
接続後にクエリを追加するだけです
CODE:
$this->query("SET NAMES ‘utf8＇");
マニュアルの第 10 章を読んだ後、主な問題は文字セットだと思います。
文字化けの鍵となるのはcharacter_set_client、character_set_results、character_set_connectionの3つの操作変数です。 mysql は、クライアントによって送信されたクエリをcharacter_set_client からcharacter_set_connection
に変換します。これは、デフォルトの Web ページによって送信されたクエリが gb2312 (フォームページのメタで確認できます) であり、mysql がデフォルトでそれを utf8 として扱うためです (character_set_client を見つけることができます)。このとき =utf8 ）なので文字化けしているはずです。同様に、mysql によって返される結果は、character_set_results エンコーディングに変換されています (テーブルのエンコーディングとは関係ありません)。デフォルトは utf8 であり、Web ページではそれを gb2312 として扱うため、フィールドが文字化けするはずです。データベースから読み取られたタイトルやその他のフィールドなど、他の部門のテキストは文字化けしません。
上記の例は utf8 文字セットです。この方法を使用して gbk に設定すると、問題が解決されます。
mysql 4.1 の文字化けに対する究極の解決策
この記事は mysql 4.1 のみを対象としていることに注意してください。 mysql の他のバージョンについては、記事を参照してください。
mysql4.1 は多言語の細かい設定に対応していて、しかもデフォルトが utf8 なのでどう作っても文字化けします。
さて、これ以上の苦労はせずに、この問題を段階的に解決しましょう:
1. /etc/my.cnf ファイルを次のように変更します:
[mysqld]
datadir=/var/lib/mysql
socket=/var/ lib/ mysql/mysql.sock
default-character-set=utf8
[mysql.server]
user=mysql
basedir=/var/lib
[mysqld_safe]
err-log=/var/log/mysqld.log
pid- file=/var/run/mysqld/mysqld.pid
注:default-character-set=utf8 という文を追加するだけです。
2./etc/init.d/mysqld restart mysql を再起動します。
3. phpmyadmin を開き、lang を「China simplifying(zh-utf-8)」として選択し、「MySQL connection校正」を「utf8_general_ci」として選択し、「表示」をクリックします。 「MySQL 実行情報」-「変数」で、以下を確認できます。
文字セット クライアント utf8 utf8
文字セット接続 utf8 utf8
文字セット データベース utf8 utf8
文字セット結果 utf8 utf8
文字セット サーバー utf8 utf8
文字セット システム utf8 utf8
照合接続 utf8_general_ci utf8_general_ci
照合データベース utf8_general_ci utf8_general_ci
照合サーバー utf8_general_ci utf8_general_ci
ここから、すべての文字がutf8になっていることがわかります。
なぜ utf8 に変更する必要があるのか​​と疑問に思う人もいるかもしれません。 GB2312に変更できないでしょうか？
説明は次のとおりです:
utf8 に変更したくないのですが、phpmyadmin2.6 は mysql4.1 の場合にのみ utf8 を使用します。他のページの文字セットも gb2312 に変更すると、間違いなく問題が発生します。文字化けは phpmyadmin しか作成できません。
mysql3.23 でのみ、phpmyadmin には追加のページ文字セット gb2312 が含まれますが、これは現時点では正常です。
3. 以前の mysql3 ライブラリ ファイルを mysql4.1 ライブラリにインポートします。
2 つの状況があります:
まず、phpmyadmin からインポートします。このとき、左下に「ファイル」があることに注意してください。ページの下部でライブラリ ファイルを選択します。文字セット: "、デフォルトは utf8 ですが、gb2312 に変更する必要があります。そうしないとインポートが文字化けします。
2 つ目は、Linux でインポートする場合、
SET NAMES 'gb2312'; という行を最初にライブラリ ファイルの先頭に追加します。最後の ; も数字であることに注意してください。
その後、 mysql -u username -p password xxx.sql > library name を実行します
インポートが完了したら、phpmyadminで開き、中の漢字が正しいことを確認します。
4. mysql4.1 からライブラリ ファイルをエクスポートします
1. phpmyadmin を使用してエクスポートします
phpmyadmin の閲覧ページに表示される中国語が正常であれば、エクスポートは正常である必要があります
2.
mysqldump でエクスポートするときに文字化けが発生しても問題ありません。iconv を実行して変換できます
iconv -c -f UTF-8 -t GB2312 ライブラリ ファイル名 > 新しい gb2312 ライブラリ ファイル名
まとめると、次のようにする必要があります。注:
1.インポートする必要があるライブラリ ファイルの先頭に SET NAMES 'gb2312' を追加してみてください。インポートするファイルが gb2312 ファイルであることを mysql に伝えます。おそらくこれが必要です:
SET NAMES 'utf8';
mysql にログインした後に使用します。文字の一部のパラメータを utf8 に変更すると、問題が軽減される場合がありますが、必須ではありません。
mysql で使用:
SHOW VARIABLES LIKE 'character_set_%';
​​現在のステータスを表示するために使用されます。
3. 文字化けが発生しても心配しないでください。まず、元のバックアップを保持することに注意してください。次に、iconv を使用して変換します。
通常の使用前に必ずインポートおよびエクスポートのテストを行って、問題がないことを確認してください。
もう一度説明します。インターネット上の多くの友人は、Mysql4.1 はアップグレードのみ可能であり、ダウングレードはできないと言っています。これは間違いです。 --compatibility パラメーターを追加してデータベースをエクスポートします。 . -character-set=このパラメータは文字セットを設定します。
デモ: mysqldump -uroot -pPassword --compatibility=mysql40 --default-character-set=gb2312 discuz>d:discuz.sql
ok このようにエクスポートされたファイルMysql4.0でも使えるのですが、今ではmysql5が新時代と言われていますが、公式サイトからダウンロードしてインストールしたmysql5は未だに文字化けします。この現象については次のとおりです:
公式にコンパイルされた mysql のデフォルトでサポートされているエンコーディングがラテン文字セットであるため、mysql のソース コードをダウンロードしてコンパイルすることをお勧めします。データベースで表示すると文字化けします。 MySQL をコンパイルするときに withcharset= エンコーディングを使用します。MySQL が中国語の検索とソートを直接サポートできるように、mysql をこのエンコーディング形式に簡単にコンパイルできます。 --with-extra-charsets パラメータは、他の使用可能な文字セットを指定します。
ソース コード パッケージをダウンロードして解凍し、INSTALL-SOURCE を開きます。ここでは、Linux での詳細なインストール方法を示します。したがって、注意する必要があるのは、次のconfigure コマンドだけです:
groupadd mysql
useradd -g mysql mysql
./configure --with-charset=gbk --with-collat​​ion=gbk_chinese_ci --with-extra-charsets=gb2312,big5,utf8,binary,ascii --prefix=/usr/local/mysql
make
make install
cp support-files/my-medium.cnf /etc/my.cnf
cd /usr/local/mysql
bin/mysql_install_db --user=mysql
chown -R root .
chown -R mysql var
chgrp -R mysql
bin/mysqld_safe --user=mysql &
bin/mysql
mysql>
グローバル文字セット パラメータはすべて gbk であることがわかります。それについて話し合う。
通常のmysql4.0と同じPHP操作を実行すると、中国語の文字化けが依然として表示されることがわかります。
ここで説明する必要があるのは、mysql 4.1 以降、mysql データベースに接続した後にアプリケーションの文字セットを指定する必要があることです。そうしないと、英語以外の文字によるテキスト アクセスは解釈できず、? 記号になります。
解決策は、mysql の新しいバージョンの要件に適応することです。
mysql データベースに接続した後、setcharacter setcharacterset を実行します。デフォルトの文字セットが一致する場合、このコマンドは最新バージョンの mysql 5 で免除されます。 storage:
setcharacter set gbk;
php では次のように記述する必要があります: mysql_query("setcharacter set gbk");
命令は大文字でも小文字でも構いません
phpwind と discuz は広く使用されている国内の PHP フォーラムです。上記の手順を理解した後、フォーラムのソース コードに小さな変更を加え、データベースを mysql5 に安全にアップグレードすることもできます。
include/db_mysql.php を見つけて function connect(...){ .....}
データベース mysql_select_db($dbname) ; の後に文 mysql_query('set Character set gbk') を追加して保存します。
2. ファイルのインポートとエクスポート: 非 GBK 文字を保存する場合は、インポートされたファイルの先頭に SET NAMES 'Character set' という行を追加する必要があります。最後にある ; 記号に注意してください。見逃せません。
ファイルのインポートとエクスポートの実行
mysql -u ユーザー名-p パスワード データベース名
mysqldump -u ユーザー名-p パスワード データベース名>data.sql
mysqldump でエクスポートしたデータが文字化けしていても問題ありません。iconv を実行すると、変換します:
iconv -c -f utf8 -t gbk ライブラリ ファイル名 > 新しい gbk ライブラリ ファイル名
要約すると、次の点に注意する必要があります:
1.インポートする必要があるライブラリ ファイルの先頭にセット名「gbk」を追加してみてください。インポートしたいものが gbk ファイルであることを mysql に伝えます。現在の文字セットのステータスを表示するには、show variables; または mysql の 'character_set_%'; のような変数を使用します。
3.文字化けが発生しても心配しないでください。第一に、元のバックアップを保持することに注意し、第二に、iconv を使用して変換する必要があります。
#PHP 接続の問題:
MySQL 4.1 から始まるパスワード ハッシュ アルゴリズムの変更により、クライアントが認証プロトコルをサポートしていないという問題がデータベースに接続するときに発生する可能性があります
この問題は mysql 5 には存在せず、mysql 5 では認証プロトコルを必要としません以下の設定。
データベース ユーザーのパスワードの不一致の問題は、次の 2 つの方法で解決できます。
1 つ目: mysql> SET PASSWORD FOR 'some_user'@'some_host' = OLD_PASSWORD('newpwd'); 2 つ目: mysql> Password = OLD_PASSWORD('newpwd') Where Host = 'some_host' AND User = 'some_user'
PHP 出力のその他の文字化けコードの問題:
mysql がデフォルトのエンコーディング gbk にコンパイルされると、非 gbk データが直接たとえば、一部の文字が utf8 に保存されている場合、データの大部分が utf8 文字セットにある場合、当然ながら、mysql をデフォルトのエンコーディング utf8 にコンパイルする必要があります。
Mysql 4.1 のリリース後。 `mytest` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
ただし、mysql データベースに接続した後、このステートメントを使用して設定する必要があります: set names 'utf8'; php で設定するには、プログラムは正しくエンコードされた文字を取得し、Web ページに表示します。
mysql_query("set names 'utf8'",$connection);
インターネット上の多くの友人は、Mysql4.1 はアップグレードのみ可能であり、データベースのエクスポートには使用できないと言っています。 --compatibility パラメータを追加します。文字セットを設定するパラメータである --default-character-set= を忘れないでください。
デモ: mysqldump -uroot -pPassword --compatibility=mysql40 --default-character-set=gb2312 discuz>d:discuz.sql
ok この方法でエクスポートされたファイルは、Mysql4.0.X および Mysql.3.2 で使用できます。バージョン で使用されていますが、考えてみてください。4 つの理由から、これを書き留めておくことには意味があります。MySQL 4.1 では、多言語サポートに大きな変更が加えられています (これにより問題が発生します)
MySQL 3 が依然としてほとんどの場所 (個人使用およびホスティング プロバイダーを含む) で優勢ですが、MySQL 4.1 は MySQL の公式バージョンであり、推奨データベースはすでに提供されています。ホスティングプロバイダーによって提供され、今後もさらに提供される予定です。
多くの PHP プログラムはデフォルトのデータベース管理ソフトウェアとして MySQL を使用しますが、通常は MySQL 4.1 と 4.1 より前のバージョンを区別せず、一般に MySQL 3 と呼ばれます。 xx.xx 以降」はインストール要件を満たすことができます。
latin1 は多くの場所でデフォルトの文字セットとして使用されているため (特定の場所については後で詳しく説明します)、多くの PHP プログラム開発者とユーザーをうまく騙しています。中国語やその他の言語環境で発生する可能性のある問題;
簡単に言うと、MySQL 自体と MySQL を使用する PHP プログラムの変更がこれを無視しており、問題の発生と複雑化につながり、ほとんどのユーザーが英語を使用しているため、この問題は発生しません。真剣に受け止められていません。ここで説明する PHP プログラムは主に WordPress に関するものです。
MySQL 4.1 でのキャラクタ セット サポートの原則。MySQL 4.1 のキャラクタ セットの仕様は、マシン、データベースの 1 つ、テーブルの 1 つ、および列。ただし、従来の Web プログラムはデータベースやデータ テーブルを作成するときにこのような複雑な構成を使用しません。では、デフォルトの構成はどこから来たのでしょうか。
MySQL をコンパイルするとき、デフォルトの文字セット (latin1) が指定されます。
MySQL をインストールするとき、設定ファイル (my.ini) でデフォルトの文字セットを指定できます。指定しない場合、この値はコンパイル中に Specified から継承されます。 ;
mysqld を起動するときに、コマンドラインパラメータでデフォルトの文字セットを指定できます。指定しない場合、この値は設定ファイルから継承されます。新しいデータベース、明示的に指定しない限り、データベースの文字セットはデフォルトでcharacter_set_serverに設定されます。
データベースが選択されると、character_set_databaseはデータベースのデフォルトの文字セットに設定されます。テーブルのデフォルトの文字セットは、このデータベースのデフォルトの文字セットであるcharacter_set_databaseに設定されます。
テーブルに列を設定するとき、明示的に指定されていない限り、この列のデフォルトの文字セットは、テーブル; この文字セットは、データベースにデータを保存するために実際に使用される文字セットであり、mysqldump によって出力されるコンテンツは、この文字セットの下にあります。
簡単にまとめると、何も変更されない場合、すべてのテーブルのすべてのフィールドが対象となります。ただし、MySQL をインストールする場合、通常は多言語サポートを選択します。つまり、インストール プログラムは、設定ファイルのデフォルトで、default_character_set を UTF-8 に設定します。すべてのデータベースのすべてのテーブルは UTF-8 で保存されます。
PHP プログラムが MySQL との接続を確立するとき、プログラムによって MySQL に送信されるデータはどの文字セットを使用しますか? MySQL には知る方法がありません (せいぜい推測することしかできません)。そのため、MySQL 4.1 では、クライアントがこの文字セット (character_set_client) を指定する必要があります。MySQL の奇妙な点は、取得した文字セットがすぐにはその文字セットに変換されないことです。その文字セットはデータベースに保存されますが、最初はcharacter_set_connection変数で指定された文字セットに変換されますが、接続層が何に使用されるのかよくわかりませんが、character_set_connectionの文字セットに変換した後も必要です。つまり、データを出力するときに、データベースのデフォルトの文字セットからcharacter_set_resultsで指定された文字セットに変換する必要があります。
典型的な環境 典型的な環境では、MySQL 4.1 が自分のコンピュータにインストールされている場合を例に挙げます。Apache 2、PHP 5、および WordPress 1.5.1.3 は、MySQL 設定ファイルで utf8 として指定されています。そこで問題が発生します:
WordPress はデフォルトでインストールされているため、すべてのテーブルはデータの保存に UTF-8 を使用します。
WordPress で採用されているデフォルトの閲覧文字セットは UTF-8 ([オプション]->[読み取り] で設定) であるため、すべての WP ページは UTF-8 を使用します。メタは文字セットが utf-8 であることを示します
したがって、ブラウザはすべての WP ページを utf-8 モードで表示し、書き込みのすべての投稿とコメントはブラウザから Apache に UTF-8 形式で送信されます。次に、Apache はそれを PHP に渡します。つまり、WP がすべてのフォームから取得したデータは、変換せずに MySQL に直接送信されます。MySQL のデフォルトのcharacter_set_clientとcharacter_set_connectionは両方ともlatin1です。このとき、実際には「latin1として変換」されたUTF-8形式のデータでしたが、実際にはlatin1に変換されました。これら 2 つの変換の後、一部の utf-8 文字が失われ、?? になります。最終出力では、character_set_results はデフォルトで latin1 になります。これは、出力が奇妙であることを意味します。
最も驚くべきことはこれではありません。WordPress が GB2312 形式で読み取るように設定されている場合、WP によって MySQL に送信された GB2312 でエンコードされたデータは「as latin1」に変換され、奇妙な形式でデータベースに保存されます。奇妙な形式です。mysqldump の後で見つけることができます。utf-8 または gb2312 として読み取られても文字化けします)、この形式が latin1 として出力される場合は、GB2312 に戻すことができます。
これはどのような現象を引き起こしますか？ WP が MySQL 4.1 データベースを使用している場合、エンコーディングが GB2312 に変更されても正常になります。残念ながら、この正常性は表面的なものにすぎません。
問題の解決方法 せっかちな方は (ほぼ間違いなく) グーグルで検索してください。ほとんどの答えは、SET NAMES 'utf8' の前にクエリを実行するというものであることがわかります。はい、これが解決策ですが、目的はこの記事では、これが解決策である理由を説明します。
結果が正しいことを確認するには、データ テーブルで使用されている形式が正しいこと、つまり、少なくともすべての漢字を格納できることを確認する必要があります。その場合、選択肢は gbk または utf-8 の 2 つだけになります。以下utf-8の状況。
設定ファイルに設定されているdefault_character_setがutf8であるため、データテーブルはデフォルトでutf-8を使用して作成されます。これは、MySQL 4.1 を使用するすべてのホスティング プロバイダーで採用される構成である必要があります。したがって、確認する必要があるのは、クライアントと MySQL の間で指定されたエンコーディングが正しいことだけです。
可能性は 2 つだけあり、クライアントが gb2312 形式でデータを送信するか、utf-8 形式でデータを送信します。
gb2312 形式で送信する場合:
SETcharacter_set_client='gb2312'
SETcharacter_set_connection='utf8' または
SETcharacter_set_connection='gb2312'
どちらも受け入れられ、どちらもエンコード変換中にデータが失われないことを保証できます。データベースに保存されている内容は正しいことが保証されています。
正しいコンテンツが確実に取得されるようにするにはどうすればよいですか?ほとんどのクライアント (WP を含む) では、送信されるデータのエンコーディングが受信を予期するデータのエンコーディングであることを考慮すると、次のようになります:
SET Character_set_results='gb2312'
ブラウザに表示される形式が gb2312 であることが保証されます。
2 番目のケースで、クライアントが utf-8 形式 (WP のデフォルト) で送信する場合は、次の設定を使用できます:
SET Character_set_client='utf8'
SET Character_set_connection='utf8'
SET Character_set_results='utf8'
この設定は、SET NAMES 'utf8' と同等です。
WP が行うべき変更は依然として同じ文です。クライアントがどのようなコード化されたデータをデータベースに送信したいのかをデータベースが正確に知ることは不可能です。したがって、WP は正しい SET を送信する必要があります。 .. .MySQL の場合。最も適切な送信方法は何ですか?台湾の pLog の同僚は、次のような提案をしました:
まず、サーバーが 4.1 以上であるかどうか、コンパイル時に UTF-8 サポートが追加されるかどうかをテストします。そうであれば、続行します
次に、データベースが保存されている形式 ($dbEncoding) をテストします。 SET NAMES $dbEncoding
2点目については、上記の典型的な構成ではWPの場合とは異なりますが、WPを使用する限りデータベースはUTF-8で保存する必要があるため、ユーザーに合わせて判断する必要があります。 GB2312 または UTF-8 でのブラウジングの設定 (bloginfo('charset')) ですが、この値はデータベースに接続した後にのみ取得できるため、最も効率的な方法は、データベースに接続した後にこの設定に従って SET NAMES を 1 回設定することです。各クエリの前にデータベースを再設定するのではなく、データベースを再設定します。
私の変更は次のようになります。 wp_includes/wp-db.php に追加します。
function set_charset($charset)
// まず mysql のバージョンを確認します
$serverVersion = mysql_get_server_info($this->dbh) ; version =explode('.', $serverVersion);
if ($version[0] // utf8 サポートがコンパイルされたかどうかを確認します
$result = mysql_query("SHOW CHARACTER SET like 'utf8' ",
$this->dbh);
if (mysql_num_rows($result) if ($charset == 'utf-8' || $charset == 'UTF-8')
$charset = 'utf8';
@mysql_query("SET NAMES '$charset'", $this->dbh);
}
wp-settings.php で (ABSPATH . WPINC . '/ vars.php') ); 次に追加します:
$wpdb->set_charset(get_bloginfo('charset'));

1. MySQL 4.1 には、文字セットと照合順序の概念が含まれています。
2. MySQL 4.0 では、一般的なプログラムはテキストをラテン語で保存します。これは、MySQL 4.0 と MySQL 4.0 では異なります。問題はない。
3. ただし、MySQL 4.1 のシステムエンコーディングはデフォルトでは UTF-8 になっており、MySQL 4.0 のバックアップファイルを MySQL 4.1 に復元しようとすると文字化けが発生します。その理由は、MySQL 4.1 がラテン語コードを変換するため、その変換が完全ではなく、その結果、少量のテキストが文字化けするためです。
4. この文字化けしたコードの問題を解決するのは難しくありません。まず、MySQL 4.0 をバックアップする場合は、すべてのテキスト フィールドをバイナリ型に変更してから、通常のバックアップを実行します。 2 番目のステップでは、MySQL 4.1 で以前のバックアップを復元できます。最後に、先ほどバイネイ型に変更したテキストフィールドを再度テキスト型に戻します。このようにして、中国語エンコードの問題は完全に解決されるはずです。
5. テキスト フィールドをバイナリ タイプに変更する場合は、バイナリ列の長さをテキスト フィールドの長さ以上 (>=) に設定する必要があります。そうしないと、データが失われます。
6. さらに、この方法でアップグレードされた MySQL データベースは MySQL 4.1 で正常に動作し、どのようにバックアップおよび復元しても文字化けの問題は発生しなくなります。
作者: MySQL 公開日: 2005-12-14
mysql4.1はかなり面倒、多言語の詳細設定に対応、phpmyadmin2.6も割とバカでデフォルトは変更不可のutf8で文字化けする。どうやっても。
それでは、早速、この問題を段階的に解決していきましょう:
1. /etc/my.cnf ファイルを次のように変更します:
[mysqld]
datadir=/var/lib/mysql
socket=/var /lib /mysql/mysql.sock
default-character-set=utf8
[mysql.server]
user=mysql
basedir=/var/lib
[mysqld_safe]
err-log=/var/log/mysqld.log
pid -file=/var/run/mysqld/mysqld.pid
注:default-character-set=utf8 という文を追加するだけです。
2./etc/init.d/mysqld restart mysql を再起動します。
3. phpmyadmin を開き、lang を「China simplifying(zh-utf-8)」として選択し、「MySQL connection校正」を「utf8_general_ci」として選択し、「表示」をクリックします。 「MySQL 実行情報」-「変数」で、以下を確認できます。
文字セット クライアント utf8 utf8
文字セット接続 utf8 utf8
文字セット データベース utf8 utf8
文字セット結果 utf8 utf8
文字セット サーバー utf8 utf8
文字セット システム utf8 utf8
照合接続 utf8_general_ci utf8_general_ci
照合データベース utf8_general_ci utf8_general_ci
照合サーバー utf8_general_ci utf8_general_ci
ここから、すべての文字がutf8になっていることがわかります。
なぜ utf8 に変更する必要があるのか​​と疑問に思う人もいるかもしれません。 GB2312に変更できないでしょうか？
説明は次のとおりです:
utf8 に変更したくないのですが、phpmyadmin2.6 は mysql4.1 の場合にのみ utf8 を使用します。他のページの文字セットも gb2312 に変更すると、間違いなく問題が発生します。文字化けは phpmyadmin しか作成できません。
mysql3.23 でのみ、phpmyadmin には追加のページ文字セット gb2312 が含まれますが、これは現時点では正常です。
3. 以前の mysql3 ライブラリ ファイルを mysql4.1 ライブラリにインポートします。
2 つの状況があります:
まず、phpmyadmin からインポートします。このとき、左下に「ファイル」があることに注意してください。ページの下部でライブラリ ファイルを選択します。文字セット: "、デフォルトは utf8 ですが、gb2312 に変更する必要があります。そうしないとインポートが文字化けします。
2 つ目は、Linux でインポートする場合、
SET NAMES 'gb2312'; という行を最初にライブラリ ファイルの先頭に追加します。最後の ; も数字であることに注意してください。
その後、 mysql -u username -p password xxx.sql > library name を実行します
インポートが完了したら、phpmyadminで開き、中の漢字が正しいことを確認します。
4. mysql4.1 からライブラリ ファイルをエクスポートします
1. phpmyadmin を使用してエクスポートします
phpmyadmin の閲覧ページに表示される中国語が正常であれば、エクスポートは正常である必要があります
2.
mysqldump でエクスポートするときに文字化けが発生しても問題ありません。iconv を実行して変換できます
iconv -c -f UTF-8 -t GB2312 ライブラリ ファイル名 > 新しい gb2312 ライブラリ ファイル名
まとめると、次のようにする必要があります。注:
1.インポートする必要があるライブラリ ファイルの先頭に SET NAMES 'gb2312' を追加してみてください。インポートするファイルが gb2312 ファイルであることを mysql に伝えます。おそらくこれが必要です:
SET NAMES 'utf8';
mysql にログインした後に使用します。文字の一部のパラメータを utf8 に変更すると、問題が軽減される場合がありますが、必須ではありません。
mysql で使用:
SHOW VARIABLES LIKE 'character_set_%';
​​現在のステータスを表示するために使用されます。
3. 文字化けが発生しても心配しないでください。まず、元のバックアップを保持することに注意してください。次に、iconv を使用して変換します。
通常の使用前に必ずインポートおよびエクスポートのテストを行って、問題がないことを確認してください。


MYSQL を 4.1.2 にアップグレードし、phpmyadmin は 2.6.2 を使用しています。データ テーブル内の中国語の文字を含む中国語フィールドはすべて文字化けし、エクスポートされたデータも文字化けします。以前の 2.5.7 を問題なく使用していたのですが、通常の漢字を表示するには phpmyadmin ファイルのどの設定を変更すればよいでしょうか。
これらの文字関連の変数は SQL と密接に関連しています:
character_set_client
character_set_connection
character_set_results
さらに、データベース内の対応するフィールドに設定されている文字セットです。フィールドに設定がない場合、デフォルトはその文字です。テーブルのセット、table 指定しない場合、デフォルトでデータベースが使用されます。
上記の 3 つの変数の機能は次のとおりです。 client はクライアントが送信する文字セットを表し、results はクライアントに送信される文字セットを表します (ここで送信されるものと送信されるものは必ずしも一致するわけではないため、これら 2 つは分離されています)。同じクライアント) の場合、接続はクライアントとデータベース間の接続として機能します。
これは具体的には次のとおりです。たとえば、mysql コマンドラインで、クライアントを gbk に、接続を utf8 に、結果を gbk に、データベースを big5 に設定します。
insert ステートメントを送信するとき、このステートメントは次のように使用されます。 gbk コードであり、最初に utf8 コード (接続) に変換され、次にそれを big5 (データベース) に変換してデータベースに挿入されます。
select ステートメントを実行すると、データベースから得られた結果は、big5 から utf8、gbk という逆のプロセスを経て、gbk の結果が得られます。
したがって、最も重要なことは、クライアントと結果を、使用しているクライアントと一致させることです。たとえば、Web ページが utf8 でエンコードされている場合、これら 2 つを utf8 に設定する必要があります。
mysql コマンドラインを使用するときは 2000 を使用しますが、これは gbk に設定する必要があります
そして、使用するセット名 XXX は、実際にはこれら 3 つの変数を同時に XXX に設定します。
この場合、データベース内の異なるテーブルまたはフィールドを異なる文字セットに設定できます。上記の 3 つの設定が正しい限り、データベース内で異なる文字セットを同時に使用できます。
データベース内の文字が正しい文字セットを使用していることを確認するように注意してください。たとえば、最初に間違った文字セットを設定した場合、データを挿入した後、その設定が正しくなかったとしても、データ自体のエンコードが正しくなくなります。元に戻すと正しく表示されません。
もう一つは、エンコーディング間の互換性です。 gbkには存在するが、utf8には存在しない文字がある場合、gbk-》utf8-》gbkの過程で「？」になります。
具体的な解決策については、もう一度お話します。
まず、アップグレードしたデータベースとテーブルとフィールドの文字セットを指定する必要があります。複数のエンコーディングを同時に使用しない場合は、通常、gb2312 または utf8 を使用します。データベースを構築するときに SQL ステートメントに追加することもでき、phpMyAdmin で対応する文字セットを変更することもできます。
次に、古いデータをインポートします。まず、データ ファイルのエンコーディングを決定します。 phpMyAdmin を使用してインポートする場合、インターフェイスにファイル エンコード オプションがあり、データ ファイルのエンコードと一致している必要があります。
mysql コマンドラインからインポートする場合は、上記の 3 つの変数を自分で設定し、名前を xxx に設定する必要があります。
他のクライアントプログラムを使用する場合は注意してください。
このようにして、新しいデータベースに転送された後の古いデータのエンコードは正しくなります。この手順を間違えると、後で正しい表示を得ることができなくなります。
その後、独自のプログラムになり、Web ページのエンコーディングに応じて set names xxx を 1 回実行できます。
これにより、基本的にエンコードが正しいことが保証されます。
インポートされたデータのエンコードが間違っている可能性が非常に高いです。

MYSQL データベースのデフォルト言語はスウェーデン語で、GB2312 文字を含むデータベースがあります。
データベースを再インストールせずにコードを解決する方法はありますか? MySQL 4.1 から導入された言語サポートは非​​常に優れており、いくつかの機能は他のデータベース システムを上回っています。ただし、テスト中に、MySQL 4.1 より前の MySQL に適した PHP ステートメントを使用して MySQL データベースを操作すると、テーブルの文字セットが設定されていても文字化けが発生することがわかりました。新しい MySQL オンライン マニュアルの第 10 章「文字セットのサポート」を読んだ後、ついに解決策を見つけてテストに合格しました。
MySQL 4.1 の文字セット サポート (Character Set Support) には、文字セット (Character set) とソート方法 (照合順序) の 2 つの側面があります。文字セットのサポートは、サーバー、データベース、テーブル、接続の 4 つのレベルに細分化されています。
システムの文字セットとソート設定を表示するには、次の 2 つのコマンドを使用できます:

mysql> SHOW VARIABLES LIKE 'character_set_%';
​​+---------------- - --------+---------------+
| 値 | ----------+-------------------------- ---
| 文字セット_クライアント | 文字セット_データベース
| SQL /文字セット/
+-------------------------------------+---------------------- ---- ------+
セット内の 7 行 (0.00 秒)
mysql> 'collat​​ion_%' のような変数を表示
+----------------- ---- -+-------------------+
| 値 | --+------+
| ラテン 1_スウェーデン語_サーバー | ----------+-------------------+
セット内の 3 行 (0.00 秒)

上にリスト値はシステムのデフォルト値です。 (システムがデフォルトでスウェーデン語のソート方法 latin1 に設定されているのは奇妙です)...
本来の方法で PHP 経由で MySQL データベースにアクセスすると、テーブルのデフォルトの文字セットが utf8 に設定されていてクエリが送信されても​​、 UTF-8 エンコードを使用しても、データベースに保存されているデータが依然として文字化けしていることがわかります。問題はこの接続層にあります。解決策は、クエリを送信する前に次の文を実行することです:
SET NAMES 'utf8';
SET Character_set_client = utf8;
SET Character_set_connection = utf8;試してみてください、それは普通ですか？ ^_^ お楽しみください!
具体的には、次の行をクエリの前に追加します:
mysql_query("SET NAMES 'gb2312';",$this->con);
文字に関連するものをよく読んでください。変数の中で、これらは SQL と密接に関連しています:
character_set_client
character_set_connection
character_set_results
さらに、これはデータベース内の対応するフィールドに設定された文字セットです。フィールドが設定されていない場合、デフォルトはその文字セットです。テーブル。デフォルトでは、データベースが使用されます。
上記の 3 つの変数の機能は次のとおりです。 client はクライアントが送信する文字セットを表し、results はクライアントに送信される文字セットを表します (ここで送信されるものと送信されるものは必ずしも一致するわけではないため、これら 2 つは分離されています)。同じクライアント) の場合、接続はクライアントとデータベース間の接続として機能します。
これは具体的には次のとおりです。たとえば、mysql コマンドラインで、クライアントを gbk に、接続を utf8 に、結果を gbk に、データベースを big5 に設定します。
insert ステートメントを送信するとき、このステートメントは次のように使用されます。 gbk コードであり、最初に utf8 コード (接続) に変換され、次にそれを big5 (データベース) に変換してデータベースに挿入されます。
select ステートメントを実行すると、データベースから得られた結果は、big5 から utf8、gbk という逆のプロセスを経て、gbk の結果が得られます。
したがって、最も重要なことは、クライアントと結果を、使用しているクライアントと一致させることです。たとえば、Web ページが utf8 でエンコードされている場合、これら 2 つを utf8 に設定する必要があります。
mysql コマンドラインを使用するときは 2000 を使用しますが、これは gbk に設定する必要があります
そして、使用するセット名 XXX は、実際にはこれら 3 つの変数を同時に XXX に設定します。
この場合、データベース内の異なるテーブルまたはフィールドを異なる文字セットに設定できます。上記の 3 つの設定が正しい限り、データベース内で異なる文字セットを同時に使用できます。
データベース内の文字が正しい文字セットを使用していることを確認するように注意してください。たとえば、最初に間違った文字セットを設定した場合、データを挿入した後、その設定が正しくなかったとしても、データ自体のエンコードが正しくなくなります。元に戻すと正しく表示されません。
もう一つは、エンコーディング間の互換性です。 gbkには存在するが、utf8には存在しない文字がある場合、gbk-》utf8-》gbkの過程で「？」になります。
具体的な解決策については、もう一度お話します。
まず、アップグレードしたデータベースとテーブルとフィールドの文字セットを指定する必要があります。複数のエンコーディングを同時に使用しない場合は、通常、gb2312 または utf8 を使用します。データベースを構築するときに SQL ステートメントに追加することもでき、対応する文字セットは phpMyAdmin で変更することもできます。
次に、古いデータをインポートします。まず、データ ファイルのエンコーディングを決定します。 phpMyAdmin を使用してインポートする場合、インターフェイスにファイル エンコード オプションがあり、データ ファイルのエンコードと一致している必要があります。
mysql コマンドラインからインポートする場合は、上記の 3 つの変数を自分で設定し、名前を xxx に設定する必要があります。
他のクライアント プログラムを使用する場合は注意してください。
このようにして、新しいデータベースに転送された後の古いデータのエンコードは正しくなります。この手順を間違えると、後で正しい表示を得ることができなくなります。
その後、独自のプログラムになり、Web ページのエンコーディングに応じて set names xxx を 1 回実行できます。
------------------------------------------------------
mysql import コードの文字化けの問題 - -
mysql が mysqldump を使用して 4.1 からデータをエクスポートし、それを 4.0 にインポートすると、SQL ステートメント エラーが発生し、すべてのデータが文字化けします。これを解決するには、次のパラメータを使用します
mysqldump -uxunai -p --compatibility=mysql40 --default-character-set=latin1 xunai>xunai.sql
mysql -uroot -p fmx

上記は、mysql 中国語文字化けの解決策集です。その他の関連コンテンツについては、PHP 中国語 Web サイト (www.php.cn) をご覧ください。