古い Web サイトを書き直そうとしています。
ペルシア語で書かれており、ペルシア語/アラビア文字が使用されています。
リーリーほぼすべてのテーブル/列の COLLATE が utf8_persian_ci
新しいスクリプトに codeigniter を使用しています。
リーリーはデータベース設定にあるので問題ありません。
これが奇妙な部分です
古いスクリプトは、TUBADBENGINE
または TUBA DB ENGINE
と呼ばれる何らかのデータベース エンジンを使用していました...特別なことは何もありません。
古いスクリプトを使用してデータベースにデータ (ペルシャ語) を入力したとき、データベースを見ると、文字は Ø1مران
として保存されていました。
古いスクリプトはデータを正常に取得/表示しますが、新しいスクリプトはデータベースと同じ奇妙なフォント/文字セットを使用してデータを表示します
つまり、???
と入力すると、データベースに保存されているデータは Ø1Ù...راÙ
のようになり、新しいスクリプトでそれを取得すると、 Ø1Ù...راÙ
を参照してください。ただし、古いスクリプトでは ??
一方、???
をデータベースに直接入力すると
もちろん、同じものをデータベースに保存しました ???
新しいスクリプトは非常にうまく表示されます
しかし、古いスクリプトでは、??????
これを理解できる人はいますか?
これは大型エンジンです
https://github.com/maxxir/mz-codeigniter-crud/blob/master/tuba.php
古いスクリプトの使用例:
リーリーP粉2573421662023-11-18 09:06:47
deceze の答え は非常に優れていますが、手動でテストせずに大量のレコードを処理するのに役立つ可能性のある情報をいくつか追加できます。
変換CONVERT(BINARY CONVERT(field_name USING latin1) USING utf8) が失敗した場合、
field_name の内容の代わりに
NULL が出力されます。
リーリー
またはこれ:リーリー この句を含む
UPDATE は、正常に変換されたレコードにのみ影響します:
リーリー
P粉6638838622023-11-18 00:37:25
つまり、この質問はこれまでに何千回も議論されてきたからです:
"汉字"
などの文字列を UTF-8 でエンコードして保存します。バイトは E6 BC A2 E5 AD 97
です。 latin1
に設定された データベース接続を介して送信されます。 E6 BC A2 E5 AD 97
を受信し、それらが latin1
文字を表していると考えました。 æ¡ ¡ ¿李>
- 同じプロセスを逆に実行すると、PHP は同じバイトを受信し、それらを UTF-8 として扱います。ラウンドトリップは PHP では問題なく機能しますが、データベースは文字を適切に処理しません。
つまり、ここでの問題は、データをデータベースに入力するときにデータベース接続が正しく設定されていないことです。データベース内のデータを正しい文字に変換する必要があります。これを試して:### リーリー
おそらくutf8 は必要なものではないので、試してみてください。機能する場合は、これを
UPDATE ステートメントに変更して、データを永続的に更新します。