プロジェクトのニーズにより、ローカル サーバーはデータを受信してから別のサーバーにデータを転送する必要があるため、データの送信にはシミュレートされたポスト リクエストが使用されます。もちろん、データにはファイル ストリームも含まれます。
curl は PHP で最も一般的に使用されるメソッドの 1 つであり、一般的なコードは次のとおりです。
リーリー 相手はJavaサーバーですが、インターフェースだけは分かりますが、相手がどのようにファイルを受信するのかが分かりません。 win7のwamp環境では上記の方法は成功しましたが、centOS+Nginxサーバーにコードを置くとファイルの受信に失敗したというメッセージが返されて失敗してしまいます。パケット キャプチャ分析の結果、win7 wamp によって配信されたパケットの形式と centos nginx によって配信された http パケットの形式が異なることが判明しました。通常の状況では、curl はデフォルトで content_type を multipart/form-data に設定します。私のマシンでは、これは win7 wamp では当てはまりますが、centos nginx では application/x-www-form-urlencoded です。もちろん、これはサーバー構成の問題である可能性もありますが、どこに問題があるのかわかりません。そこでPHPのバージョンを確認してみたところ、やはりPHP5.3.Xでしたが若干の違いがありました。 PHP のバージョンに問題がある可能性は否定できません。コードを次の後に追加します:
リーリー ヘッダーを設定しますが、centos ではまだ無効です。コンテンツ タイプを変更することはできません。これはまさに詐欺です。
その後、テクニカル ディレクターの協力を得て、PHP の公式 Web サイト http://php.net/manual/en/class.curlfile.php のリンクを読み、公式 Web サイトの手順に従って、次の条件でポスト リクエストを正常に実行しました。 wampとcentos nginxに勝ちます。コードをよく読んでみると、curl 自体が生成する部分を使用するのではなく、http リクエストのボディ部分を完全に記述する方法があることがわかり、感心しました。コードは以下で公開されています:
リーリー ファイルの場合、絶対パスの前にパラメータを渡しても効果はありません。唯一の違いは、ファイル データと通常のデータを分離するために異なる配列を使用し、http の本体部分をシミュレートするときにそれらを異なる方法で処理することです。最終的にファイルは正常にアップロードされました。