JSP doit être "codé" deux fois. La première étape utilisera pageEncoding, la deuxième étape utilisera utf-8 vers utf-8 et la troisième étape est la page Web produite par Tomcat, en utilisant contentType.
Concernant la différence entre les attributs pageEncoding et contentType dans les pages JSP :
pageEncoding est l'encodage du fichier jsp lui-même
Le jeu de caractères de contentType fait référence à l'encodage du contenu lorsque le serveur l'envoie au client.
JSP doit être "codé" deux fois. La première étape utilisera pageEncoding, la deuxième étape utilisera utf-8 vers utf-8 et la troisième étape est la page Web produite par Tomcat, en utilisant contentType.
La première étape consiste à compiler jsp en .java. Il lira jsp selon le paramètre de pageEncoding. Le résultat est que le schéma de codage spécifié est traduit en un code source JAVA UTF-8 unifié (c'est-à-dire .java). le réglage est erroné, ou il n'y a pas de réglage, et ce qui ressort, ce sont des caractères chinois tronqués.
La deuxième étape est la compilation du code source JAVA de JAVAC vers java byteCode. Quel que soit le schéma de codage utilisé lors de l'écriture de JSP, les résultats de cette étape sont tous des codes sources Java codés en UTF-8.
JAVAC utilise le codage UTF-8 pour lire le code source Java et le compiler en code binaire de codage UTF-8 (c'est-à-dire .class). Il s'agit de la spécification de la JVM pour l'expression de chaînes constantes dans le code binaire (codage Java).
La troisième étape est que Tomcat (ou son conteneur d'application) charge et exécute le code binaire JAVA de la deuxième étape. Le résultat de sortie est ce qui est vu sur le client. À ce stade, le paramètre contentType masqué dans les étapes un et deux est Cela a fonctionné.
paramètre contentType.
Les valeurs par défaut pour pageEncoding et contentType sont toutes deux ISO8859-1. Si vous définissez l'un d'eux avec désinvolture, l'autre sera le même (c'est le cas pour TOMCAT4.1.27). Mais ce n'est pas absolu, cela dépend de la méthode de traitement. chaque JSPC pageEncoding n'est pas égal à contentType, ce qui est plus propice au développement et à l'affichage de pages Web JSP de texte CJKV en Asie (par exemple, pageEncoding=GB2312 n'est pas égal à contentType=utf-8).
Le fichier jsp n'est pas comme .java Lorsque .java est lu par le compilateur, il utilise par défaut le codage correspondant aux paramètres régionaux définis par le système d'exploitation. Généralement, que l'on écrive du code dans Notepad ou dans ue, s'il n'y a pas de transcodage spécial, ce qui est écrit sera le contenu dans le format d'encodage local. Par conséquent, la méthode adoptée par le compilateur peut simplement permettre à la machine virtuelle d’obtenir les bonnes données.
Mais ce n'est pas le cas pour les fichiers jsp. Il n'a pas ce processus de transcodage par défaut, mais un transcodage correct peut être obtenu en spécifiant pageEncoding.
Par exemple:
<%@ page contentType="text/html;charset=utf-8" %>
La plupart d'entre eux affichent des caractères tronqués, car le "Comment vas-tu" que j'ai entré vient de gbk, mais on ne sait pas si le serveur a correctement capturé "Comment vas-tu".
Changez-le simplement par le contenu suivant
<%@ page contentType="text/html;charset=utf-8" pageEncoding="GBK"%>