このようなparamNameに= paramvalue形態のような、デフォルトのキーと値のペアに応じて解決するためのアプリケーション/ x-www-form-urlencodedで場合：実際には、溶液が簡単で、エンティティ、コンテンツ・タイプから時間POST要求パラメータでありますしかし、そこに、隠された要件はfrombodyパラメータだけ多くのパラメータがfrombodyするように変更されている場合には、ときに、コンパイラは文句を言うだろう、いずれかである限りfrombody変更されたパラメータ、重要な名前がない、ということを意味その後、HTTPパラメータの名前から直接要求は無視される身体の部分は、それが直接、文字列型として読み取ることができ、よりパラメータ=コンテンツを書き始めました。あなたが理解していない場合は、次のスクリーンショットのデモを見てみましょう。
図は、シミュレートされたHTTP要求、図中のサーバー側のコードである。図は、直ちにデータベースに挿入された値の完了後に行われます、
どこ3の懸念があり、
図1に示すように、サーバ側のコードが必要に2つのパラメータを渡すことがわかる、パラメータが文字列型であり、差は、URLから抽出された別のボディから抽出され、それはバック、URLパラメータに書き込まれていません＆他のパラメータに追いつくために追加し、
図2は、データの内容が実際にコンテンツを埋める体、フォームのデフォルトのエンコーディングがUTF-8であり、本体は、コンテンツをアップロードし、URLが同じキーと値のペアであることができない、key = valueの形式は、逆に、支持しません= =開始番号、サーバ上のメッセージがヌルヌルであるわけではない場合に、刺すようなパラメータのタイプのすべてが、後に送信さfrombodyから開始
図3に示すように、データの内容、すなわち、コンテンツ長パラメータ体、もしPOST、および非ヌルの本体は、Content-Lengthヘッダであり、そして、もし必要があり、HTTP1.1上で、必要があります漢字が存在し、その後、UTF-8符号化モード再、長さは、人が確認のため、もう一度手書き信じることができない場合は、バイト配列の長さ、すなわちコーディングする前に、文字の長さではなく、長さを使用してエンコードする必要があります。
もちろん、オンラインfrombody引数の場合はnullで、多くの人が受信するオブジェクトへのパラメータ、または文字列型を処理するために読書クラスを行うために自分自身を提案し、その後、JSONを受け取るために、このような形に巻き込まれているがありますしかし、コンテンツタイプ等、テキスト/ JSONを変更されなければならない、私はそれがこれよりももっと複雑な方法、絶対にない簡単で便利なの、この方法としては良いことだと思います。