multipart / form-dataの境界は何ですか？

について質問したいmultipart/form-data。HTTPヘッダーで、Content-Type: multipart/form-data; boundary=???。

ある???ユーザによって定義されて自由には？それともHTMLから生成されますか？私が定義することは可能??? = abcdefgですか？

ある???ユーザによって定義されて自由には？

はい。

それともHTMLによって提供されますか？

いいえ。HTMLはそれとは関係ありません。以下をお読みください。

???として定義することは可能abcdefgですか？

はい。

次のデータをWebサーバーに送信する場合：

name = John
age = 12

使用application/x-www-form-urlencodedは次のようになります：

name=John&age=12

ご覧のとおり、サーバーはパラメータがアンパサンドで区切られていることを認識しています&。&パラメータ値に必要な場合は、エンコードする必要があります。

では、サーバーはどのようにして、パラメーター値がどこで開始および終了するのmultipart/form-dataかを使用して、HTTP要求を受信したときにそれを知っていますか

に似た境界を使用し&ます。

例えば：

--XXX
Content-Disposition: form-data; name="name"

John
--XXX
Content-Disposition: form-data; name="age"

12
--XXX--

その場合、境界値はXXXです。Content-Typeヘッダーで指定して、サーバーが受信したデータを分割する方法を認識できるようにします。

だからあなたはする必要があります：

• サーバーに送信されるHTTPデータに表示されない値を使用してください。

• 一貫性を保ち、リクエストメッセージのどこでも同じ値を使用します。

質問に対する正確な答えは次のとおりです。はい、boundary長さが70バイトを超えず、7ビットUS-ASCII（印刷可能）文字のみで構成されていれば、パラメーターに任意の値を使用できます。

multipart/*コンテンツタイプのいずれかを使用している場合、実際にはヘッダーでパラメーターを指定する必要があります。そうでない場合、サーバー（HTTPリクエストの場合）はペイロードを解析できません。boundaryContent-Type

おそらく、また、設定したいcharsetにパラメータをUTF-8あなたにContent-Typeあなたがすることができない限り、ヘッダー絶対に確認するだけでUS-ASCII文字セットがペイロード・データに使用されます。

RFC2046からのいくつかの関連する抜粋：

• 4.1.2。文字セットパラメータ：

  他の一部のパラメーター値とは異なり、charsetパラメーターの値では大文字と小文字が区別されません。charsetパラメータがない場合に想定する必要があるデフォルトの文字セットはUS-ASCIIです。

• 5.1。マルチパートメディアタイプ

  Content-Transfer-Encodingフィールドの定義[RFC 2045]で述べられているように、タイプ「multipart」のエンティティには、「7bit」、「8bit」、または「binary」以外のエンコードは許可されていません。「マルチパート」境界区切り文字とヘッダーフィールドは常に7ビットUS-ASCIIとして表されます（ただし、ヘッダーフィールドはRFC 2047に従って非US-ASCIIヘッダーテキストをエンコードする場合があります）。ボディパーツ内のデータは、パーツごとに、適切な各ボディパーツのContent-Transfer-Encodingフィールドを使用します。

  マルチパートエンティティのContent-Typeフィールドには、「boundary」という1つのパラメーターが必要です。次に、境界区切り行は、2つのハイフン文字（ "-"、10進数値45）と、それに続くContent-Typeヘッダーフィールドの境界パラメーター値、オプションの線形空白、および終了CRLFで構成される行として定義されます。

  境界区切り文字は、カプセル化されたマテリアル内に表示することはできません。また、先頭の2つのハイフンを含めずに、70文字以下にする必要があります。

  最後のボディパーツに続く境界区切り線は、以降のボディパーツが続かないことを示す区別可能な区切り文字です。このような区切り線は、境界パラメーター値の後に2つのハイフンが追加されている点で、以前の区切り線と同じです。

以下は、任意の境界を使用した例です。

Content-Type: multipart/form-data; charset=utf-8; boundary="another cool boundary"

--another cool boundary
Content-Disposition: form-data; name="foo"

bar
--another cool boundary
Content-Disposition: form-data; name="baz"

quux
--another cool boundary--

multipart / form-dataには、名前と値のペアを区切る境界が含まれています。境界は、フォームが送信されたときに渡される名前と値のペアの各チャンクのマーカーのように機能します。境界は、リクエストヘッダーのコンテンツタイプに自動的に追加されます。

フォームのenctype =「マルチパート/フォームデータ」属性は、要求ヘッダーのContent-Typeを有するであろう：マルチパート/フォームデータを、境界--- WebKit193844043-h（ブラウザが生成した値）。

渡されるペイロードは次のようになります。

Content-Type: multipart/form-data; boundary=---WebKitFormBoundary7MA4YWxkTrZu0gW

    -----WebKitFormBoundary7MA4YWxkTrZu0gW
    Content-Disposition: form-data; name=”file”; filename=”captcha”
    Content-Type:

    -----WebKitFormBoundary7MA4YWxkTrZu0gW
    Content-Disposition: form-data; name=”action”

    submit
    -----WebKitFormBoundary7MA4YWxkTrZu0gW--

Webサービス側では、@ Consumes（ "multipart / form-data"）形式で使用されます。

添付ファイルを送信するには、Chrome Postmanを使用してWebサービスをテストするときに、ドロップダウンボックスからフォームデータオプション（ラジオボタン）と[ファイル]メニューを確認する必要があります。multipart / form-dataとしてコンテンツタイプを明示的に指定すると、エラーがスローされます。境界が適切に機能する境界を追加することにより、content-typeでサーバーへのポストマンのカールリクエストをオーバーライドするため、境界が欠落しているためです。

RFC1341 sec7.2 The Multipart Content-Typeを参照してください