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

Tout d'abord, Content-Type est spécifié comme application/x-www-form-urlencoded ; l'exigence de format ici est l'exigence de format de la chaîne de requête dans l'URL : plusieurs paires clé-valeur sont connectées avec &, et des clés et des valeurs. ​​sont précédés de = Connection, et seuls les caractères ASCII peuvent être utilisés. Les caractères non-ASCII doivent être codés à l'aide d'UrlEncode. La plupart des langages côté serveur prennent bien en charge cette méthode. Par exemple, en PHP, $_POST['title'] peut obtenir la valeur du titre et $_POST['sub'] peut obtenir le sous-tableau.

Répartition des fichiers

Le corps de la requête du troisième corps de la requête est divisé en plusieurs parties et sera utilisé lors du téléchargement de fichiers. Ce format est le premier. doit être utilisé dans la transmission par courrier électronique. Chaque champ/fichier est divisé en segments distincts par la limite (spécifiée dans Content-Type). Chaque segment commence par -- plus la limite, suivi de l'en-tête de description du segment, et est vide après le. en-tête de description. Le contenu est connecté sur une seule ligne. La fin de la requête est marquée de -- après la limite. La structure est présentée dans la figure ci-dessous :

La clé pour distinguer si elle est considérée. en tant que fichier, il s'agit de savoir si Content-Disposition contient un nom de fichier, car les fichiers ont un type différent, donc Content-Type est également utilisé pour indiquer le type du fichier. Si vous ne savez pas de quel type il s'agit, la valeur peut être application/. flux d'octets pour indiquer que le fichier est un fichier binaire. S'il ne s'agit pas d'un fichier, Content-Type peut être omis.
Lorsque nous utilisons un formulaire pour télécharger des fichiers, nous devons rendre le enctyped du formulaire égal à multipart/form-data. Regardons directement un exemple de requête :

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. Convertissez les espaces en signes plus (+)

3. Convertissez le contenu non textuel sous la forme de "%xy", xy est une valeur hexadécimale à deux chiffres

4. Placez un symbole & entre chaque paire nom=valeur.

L'un des nombreux problèmes rencontrés par les concepteurs de sites Web est de savoir comment gérer les différences entre les différents systèmes d'exploitation. Ces différences entraînent des problèmes avec les URL : par exemple, certains systèmes d'exploitation autorisent les espaces dans les noms de fichiers, tandis que d'autres ne le font pas. La plupart des systèmes d'exploitation ne pensent pas que le symbole « # » dans le nom de fichier a une signification particulière ; mais dans une URL, le symbole « # » indique que le nom de fichier est terminé, suivi d'un identifiant de fragment (partie). D'autres caractères spéciaux, jeux de caractères non alphanumériques, qui ont une signification particulière dans l'URL ou sur un autre système d'exploitation, posent des problèmes similaires. Afin de résoudre ces problèmes, les caractères que nous utilisons dans l'URL doivent être des éléments d'un jeu de caractères fixe du jeu de caractères ASCII, comme suit :

1. Lettres majuscules A-Z

2. Lettres minuscules a-z

3. Chiffres 0-9

4. Caractères de ponctuation - _ ~ * ' (et,)

Caractères tels que : / & @. # $ + = et % peuvent également être utilisés, mais chacun a son propre objectif particulier Si un nom de fichier contient ces caractères ( / & ? @ # $ + = % ), ces caractères et tous les autres caractères doivent être codés.

Le processus d'encodage est très simple. Tous les caractères qui ne sont pas des chiffres ASCII, des lettres ou les caractères de ponctuation susmentionnés seront convertis sous forme d'octets. Chaque octet est écrit sous cette forme : un "%" suivi de deux valeurs hexadécimales. Les espaces sont un cas particulier car ils sont très courants. En plus d'être codé sous la forme "%20", il peut également être codé sous la forme d'un "+". Le signe plus (+) lui-même est codé comme %2B. /# = & et ? doivent être codés lorsqu'ils sont utilisés dans le cadre d'un nom, plutôt que comme séparateur entre les parties de l'URL.

ATTENTION Cette stratégie n'est pas idéale dans des environnements hétérogènes comportant un grand nombre de jeux de caractères. Par exemple : sur les systèmes Windows américains, é est codé sous la forme %E9. Sur les Mac américains, il est codé sous la forme %8E. L’existence de cette incertitude constitue une lacune évidente des URI existants. Par conséquent, les futures spécifications d’URI devraient être améliorées grâce aux identifiants internationaux de ressources (IRI).

Les URL de classe n'effectuent pas automatiquement l'encodage ou le décodage. Vous pouvez générer un objet URL, qui peut contenir des caractères ASCII et non-ASCII illégaux et/ou %xx. Ces caractères et caractères d'échappement ne sont pas automatiquement codés ou décodés lors de l'utilisation des méthodes getPath() et toExternalForm() comme méthodes de sortie. Vous êtes responsable des objets chaîne utilisés pour générer un objet URL, en vous assurant que tous les caractères sont codés de manière appropriée.

Recommandations associées :

En-tête de requête HTTP

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!