When we send data using a POST request, the data is placed in the body instead of the header, and when we send data in the body, we can think of the body as a long single string, and we use different encodings to send the data in different forms.

application/x-www-form-urlencoded

The data in the form is converted to key-value pairs, & separated. When the action of a form is GET, the browser codes the form data as (name1= Value1&name2 =value2…) using x-www-form-urlencoded codes. And append the string to the URL with? To jump to the new URL. When the form action is POST, the browser wraps the form data in an HTTP body and sends it to the server. Files cannot be submitted in this format. It is the default format for POST. By default, it uses some special characters as delimiters, such as & (ASCII code 0x26), =(0x3D), (space), etc. We send name and value information in input with = connection, and use & connection between different input. Decoding is performed in the same way at the receiving end. Once characters such as &,= are encountered, the long byte will be broken and restored to the original data in the form of key:value for our use. So when decoding in this format, it can be scanned byte by byte, with special bytes to distinguish the different parts.

The problem

If you want to send a multi-byte character, for example, a Chinese character, the utF-8 encoding is 0xE4B8AD, and the utF-8 encoding is 0xE4, 0xB8, 0xAD. When some Chinese or multi-byte characters are sent and one byte is decoded to 0x26 or 0x3D, one byte of the multi-byte characters will be decoded to the special byte of = or ampersand in the receiving segment, thus disconnecting the data from this point and causing a data error.

In order to solve this problem, using the JS URLencode transcoding method, namely URL encoding, we often see a URL similar to https://cn.bing.com/search?q=ascii%E7%A0%81%E8%A1%A8, %E7%A0%81%E8%A1%A8 is produced in this way. We send the above medium, utF-8 encoded as 0xE4B8AD (this is a 3 byte hexadecimal notation that represents a character of one of the characters) and cannot send directly. You need to transcode using URLencode, based on the hexadecimal string of this encoding, add a % before every two characters to get the string %E4%B8%AD (this is a string, each character is a byte, there are 9 bytes in total), and then send the byte. That solves the above problem.

Data sent in this way will be encoded into 9 bytes for sending, which will seriously waste network bandwidth resources when sending a large number of Chinese and multi-character data. Generally, it is used when sending a small amount of data. For example, the following is part of the message sent by the browser when {country: China, city: Beijing} is sent in a form

POST/Users/HTTP/1.1 Host: localhost:8000 Content-Type: Application/X-www-form-urlencoded // Header specifies format country=%E4%B8%AD%E5%9B%BD&city=%E5%8C%97%E4%BA%AC // Encoded dataCopy the code

form-data

Application/X-www-form-urlencoded must be coded for multi-byte characters because the single byte information of multi-byte characters may conflict with special byte information. Instead of using these one-byte special characters as special splits, form-data tells the other party to use the split string. When the {country: China, city: Beijing} form information is sent in this format, the browser sends data as.

POST /users/ HTTP/1.1 Host: localhost:8000 Content-type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW ------WebKitFormBoundary7MA4YWxkTrZu0gW--, Content-Disposition: form-data; Name = "country" -- -- -- -- -- - WebKitFormBoundary7MA4YWxkTrZu0gW, China - the Content - Disposition: the form - data; Name = "city" -- -- -- -- -- - WebKitFormBoundary7MA4YWxkTrZu0gW - BeijingCopy the code

In the header, content-type: multipart/form-data; A boundary = – WebKitFormBoundary7MA4YWxkTrZu0gW specifies the format and boundary segment (string), using the specified boundary strings in the body as a break up, This can be easily restored to the key:value form. In both China and Beijing, each character l, such as Chinese, is transmitted directly using utF-8 encoding (which is used in most network transmissions), meaning that each Chinese character takes only three bytes.

Raw (Postman)

You can upload text in any format, including Text, JSON, XML, and HTML

Binary (postman)

Content-type :application/octet-stream: only binary data can be uploaded. It is usually used to upload files. There are no keys, so only one file can be uploaded at a time.

conclusion

Application/X-www-form-urlencoded he can divide key: value data concisely. This is a huge advantage over form-data’s use of long strings as separators. Although the number of bytes can be dramatically increased by encoding for multi-byte data (you can see that a Chinese character is twice as large), it is cost-effective for single-byte or small amounts of data.

Form-data is a way to attach importance to data. Usually, we will send a large amount of text information in the value value, or directly send a file. The data is directly encoded in binary and sent without generating extra bytes, which is suitable for large text transmission.