[JavaServlet] Résumé de la correspondance lorsque les paramètres japonais sont déformés

C'est ayaka de Kids Programming Class ITWORKS. Je vais coudre entre l'éducation des enfants et la décrire. Cette fois, j'oublierai la partie de confirmation sur les caractères brouillés des paramètres japonais des données de formulaire HTML lors de mon propre développement, donc je vais le résumer ☺️

Pourquoi est-il facile pour les caractères japonais d'être déformés en premier lieu?

En effet, avec les paramètres par défaut, lorsqu'un paramètre japonais est envoyé sous forme de données de formulaire HTML, il est encodé en URL et envoyé à l'adresse e-mail indiquée par l'action, le servlet du serveur Web, etc. ** En d'autres termes, si vous ne prenez pas de mesures, seuls les paramètres japonais doivent être décodés: sweat_smile: **

Les mesures japonaises diffèrent selon la méthode de soumission des données du formulaire

--Pour la transmission POST

Spécifiez le codage de caractères déclaré dans le fichier HTML dans setCharacterEncoding de HttpServlet.HttpServletRequest. Dans le cas de la transmission POST Les paramètres à transmettre étant inclus dans le corps de la requête HTTP, il peut être géré en définissant HttpServletRequest.

--Pour la transmission GET

Décodez avec le codage de caractères déclaré dans le fichier HTML.

:SampleHttpServlet.java
form_data_in_japanese = request.getParameter("form-name");
URLEncoder.encode(form_data_in_japanese , "Encodage de caractère");

Dans le cas de la transmission GET, rien n'est décrit dans le corps de la requête HTTP: flushed: Il est ajouté à l'URL et envoyé. Par conséquent, si les paramètres acquis incluent le japonais, un décodage est nécessaire.

Recommended Posts

[JavaServlet] Résumé de la correspondance lorsque les paramètres japonais sont déformés
Les caractères japonais décrits dans MessageResources.properties sont déformés
Résumé de la mousse lors de la mise à jour de JMockit 1.4 vers 1.30