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

First, Content-Type is specified as application/x-www-form-urlencoded; the format requirement here is the format requirement of Query String in the URL: multiple key-value pairs are connected with &, and keys and values ​​are preceded by = Connection, and only ASCII characters can be used. Non-ASCII characters need to be encoded using UrlEncode. Most server-side languages ​​have good support for this method. For example, in PHP, $_POST['title'] can get the value of title, and $_POST['sub'] can get the sub array.

File splitting

The request body of the third request body is divided into multiple parts and will be used when uploading files. This format is the first It should be used in email transmission. Each field/file is divided into separate segments by the boundary (specified in Content-Type). Each segment starts with -- plus boundary, followed by the description header of the segment, and is empty after the description header. The content is connected in one line. The end of the request is marked with -- after boundary. The structure is shown in the figure below:

The key to distinguish whether it is treated as a file is whether the Content-Disposition contains filename, because files have different Type, so Content-Type is also used to indicate the type of the file. If you don’t know what type it is, the value can be application/octet-stream to indicate that the file is a binary file. If it is not a file, Content-Type can be omitted.
When we use a form to upload files, we must make the form's enctyped equal to multipart/form-data. Let’s look directly at a request example:

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. Convert spaces into plus signs (+)

　3. Convert non-text content into the form of "%xy", xy is a two-digit hexadecimal value;

　4. Place an & symbol between each name=value pair.

One of the many problems faced by web designers is how to deal with the differences between different operating systems. These differences cause problems with URLs: for example, some operating systems allow spaces in file names, while others do not. Most operating systems do not think that the symbol "#" in the file name has any special meaning; but in a URL, the symbol "#" indicates that the file name has ended, followed by a fragment (part) identifier. Other special characters, non-alphanumeric character sets, which have special meanings in the URL or on another operating system, pose similar problems. In order to solve these problems, the characters we use in the URL must be elements in a fixed character set of the ASCII character set, as follows:

　1. Uppercase letters A-Z

　2. Lowercase letters a-z

　3. Numbers 0-9

　4. Punctuation characters - _ . ! ~ * ' (and,)

　 Characters such as: / & ? @ # $ + = and % can also be used, but each has its own special purpose. If a file name contains these characters ( / & ? @ # $ + = % ), these characters and all other characters should be encoded.

The encoding process is very simple. Any characters that are not ASCII numbers, letters, or the aforementioned punctuation characters will be converted into byte form. Each byte is written in this form: a "%" Followed by two hexadecimal values. Whitespaces are a special case because they are so common. In addition to being encoded as "%20", it can also be encoded as a "+". The plus sign (+) itself is encoded as %2B. Both / # = & and ? should be encoded when used as part of a name, rather than as a separator between URL parts.

WARNING This strategy is not ideal in heterogeneous environments with a large number of character sets. For example: On U.S. Windows systems, é is encoded as %E9. On U.S. Mac, it is encoded as %8E. The existence of this uncertainty is an obvious shortcoming of existing URIs. Therefore, future URI specifications should be improved through International Resource Identifiers (IRIs).

Class URLs do not automatically perform encoding or decoding. You can generate a URL object, which may contain illegal ASCII and non-ASCII characters and/or %xx. Such characters and escape characters are not automatically encoded or decoded when using the methods getPath() and toExternalForm() as output methods. You are responsible for the string objects used to generate a URL object, ensuring that all characters are encoded appropriately.

Related recommendations:

HTTP request header

The above is the detailed content of Detailed explanation of HTTP request headers and request body. For more information, please follow other related articles on the PHP Chinese website!