application/x-www-form-urlencodedHTTP では、データを POST する方法がとの 2 つありますmultipart/form-data。ほとんどのブラウザでは、 を使用した場合にのみファイルをアップロードできると理解していますmultipart/form-data。API コンテキスト (ブラウザが関与しない) でエンコード タイプのいずれかを使用するタイミングについて、追加のガイダンスはありますか? たとえば、次の内容に基づいている可能性があります。
- データサイズ
- 非ASCII文字の存在
- （エンコードされていない）バイナリデータ上に存在する
- 追加データ（ファイル名など）を転送する必要がある
これまでのところ、さまざまなコンテンツ タイプの使用に関する正式なガイダンスは Web 上でほとんど見つかりませんでした。
ベストアンサー1
要約
要約: バイナリ (英数字以外) データ (またはかなり大きなサイズのペイロード) を送信する場合は、 を使用しますmultipart/form-data。それ以外の場合は、 を使用しますapplication/x-www-form-urlencoded。
あなたが言及した MIME タイプはContent-Type、ユーザー エージェント (ブラウザー) がサポートする必要がある HTTP POST 要求の 2 つのヘッダーです。これらの 2 つの要求タイプの目的は、名前と値のペアのリストをサーバーに送信することです。送信されるデータのタイプと量に応じて、いずれかの方法が他の方法よりも効率的になります。その理由を理解するには、それぞれの方法が内部で何をしているかを調べる必要があります。
の場合application/x-www-form-urlencoded、サーバーに送信される HTTP メッセージの本文は、基本的に 1 つの巨大なクエリ文字列です。名前と値のペアはアンパサンド ( &) で区切られ、名前と値は等号 ( =) で区切られます。次に例を示します。
MyVariableOne=ValueOne&MyVariableTwo=ValueTwo
による仕様:
[予約文字および]英数字以外の文字は、パーセント記号と文字のASCIIコードを表す2つの16進数字である「%HH」に置き換えられます。
つまり、値の 1 つに存在する英数字以外のバイトごとに、それを表すのに 3 バイトかかります。大きなバイナリ ファイルの場合、ペイロードを 3 倍にするのは非常に非効率的です。
ここでmultipart/form-dataの出番です。名前/値のペアを転送するこの方法では、各ペアは MIME メッセージの「パーツ」として表されます (他の回答で説明されているように)。パーツは特定の文字列境界によって区切られます (この境界文字列が「値」ペイロードのいずれにも出現しないように特別に選択されます)。各パーツには、、、Content-Type特に などの独自の MIME ヘッダー セットがありContent-Disposition、これにより各パーツに「名前」を付けることができます。各名前/値ペアの値部分は、MIME メッセージの各パーツのペイロードです。MIME 仕様では、値ペイロードを表す際により多くのオプションが提供されています。帯域幅を節約するために、バイナリ データのより効率的なエンコード (たとえば、base 64 または raw バイナリ) を選択できます。
multipart/form-data常に使用しないのはなぜでしょうか? 短い英数字の値 (ほとんどの Web フォームなど) の場合、すべての MIME ヘッダーを追加するオーバーヘッドは、より効率的なバイナリ エンコーディングによる節約を大幅に上回ります。