OK、私のコマース プラットフォームでは、ショッピング カートのデータはシリアル化された配列としてセッションに保存されます。今日、アイテムのサイズ オプションの 1 つに 1/4 および 1/2 サイズの特殊文字が含まれているという問題が発生しました。7¼、7½ など。ただし、お客様がこの商品を注文した場合、サイズの値は次のように表示されます: 7½½
101 のトラブルシューティングを行い、サイトにアクセスして、顧客が行ったのとまったく同じ注文をしました...奇妙なことに、すべてが期待どおりに機能し、問題は再現しませんでした。その後、注文が「電話注文」を介して行われたことに気付きました。これは、店舗のスタッフが新しい注文をまとめて、すべてを 1 つの画面で請求/確定できるようにするバックエンド スクリプトです。システムは jquery と ajax を使用してこれを行い、複数の「チェックアウト ページ」を用意することなく、すべてを画面上に表示します。
とにかく、電話注文スクリプトで同じ注文をすると、問題は問題なく再現されました。さらに詳しく調べてみると、顧客が注文する「サイト」側で、カートのデータが PHP 関数を使用してシリアル化され、次に base64_encode されて、注文とともにデータベースに「圧縮」されて保存されていることに気付きました。
電話注文側では、シリアル化は php.js シリアル化関数を介して行われます。これは、php シリアル化関数を同じようにエミュレートすると想定されています。シリアル化されたデータは、顧客情報などとともにハンドラーに POSTED されます。サイト側と同様に、CC が請求され、注文がデータベースに保存されます。
さらに調べてみると、両側の 2 つの「シリアル化された」文字列をまったく同じ順序で比較したところ、違いがあります。PHP側では、値7½は「s:2:7½」と表示され、Javascriptバージョンは「s:3:7½」と表示されます...
このプロセスに関連するすべてのページで、サイトの文字エンコーディングが西洋 (iso-8859-1) であることを確認しました。
私は問題を回避することができました...「悪い」シリアル化されたオブジェクトがphpに渡されて注文が保存されたら、それをシリアル化解除し、結果の配列/オブジェクトをコンバーター関数を実行する再帰関数に渡します( char2html) すべての値で、特殊文字をエンティティ名コードに変換します。基本的に ½ は ½ になります。Â は Â になります。次に、str_replace を使用して「Â」を削除します。&entityNames; を変換する別の関数 (html2char) を実行します。実際のキャラクターに戻ります。
その関数の実行が終了すると、オブジェクト/配列が php の serialize 関数を使用して再シリアル化され、すべてが完全に機能し、電話注文スクリプトで行われた注文に Acric 文字が表示されなくなります。
具体的には、渡す前に、javascript の 1/2 文字の UTF8 バージョンを (javascript が見ている 2 バイトの UTF8 バージョンではなく) 1 バイト バージョンに強制的に変換できる方法があるかどうかを調べています。 serialize 関数が UTF8 文字を含まない正しい文字列を返すことを期待して、serialize 関数に渡します。
それはまた、 php.jsのシリアル化関数でいくつかのUTF8nessが進行していると言われていますが、これを行うシリアル化関数の内部に何かがあるかどうかを判断するには、JSコーディングが十分に進んでいません...またはそれを変更する方法がある。
関数リファレンス: http://phpjs.org/functions/serialize:508
考え？