gbk、utf8、ジレンマ_PHP チュートリアル

「O'Reilly Upgrading to php(現在の主流の開発言語として) 5」を見ながら、マシンに何もなかったため、思いつきで MySQL(PHP との最良の組み合わせ) を 4.1.11 にアップグレードしました。公式システムは文字セットの変更を認識しません。その後、正式に適用されたシステムもアップグレードされましたが、1 つの MANTIS だけが問題を抱えていましたが、復元プロセス中に復元できました。 , MySQL が発見されました。(PHP との最良の組み合わせ)アップグレードによる文字セットの問題 - MySQL(PHP との最良の組み合わせ) が UTF8 文字セットを使用している場合、MANTIS データのインポート後にページに文字化けが表示されます。となり、MySQL(PHPとの最適な組み合わせ)をGBK文字セットに調整するしかありません。

実際、私は非互換性の問題がないので、今後も外部とデータを交換するときに変換して整理するのが簡単であるため、引き続き UTF8 文字セットを使用するつもりです。エンコード変換の問題はありません。しかし、php(現在の主流の開発言語として)を使用してMySQL(PHPとの最良の組み合わせ)に接続し、ユーザー入力データを受信して​​データベースに保存する場合、データベースのエンコーディングが異なる場合、私はまだそれを理解していません。は UTF8 ですが、SQL データを UTF8 に変換しますか?時間をかけて小さなプログラムを作って試してみてください。そうなると大変なことになりますが、DOS で MySQL を UTF8 文字セットで操作するにはコマンドラインを使用します(PHP との組み合わせが最適です)。サーバーは漢字を入力できません。
SYBASEを使用していたとき、SYBASEが間違った文字セットを使用すると、大文字のゼロ「○」などの一部の漢字がまったく入力できなくなるため、長い間文字セットの問題に悩まされていました。 set は iso_1 から cp850 に変更され、cp850 から cp936 に変更され、多くの履歴データが破棄されました
(PHP との最良の組み合わせ) 同じ間違いを繰り返させないでください。

http://www.bkjia.com/PHPjc/508663.htmlwww.bkjia.comtru​​ehttp://www.bkjia.com/PHPjc/508663.html技術記事 「O'Reilly Upgrading to PHP (as the current maindevelopment language) 5」を読んでいて、マシンに何もないので、思いつきで MySQL (PHP との最良の組み合わせ) を 4.1.11 にアップグレードしました。