Explication détaillée de la différence entre la production de pages GET POST_HTML/Xhtml_Web

1. Get est utilisé pour obtenir des données du serveur, tandis que Post est utilisé pour transférer des données vers le serveur.
2. Get ajoute les données du formulaire à l'URL pointée par l'action sous la forme variable=valeur, et les deux sont connectés à l'aide de "?", et chaque variable est connectée à l'aide de "&" ; se connecter Les données du formulaire sont placées dans le corps de données du formulaire et transmises à l'URL pointée par l'action en fonction des variables et valeurs correspondantes.
3. Get n'est pas sécurisé car pendant le processus de transmission, les données sont placées dans l'URL demandée, et de nombreux serveurs, serveurs proxy ou agents utilisateurs existants enregistreront l'URL demandée dans des fichiers journaux, puis la placeront quelque part, il peut y en avoir. informations privées visibles par un tiers. De plus, les utilisateurs peuvent également voir les données soumises directement sur le navigateur, et certains messages internes du système seront affichés devant l'utilisateur. Toutes les opérations de publication sont invisibles pour les utilisateurs.
4. La quantité de données transférées par Get est faible, principalement parce qu'elle est limitée par la longueur de l'URL ; tandis que Post peut transférer une grande quantité de données, vous ne pouvez donc utiliser Post que lors du téléchargement de fichiers (bien sûr, il en existe un autre). raison, qui sera mentionnée plus tard) ).
5. Get limite la valeur de l'ensemble de données dans le formulaire Form aux caractères ASCII ; tandis que Post prend en charge l'ensemble du jeu de caractères ISO10646. La valeur par défaut est d'utiliser le codage ISO-8859-1
6. Get est la méthode par défaut de Form.
La comparaison suivante est très utile :
Je fais du développement Web Java depuis un moment, et il y a un problème qui me dérange toujours, c'est le caractère tronqué problème de code. En gros, je cherchais des solutions en ligne (il y a vraiment beaucoup d'informations en ligne), et il y avait beaucoup d'introductions sur la façon de résoudre ce genre de problème de code tronqué, mais peu d'entre elles expliquaient les tenants et les aboutissants du problème. problème clairement. Parfois, après avoir lu certains articles, je pensais comprendre, mais pendant le développement, le problème de code tronqué apparaît comme un fantôme et fait peur aux gens. Cet article est l'accumulation d'une certaine compréhension de ma lutte à long terme avec des personnages tronqués. J'espère également que davantage d'amis pourront me donner des conseils et des suppléments.
Le formulaire propose deux méthodes pour soumettre des données au serveur, les obtenir et les publier respectivement.
(1) Obtenir la soumission
1. Tout d'abord, parlons de la façon dont le formulaire client (navigateur) utilise la méthode get pour encoder les données et les soumettre au serveur.

Pour la méthode get, les données sont concaténées derrière l'URL demandée en tant que paramètre, tel que : http://localhost:8080/servlet?msg=abc
(un problème tronqué très courant. sur le point d'apparaître. Si des caractères chinois ou autres caractères spéciaux apparaissent dans l'URL, tels que : http://localhost:8080/servlet?msg=Hangzhou, le côté serveur est facile à obtenir des caractères tronqués). le navigateur traitera l'encodage d'URL, puis l'enverra au serveur. Le processus d'encodage d'URL consiste à utiliser une partie de l'URL sous forme de caractères, à l'encoder en bytecode binaire selon une certaine méthode d'encodage (telle que utf-8, gbk, etc.), puis utilisez un Représenté par la chaîne de 3 caractères "%xy", où xy est la représentation hexadécimale à deux chiffres de l'octet. Ce dont je parle ici n'est peut-être pas clair. Pour une introduction détaillée, vous pouvez lire l'introduction de la classe java.net.URLEncoder ici. Après avoir compris le processus d'encodage d'une URL, nous pouvons voir deux problèmes très importants. Premièrement : les caractères qui nécessitent un encodage d'URL sont généralement des caractères non-ASCII (d'une manière générale), et plus généralement, ce sont des textes autres que les lettres anglaises (comme : chinois, japonais, etc.) doivent être codés en URL, donc pour nous, les URL avec des lettres anglaises n'entraîneront pas l'obtention de caractères tronqués par le serveur. Les caractères tronqués sont causés par des caractères chinois ou spéciaux dans l'URL :Quels. méthode d'encodage l'URL utilise-t-elle pour encoder les caractères ? C'est une question de navigateurs, et différents navigateurs ont des approches différentes. La version chinoise du navigateur utilise généralement GBK par défaut. Vous pouvez également utiliser UTF-8 en définissant le navigateur. Différents utilisateurs peuvent avoir des préférences de navigation différentes. Dans différentes méthodes d'encodage, de nombreux sites Web utilisent JavaScript pour encoder les caractères chinois ou spéciaux dans l'URL, puis fusionner l'URL pour soumettre les données, c'est-à-dire que l'encodage de l'URL est effectué pour le navigateur. L'avantage est que le site Web peut le faire. unifier la méthode de codage des données soumises par la méthode get. Une fois le codage de l'URL terminé, l'URL devient désormais un caractère dans la plage ASCII, puis convertie en binaire à l'aide du codage iso-8859-1 et envoyée avec l'en-tête de la requête. Ce que je veux dire quelques mots de plus ici, c'est que pour la méthode get, il n'y a pas d'entité de requête et que l'URL contenant les données se trouve dans l'en-tête de la requête. La raison pour laquelle le codage d'URL est utilisé Je pense personnellement que c'est : pour l'en-tête de la requête Au final, les données pures de 101010... seront codées en binaire en utilisant la méthode de codage iso-8859-1 et transmises sur Internet si les caractères spéciaux contenant du chinois et d'autres caractères sont directement codés en iso. -8859-1, les informations seront perdues, il est donc nécessaire d'effectuer d'abord l'encodage URL.
2. Comment le côté serveur (Tomcat) obtient-il les données et les décode-t-il.
La première étape consiste à décoder les données à l'aide de l'iso-8859-1. Pour la méthode get, Tomcat obtient les données en utilisant des caractères d'en-tête de requête dans la plage ASCII. L'URL de la requête contient des données de paramètre. S'il y a du chinois dans le paramètre Attendre spécial. caractères, alors il est toujours dans l'état %XY après le codage de l'URL. Arrêtons-nous pour l'instant sur le processus général par lequel les développeurs obtiennent des données. Habituellement, tout le monde utilise request.getParameter("name") pour obtenir les données de paramètres. Les données que nous obtenons dans l'objet de requête ont été décodées et ne peuvent pas être spécifiées dans le programme pendant le processus de décodage. les novices disent que vous pouvez utiliser request.setCharacterEncoding("Character Set") pour spécifier la méthode de décodage. En fait, ce n'est pas possible Voir la description officielle de l'API du servlet pour une explication de cette méthode : remplace le. nom du codage de caractères utilisé dans le corps de cette requête. Cette méthode doit être appelée avant de lire les paramètres de la requête ou de lire les entrées à l'aide de getReader(). On voit qu'il est impuissant avec la méthode get. Alors, quelle méthode de codage est utilisée pour décoder les données ? C'est une question de Tomcat. La valeur par défaut est iso-8859-1, afin que nous puissions découvrir pourquoi la requête get avec les paramètres chinois est tronquée côté client. , UTF-8 ou GBK est généralement utilisé pour encoder l'URL des données. Il n'est évidemment pas possible d'utiliser ici le décodeur d'URL iso-8859-1. Dans le programme, on peut directement
code Java
1. String( request.getParameter("name").getBytes("iso-8859-1"),"Méthode d'encodage d'URL spécifiée par le client")
Restaurez le bytecode, puis décodez les données de la manière correcte , en ligne L'article est généralement configuré dans Tomcat
Code XML
1
Cela permet à Tomcat d'utiliser le décodeur d'URL spécifié après avoir obtenu les données. L'introduction du décodeur d'URL est ici
(1) après la soumission
1. Client (navigateur) Comment. le formulaire utilise la méthode post pour encoder les données et les soumettre au serveur.
Les données à transmettre dans la méthode post nécessitent également un encodage URL, alors quelle méthode d'encodage utilise-t-elle ?
S'il y a un segment dans le fichier html où se trouve le formulaire, En général, tout le monde pense que ce code sert à indiquer au navigateur quel jeu de caractères utiliser pour interpréter la page Web. Le site Web le mettra donc au début du code HTML pour essayer d'éviter les caractères tronqués. il a également une autre fonction : Spécifiez la méthode d'encodage d'URL pour les données soumises par la méthode post du formulaire . On peut voir d'ici que pour la méthode get, la méthode d'encodage de l'encodage URL des données par le navigateur est déterminée par les paramètres du navigateur (elle peut être spécifiée uniformément avec js), et pour la méthode post, le développeur peut précisez-le.
2. Comment le côté serveur (Tomcat) obtient-il les données et les décode-t-il.
Si vous utilisez les paramètres par défaut de Tomcat et ne définissez aucun paramètre d'encodage tel que des filtres, il sera également décodé à l'aide de l'iso-8859-1, mais request.setCharacterEncoding("Character Set") peut s'avérer utile.

J'ai trouvé que la prémisse de ce que Tomcat a mentionné ci-dessus est que la méthode d'encodage n'est pas spécifiée dans l'en-tête de la requête. Si la méthode d'encodage est spécifiée dans l'en-tête de la requête, elle est spécifiée. sera de cette façon le codage.
Il y a 2 articles recommandés, les adresses sont
Expliquez le codage des URL en termes simples : http://www.cnblogs.com/ yencain/ articles/1321386.html;
Problème de caractères tronqués lorsque le formulaire soumet des données en utilisant la méthode post : http://wanghuan8086.javaeye. com/blog/173869

Il est très important d'utiliser post S'il y a une section dans le fichier html où se trouve le formulaire,
Il est fortement recommandé d'utiliser la soumission post