エンコードの問題を診断して確認する方法
私たちがプロジェクトに持っているものは以下のとおりです。
- 複数のサイト（本番、テスト、現地開発）
- 複数の方法（PHPMyAdmin、Navicat、BackupBuddy）で移行しました。
そして私たちが抱えている問題は、オリジナルの本番サイトは問題なく動作しているようですが、残りのインストールは常にテキストエンコーディングの問題に悩まされているということです。
元のサイトはlatin MySQLテーブルで構成されていますが、WPはUTF-8として構成され、ページを提供しています。（私たちのチャットでは）これはすでに問題があります。他のサイト（そのデータベースは主に元の本番サイトを反映している）では、次のような問題が発生します。
- 壊れた文字（WPエンコード設定を調整することで修正可能）
- 壊れた文字（WPエンコード設定を調整しても修正できません）。
- サイトは問題なく動作していますが、壊れた文字を外部ライブラリに送ります。
私はしばらくこれを解くことを試みたがWPのエンコーディング問題を診断することに関する多くの情報がないので、私の質問は以下の通りです：
たとえそれが通常の状況の下でそれらを表示しないかもしれないとしても、サイトがエンコーディング設定問題を持っているかどうかを確実に診断する方法？
移行時のエンコーディングの問題を防ぐために、どの規則を策定し、文書化し、実施する必要がありますか。
それで、およそ1年後（オンとオフ！）、うまくいけばエンコードの問題を修正できました。
なぜ壊れるのか
私の経験によれば、このようなエンコーディングの問題は主に データを移動するときの通信不良 によって引き起こされるということです。
- 最善の場合、正しいデータが誤って解釈された場合、これは読み取りの不一致です。
- 最悪の場合、writeの不一致です。データが誤って保存された場合、問題の滝やさまざまな程度の破損が発生します。
先制措置
データベースを作成するときは、WPでデータベースのエンコーディングを分割するのが一番早いです。そのため、インストールするWPアーカイブをダウンロードする前でさえもです。
デフォルトに頼らず、コンポーネントが同じエンコーディング（UTF8のように）で対話することを確認しないでください 内部的に、そして互いと訪問者と同様に 。これはWPをはるかに超えていて、おそらくApacheのためのいくつかのキックとトップのPHPを伴うMySQL設定を含みます。
WordPressデータベースの文字セットと照合順序の設定 を参照してください。
固定
物事が完全に壊れたとき、あなたは何が悪いのか、そしてどうやってそれを正常に戻すのかを考え出すためのたくさんの苦痛を覚悟しています。
mb_detect_encoding() は非常に便利です。それは魔法の杖ではありませんが、（厳密なモードでは）それからの誤った復帰は、物事が そうではない 正常であることを示す良いシグナルです。
WP固有の面では、$wpdbはエンコーディング関連のプロパティを持っています。
何が悪いのかについての理由/推測/考えがある場合 - データを安全な場所にドラッグして、意味のある正規化されるようにデータを変換することを試みてください：
この問題について少し調べた後、データは実際にはUTF-8でエンコードされているがラテンのように扱われていることが私の理解です。あなたはちょっとしたジャグリングでそれを正しく読むようにそれをだます必要があります。
これを試して：
- 現在の状態でデータベースをエクスポートし、バックアップ用にダンプファイルをコピーします。
- Utf-8を使用して新しいデータベースを作成します。
- SQLダンプファイルの文字セットをutf-8に変更します。
- データを新しいデータベースにインポートします。
これにより、mysqlはデータを正しく読み取ることができなくなります。エクスポート時にエンコーディングを変更しようとすると、データはすでにUTF-8でエンコードされているため、二重にエンコードされた文字が表示されます。