昨日、ついにクライアントのWebサイトをバーチャルホストに移行し、期待を込めてURLを入力しました。一瞬でウェブサイトが簡単に開きました。 とても嬉しいです~~~ ねえ、なぜ商品の写真が表示されないのですか?すべてのブロックは空白です。 img src に対応するアドレスを入力して、何が起こっているか確認してください。結果は次の効果を示しています:
IE では次のようになります:
まさか、長いデバッグプロセスを開始してください。解決策の手順は次のとおりです。
1. 関数コードのエラーかどうか: キーワード image に従ってください。 。 。 何か不具合があって表示できないので、早速ググって解決策をいくつか調べてみました。
リーリーob_clean()
を対応するコードの場所に追加します。実行結果に変化はありません。
PS: このエラーを特定するために、特定のコードを特定する前に、echo を使用してデバッグをステップバイステップで長時間出力しました。
2. 考える: ローカルでは問題ないのに、アップロードすると間違っているのはなぜですか?環境構成の問題でしょうか?
ローカル環境 XAMP、サーバー環境: Windows + IIS7.5。
サーバーから返された結果の類似点と相違点を比較するために、Fiddler2 を使用して、同じファイルへのローカル アクセスと同じファイルへのサーバー アクセスの類似点と相違点を追跡することにしました。
Fiddler2 を開いて、結果をすぐに見つけます。
テストアドレス:
リーリーサーバーは結果を返します:
ローカルリターン結果:
類似点と相違点は次のとおりです: サーバー ファイルにはもう 1 つのヘッダーがあります
これは何ですか?検索を続けると、結果は UTF8 の BOM ヘッダーです。つまり、IIS から返されるファイルには追加の BOM ヘッダーが存在します。
UTF8 に関する一般的な知識については、http://blog.csdn.net/hiruyue/article/details/8747221 を参照してください。
3. チェックを開始します。BOM ヘッダーを含む UTF8 に変換されたファイルがあるため、BOM ヘッダーを検出するコードの PHP バージョンを見つけ、それを PHP ファイルとして保存し、サーバーに送信します。結果は、システム構成ファイルが BOM ヘッダーを持つファイルに変更されたことがすぐにわかりました。この時、FTPでWebサイトをアップロードした後、FTP付属の編集ツールを使って設定ファイルを修正していたことを思い出しました。当時はNOTEPADで改造してました。以上です。構成ファイルをもう一度ダウンロードし、NOTEPAD++ を使用してファイルの種類を BOM なしの UTF8 に変更し、保存し、アップロードしてアクセスします。ようやくウェブサイトも通常通りに戻りました。
時間を見てみると、5時間が経過しています。
追記: 2 番目のステップでは、IIS が画像バイナリ ストリームを送信する前に ICO ファイル ストリームを送信し、これによってエラーが発生したこともわかりました。
結論:
修正が完了した後、オレイン兄弟の記事を発見しました。彼も私と同じような悩みを抱えていました。
PHP はストリーミング方式を使用してファイルをダウンロードし、UTF-8 BOM の問題が発生します
概要:1. 問題に遭遇したら、まず原因を考えて解決します。そうしないと、コードのデバッグに行き詰まりやすくなります。
2. さらに検索します