POST http://www.example.com HTTP/1.1

Content-Type: application/x-www-form-urlencoded ; charset=utf-8
title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3

まず、Content-Type は application/x-www-form-urlencoded として指定されます。ここでの形式要件は、URL 内のクエリ文字列の要件です。複数のキーと値のペアは & で接続され、キーと値は = で接続され、非 ASCII 文字のみをエンコードする必要があります。 URLエンコードを使用します。ほとんどのサーバーサイド言語は、このメソッドを適切にサポートしています。たとえば、PHP では、$_POST['title'] はタイトルの値を取得でき、$_POST['sub'] はサブ配列を取得できます。

ファイルの分割

3番目のリクエストボディは複数の部分に分割されており、ファイルをアップロードする際に使用されます。この形式は、最初にメール送信で使用されるべきであり、各フィールド/ファイルはすべて分割されています。境界 (Content-Type で指定) によってセグメントを区切ります。各セグメントは -- と境界で始まり、その後、セグメントの説明ヘッダーの後に、空行がコンテンツの終わりを接続します。は境界プラス -- - としてマークされており、その構造は次の図に示されています。

ファイルとしてみなされるかどうかを区別する鍵は、Content-Disposition にファイル名が含まれているかどうかです。ファイルにはさまざまなタイプがあるため、Content-Type にはファイル名が含まれている必要があります。ファイルの種類がわからない場合は、ファイルがバイナリ ファイルであることを示すために、Content-Type を値として使用できます。省略される。
フォームを使用してファイルをアップロードする場合、 フォームの enctyped を multipart/form-data と等しくする必要があります。リクエストの例を直接見てみましょう:

BASHPOST http://www.example.com HTTP/1.1Content-Type:multipart/form-data; 
boundary=----WebKitFormBoundaryrGKCBY7qhFd3TrwA------WebKitFormBoundaryrGKCBY7qhFd3TrwAContent-Disposition: 
form-data; name="text"title------WebKitFormBoundaryrGKCBY7qhFd3TrwAContent-Disposition: form-data; name="file";
 filename="chrome.png"Content-Type: image/pngPNG ... content of chrome.png ...------WebKitFormBoundaryrGKCBY7qhFd3TrwA--

这个例子稍微复杂点。首先生成了一个 boundary 用于分割不同的字段，为了避免与正文内容重复，boundary 很长很复杂。然后 Content-Type 里指明了数据是以 multipart/form-data 来编码，本次请求的 boundary 是什么内容。消息主体里按照字段个数又分为多个结构类似的部分，每部分都是以 --boundary 开始，紧接着是内容描述信息，然后是回车，最后是字段具体内容（文本或二进制）。如果传输的是文件，还要包含文件名和文件类型信息。消息主体最后以 --boundary-- 标示结束。关于 multipart/form-data 的详细定义，请前往 rfc1867 查看。

这种方式一般用来上传文件，各大服务端语言对它也有着良好的支持。

上面提到的这两种 POST 数据的方式，都是浏览器原生支持的，而且现阶段标准中原生 表单也只支持这两种方式（通过 元素的enctype 属性指定，默认为 application/x-www-form-urlencoded。其实 enctype 还支持 text/plain，不过用得非常少）。

随着越来越多的 Web 站点，尤其是 WebApp，全部使用 Ajax 进行数据交互之后，我们完全可以定义新的数据提交方式，给开发带来更多便利。

Encoding:编码

网页中的表单使用POST方法提交时，数据内容的类型是 application/x-www-form-urlencoded，这种类型会：

　　1.字符"a"-"z"，"A"-"Z"，"0"-"9"，"."，"-"，"*"，和"_" 都不会被编码;

2. スペースをプラス記号 (+) に変換します

3. 非テキストコンテンツを「%xy」の形式に変換します。xy は 2 桁の 16 進数値です。

4. 各名前=値のペアに、間にアンパサンドを入れます。

Web デザイナーが直面する多くの問題の 1 つは、異なるオペレーティング システム間の違いにどう対処するかということです。これらの違いにより、URL に関する問題が発生します。たとえば、一部のオペレーティング システムではファイル名にスペースが許可されますが、他のオペレーティング システムでは許可されません。ほとんどのオペレーティング システムでは、ファイル名の記号「#」に特別な意味があるとは考えていませんが、URL では、記号「#」はファイル名の終了を示し、その後にフラグメント (部分) 識別子が続きます。 URL または別のオペレーティング システムで特別な意味を持つ他の特殊文字、非英数字文字セットも同様の問題を引き起こします。これらの問題を解決するには、URL で使用する文字は、次のように ASCII 文字セットの固定文字セットの要素でなければなりません:

1. 大文字 A-Z

2. 小文字 a-z

3. 数字0-9

4. 句読点文字 - _ . ! ~ * ' (and,)

/ & ? @ # $ + = や % などの文字も使用できますが、それぞれに独自の目的があります。ファイルの場合 名前にこれらの文字 ( / & ? @ # $ + = % ) が含まれている場合、これらの文字と他のすべての文字をエンコードする必要があります。

エンコードプロセスは非常に簡単です。ASCII 数字、文字、または前述の句読点文字以外の文字は、「%」の後に 2 桁の 16 進数値が続く形式で書き込まれます。 。空白は非常に一般的であるため、特殊なケースです。 「%20」としてエンコードされるほかに、「+」としてエンコードすることもできます。プラス記号 (+) 自体は %2B としてエンコードされます。 / # = & と ? は、URL 部分間の区切り文字としてではなく、名前の一部として使用する場合は両方ともエンコードする必要があります。

警告 この戦略は、多数の文字セットが存在する異種環境では理想的ではありません。例: 米国の Windows システムでは、é は %E9 としてエンコードされ、米国の Mac では %8E としてエンコードされます。この不確実性の存在は、既存の URI の明らかな欠点です。したがって、将来の URI 仕様は、International Resource Identifier (IRI) を通じて改善される必要があります。

クラスURLは自動的にエンコードやデコードを行いません。不正な ASCII 文字、非 ASCII 文字、%xx を含む可能性のある URL オブジェクトを生成できます。このような文字とエスケープ文字は、メソッド getPath() および toExternalForm() を出力メソッドとして使用する場合、自動的にエンコードまたはデコードされません。 URL オブジェクトの生成に使用される文字列オブジェクトを管理し、すべての文字が適切にエンコードされていることを確認する必要があります。

関連する推奨事項:

HTTP リクエスト ヘッダー

以上がHTTPリクエストヘッダーとリクエストボディの詳細説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。