以下では、この質問に最も完全に答えようとし、問題を独自に解決するPHPコードを提供します。
第一に、windows-1251エンコーディングでの作業を継続することは誰にもお勧めしません。 このシングルバイトのエンコーディングは、現代の要件を満たしていません。 すべてのプロジェクトをutf-8にすばやく転送します。 これが早ければ早いほど、krakozyabryの問題はより早く消えます。
今latin1について。 このエンコード（windows-1252とも呼ばれます）は、MySQLの以前のバージョン4までで広く使用されていました。キリル文字の記号表は、アラビア文字の代わりにその中にあります。 しかし、これもシングルバイトであるため、このテーブルからこのエンコーディングでデータを読み取り、windows-1251として表示する場合、コードは同じ（0xA0-0xFF）であるため問題ありません。 しかし、これはすべて、MySQL 5+をインストールするまで機能しません。これは、utf-8でデフォルトで機能します。
そのようなデータを渡すことでMySQL 5+は何をしますか？ クライアント側に転送する前に、彼はutf-8のすべてのデータを正直にトランスコードし、アラビア文字（およびキリル文字は実際にはアラビア文字です）をutf-8コードの範囲内に配置します。 その結果、iconv関数（ 'utf-8'、 'windows-1251'、$ str）を使用して、結果のutf-8文字列をトランスコードしてキリル文字に戻そうとしても、成功しません。 iconvはエラーを返すか、空の文字列を返します。
プログラマーが最初に行うことは、phpMyAdminでlatin1テーブルのエンコードをwindows-1251に変更しようとすることです。 しかし、MySQLはこれを行うことができません（彼が書いている）。これは、エンコーディングWindows-1251には対応するアラビア文字がないためです。 2番目に思い浮かぶのは、このテーブルをutf-8に変換することです。 そして判明した。 今だけで、テキストはクラコジヤブラミによってまだ表示されます。
どうする？ この問題を解決するには？
ここでの解決策は非常に簡単ですが、自分で解決するためには、エンコーディングとは何か、どのように機能するかを明確に理解する必要があります。 理解は私の手作りのチャートに役立ちます。
そして、ここにエンコードを整理するために使用するアルゴリズムがあります。
- すべてのデータベーステーブルをutf-8エンコードに変換します。 同時に、エンコーディングlatin1に格納されているため、実際にはアラビア語であるキリル文字がutf-8に変換され、アラビア文字を対象としたutf-8コードの範囲内の正当な場所を占めます。
- 私は各文字列で次のことを行うマイクロユーティリティをPHPで書いています：
- a）文字列をwindows-1252エンコーディングに変換します。 問題はないはずです。 したがって、アラビア文字はコードA0〜FFの範囲を占めます。
- b）受信したシングルバイト文字列をutf-8に変換しますが、windows-1252としてではなく、windows-1251として、つまり A0〜FFの範囲の文字をキリル文字として指定します。 結果として、文字はキリル文字を対象とするコードの範囲でutf-8に分類されます。
- これで、UTF-8のラインは正式にキリル文字になりました。 データベース内の同じセルに書き戻すか、すぐに出力ストリームに戻すことができます。 ただし、データベースの1回限りの完全な変換を実行することをお勧めします。悪夢としてのlatin1については忘れてください。
以下は、ユーザーの名前を通常のキリル文字エンコードに変換するPHPのサンプルコードです。
$q = 'select id, fio from `users`';
$res = mysql_query($q);
while (($row = mysql_fetch_assoc($res)) !== false) {
// fio utf-8/latin1 windows-1252
$s = iconv('utf-8', 'windows-1252', $row['fio']);
// utf-8, windows-1251
$s = iconv('windows-1251', 'utf-8', $s);
//
$q = 'update `users` set fio = "'.addslashes($s).'" where id = '.$row['id'];
mysql_query($q);
}