Analyse approfondie du traitement JSP et Servlet du chinois

Chaque région du monde a sa propre langue locale. Les différences régionales entraînent directement des différences dans l'environnement linguistique. Dans le processus d’élaboration d’un programme international, il est important de traiter les questions linguistiques.

Il s'agit d'un problème qui existe dans le monde entier, Java fournit donc une solution mondiale. La méthode décrite dans cet article concerne le traitement du chinois, mais par extension, elle est également applicable au traitement des langues d'autres pays et régions du monde.

Les caractères chinois sont codés sur deux octets. Ce qu'on appelle le double octet signifie qu'un double mot occupe deux positions BYTE (c'est-à-dire 16 bits), appelées respectivement bits de poids fort et bits de poids faible. Le codage des caractères chinois spécifié en Chine est GB2312, qui est actuellement obligatoire, presque toutes les applications capables de traiter le chinois prennent en charge GB2312. GB2312 comprend des caractères chinois de premier et deuxième niveaux et 9 symboles de zone. Les bits élevés vont de 0xa1 à 0xfe, et les bits faibles vont également de 0xa1 à 0xfe. Parmi eux, la plage de codage des caractères chinois est 0xb0a1 à 0xf7fe.

Il existe un autre codage appelé GBK, mais il s’agit d’une spécification non obligatoire. GBK fournit 20902 caractères chinois, compatibles avec GB2312, et la plage de codage va de 0x8140 à 0xfefe. Tous les caractères de GBK peuvent être mappés vers Unicode 2.0 un par un.

Dans un avenir proche, la Chine promulguera une autre norme : GB18030-2000 (GBK2K). Il inclut les polices des minorités ethniques tibétaines, mongoles et autres, résolvant fondamentalement le problème des positions de caractères insuffisantes. Remarque : la longueur n'est plus fixe. La partie à deux octets est compatible avec GBK et la partie à quatre octets est constituée de caractères et de glyphes étendus. Ses premier et troisième octets vont de 0x81 à 0xfe, et ses deuxième et quatrième octets vont de 0x30 à 0x39.

Cet article n'a pas pour but de présenter Unicode. Ceux qui sont intéressés peuvent parcourir « http://www.unicode.org/ » pour afficher plus d'informations. Unicode a une particularité : il inclut tous les glyphes de caractères du monde. Par conséquent, les langues de diverses régions peuvent établir des relations de mappage avec Unicode, et Java en profite pour réaliser la conversion entre des langues hétérogènes.

Dans le JDK, les encodages liés au chinois sont :

Tableau 1 Liste des encodages liés au chinois dans le JDK

dans la pratique, ceux avec lesquels je suis le plus en contact sont GB2312 (GBK) et ISO8859-1.

Pourquoi y a-t-il un signe « ? »

Comme mentionné ci-dessus, la conversion entre les différentes langues s'effectue via Unicode. Supposons qu'il existe deux langues différentes A et B. Les étapes de conversion sont les suivantes : convertissez d'abord A en Unicode, puis convertissez Unicode en B.

Donnez des exemples. Il y a un caractère chinois « 李 » dans GB2312 et son code est « C0EE », qui doit être converti en code ISO8859-1. Les étapes sont les suivantes : convertissez d'abord le caractère "李" en Unicode pour obtenir "674E", puis convertissez "674E" en caractères ISO8859-1. Bien entendu, ce mappage ne réussira pas, car il n'existe aucun caractère correspondant à "674E" dans ISO8859-1.

Le problème survient lorsque le mappage échoue ! Lors de la conversion d'une certaine langue vers Unicode, si le caractère n'existe pas dans une certaine langue, le résultat sera le code Unicode "uffffd" ("u" signifie encodage Unicode). Lors de la conversion d'Unicode vers une certaine langue, si une certaine langue n'a pas de caractères correspondants, vous obtiendrez "0x3f" ("?"). C'est de là que vient le "?"

Par exemple : effectuez la nouvelle opération String(buf, "gb2312") sur le flux de caractères buf = "0x80 0x40 0xb0 0xa1", le résultat sera "ufffdu554a", puis imprimez-le, le résultat sera " ?ah", Parce que "0x80 0x40" est un caractère en GBK, pas en GB2312.

Pour un autre exemple, effectuez la nouvelle opération String (buf.getBytes("GBK")) sur la chaîne String="u00d6u00ecu00e9u0046u00bbu00f9", et le résultat est "3fa8aca8a6463fa8b4", parmi lesquels, "u00d6 "Il n'y a pas de caractère correspondant dans "GBK", on obtient donc "3f", "u00ec" correspond à "a8ac", "u00e9" correspond à "a8a6" et "0046" correspond à "46" (car il s'agit d'un caractère ASCII), "u00bb" n'a pas été trouvé et "3f" a été obtenu. Enfin, "u00f9" correspond à "a8b4". Imprimez cette chaîne et le résultat est "?ìéF?ù". Avez-vous vu ça ? Il n’y a pas que des points d’interrogation ici, car le contenu mappé entre GBK et Unicode inclut des caractères en plus des caractères chinois. Cet exemple en est la meilleure preuve.

Par conséquent, lors du transcodage de caractères chinois, en cas de confusion, vous n'aurez pas nécessairement de points d'interrogation ! Cependant, après tout, une erreur reste une erreur. Il n’y a pas de différence qualitative entre 50 et 100 étapes.

Ou vous pouvez demander : quel sera le résultat s’il est inclus dans le jeu de caractères source mais pas dans Unicode ? La réponse est que je ne sais pas. Parce que je n'ai pas le personnage source sous la main pour faire ce test. Mais une chose est sûre, c’est que le jeu de caractères source n’est pas suffisamment standardisé. En Java, si cela se produit, une exception sera levée.

Qu'est-ce que UTF

UTF est l'abréviation de Unicode Text Format, qui signifie format de texte Unicode. Pour UTF, il est défini comme suit :

(1) Si les 9 premiers bits d'un caractère Unicode 16 bits sont 0, il est représenté par un octet. Le premier bit de cet octet est "0", et les 7 bits restants. sont identiques au caractère d'origine. Les 7 derniers chiffres sont les mêmes, tels que "u0034" (0000 0000 0011 0100), représenté par "34" (0011 0100) (identique au caractère Unicode source)

; 2) Si les 5 premiers caractères Unicode de 16 bits Si le bit est 0, il est représenté par 2 octets. Le premier octet commence par "110", et les 5 bits suivants sont identiques aux 5 bits les plus élevés de la source. caractère après avoir exclu les 5 premiers zéros ; le deuxième octet commence par "10". Au début, les 6 bits suivants sont les mêmes que les 6 bits inférieurs du caractère source. Par exemple, "u025d" (0000 0010 0101 1101) sera converti en "c99d" (1100 1001 1001 1101) ;

(3) S'il ne respecte pas les deux règles ci-dessus, il sera représenté par trois octets. Le premier octet commence par « 1110 » et les quatre derniers bits sont les quatre bits de poids fort du caractère source ; le deuxième octet commence par « 10 » et les six derniers bits sont les six bits du milieu du caractère source ; L'octet commence par "10". En commençant par "10", les six derniers chiffres sont les six chiffres inférieurs du caractère source ; par exemple, "u9da7" (1001 1101 1010 0111) est converti en "e9b6a7" (1110 1001 1011). 0110 1010 0111);

la différence entre Unicode et Unicode dans les programmes JAVA peut être décrite ainsi. La relation entre UTF n'est pas absolue : lorsqu'une chaîne est exécutée en mémoire, elle apparaît comme un code Unicode, et lorsqu'elle est enregistrée dans un fichier ou d'autres médias, UTF est utilisé. Ce processus de conversion est complété par writeUTF et readUTF.

Bon, la discussion de base est presque terminée, venons-en au fait.

Considérez d’abord le problème comme une boîte noire. Regardons d'abord la représentation de premier niveau de la boîte noire :

input(charsetA)->process(Unicode)->output(charsetB)

est simple. Il s'agit d'un modèle IPO, c'est-à-dire l'entrée, le traitement et la sortie. Le même contenu doit être converti de charsetA en unicode puis en charsetB.

Regardons la représentation secondaire :

SourceFile(jsp,java)->class->output

Dans cette figure, on peut voir que l'entrée est constituée de fichiers sources jsp et java. Lors du traitement, le fichier Class est utilisé comme support. puis sortie. Ensuite, affinez-le au troisième niveau :

jsp->temp file->class->browser,os console,db

app,servlet->class->browser,os console,db

Cette image sera plus claire. Le fichier Jsp génère d'abord le fichier Java intermédiaire, puis génère la classe. Les servlets et les applications ordinaires sont directement compilées pour générer la classe. Ensuite, sortie de la classe vers le navigateur, la console ou la base de données, etc.

JSP : Le processus du fichier source à la classe

Le fichier source de Jsp est un fichier texte se terminant par « .jsp ». Dans cette section, le processus d'interprétation et de compilation des fichiers JSP sera expliqué et les modifications chinoises seront suivies.

1. L'outil de conversion JSP (jspc) fourni par le moteur JSP/Servlet recherche le jeu de caractères spécifié dans <%@ page contentType ="text/html; charset=<Jsp-charset>"%> dans le fichier JSP. Si <Jsp-charset> n'est pas spécifié dans le fichier JSP, le paramètre par défaut file.encoding dans la JVM est utilisé. Dans des circonstances normales, cette valeur est ISO8859-1.

jspc utilise l'équivalent de "javac –encoding <Jsp". -charset> " interprète tous les caractères apparaissant dans le fichier JSP, y compris les caractères chinois et les caractères ASCII, puis convertit ces caractères en caractères Unicode, puis les convertit au format UTF et les enregistre sous forme de fichiers JAVA. Lors de la conversion de caractères ASCII en caractères Unicode, vous ajoutez simplement "00" devant, comme "A", qui est converti en "u0041" (aucune raison n'est nécessaire, c'est ainsi que la table de codes Unicode est compilée). Puis, après la conversion en UTF, il est revenu à « 41 » ! C'est pourquoi vous pouvez utiliser un éditeur de texte ordinaire pour afficher les fichiers JAVA générés par JSP ;

3.

Le moteur utilise la commande équivalente à " javac -encoding UNICODE " pour compiler les fichiers JAVA en fichiers CLASS ;

situation de conversion de ces processus. Il existe le code source suivant :

<%@ page contentType="text/html; charset=gb2312"%>
<html><corps>
<%
Chaîne a="Chinois" ;
out.println(a);
%>
</body></html>

Ce code a été écrit sur UltraEdit pour Windows. Après sauvegarde, le codage hexadécimal des deux caractères « Chinois » est « D6 D0 CE C4 » (codage GB2312). Après avoir consulté le tableau, le codage Unicode du mot « chinois » est « u4E2Du6587 », qui en UTF est « E4 B8 AD E6 96 87 ». Ouvrez le fichier JAVA converti à partir du fichier JSP généré par le moteur, et constatez que le mot « Chinois » a bien été remplacé par « E4 B8 AD E6 96 87 ». Vérifiez ensuite le fichier CLASS généré par la compilation du fichier JAVA, et recherchez. que le résultat est exactement le même que dans le fichier JAVA.

Regardons la situation où le CharSet spécifié dans JSP est ISO-8859-1.

<%@ page contentType="text/html; charset=ISO-8859-1"%>
<html><corps>
<%
Chaîne a="Chinois" ;
out.println(a);
%>
</body></html>

De même, ce fichier est écrit avec UltraEdit, et les deux caractères "chinois" sont également stockés sous le codage GB2312 "D6 D0 CE C4". Simulez d'abord le processus de génération de fichiers JAVA et de fichiers CLASS : jspc utilise ISO-8859-1 pour interpréter le "chinois" et le mappe en Unicode. Étant donné que l'ISO-8859-1 est 8 bits et est une langue latine, sa règle de mappage est d'ajouter "00" avant chaque octet, donc le codage Unicode mappé doit être "u00D6u00D0u00CEu00C4" , après conversion en UTF, cela devrait être "C3 96 C3 90 C3 8E C3 84". Bon, ouvrez le fichier et jetez un œil. Dans le fichier JAVA et le fichier CLASS, "Chinois" est en effet exprimé par "C3 96 C3 90 C3 8E C3 84".

Si <Jsp-charset> n'est pas spécifié dans le code ci-dessus, c'est-à-dire que la première ligne est écrite sous la forme "<%@ page contentType="text/html" %>", JSPC utilisera le paramètre file.encoding pour interpréter le Fichier JSP. Sur RedHat 6.2, le résultat du traitement est exactement le même que celui de la spécification ISO-8859-1.

Jusqu'à présent, le processus de mappage des caractères chinois dans le processus de conversion des fichiers JSP en fichiers CLASS a été expliqué. En un mot : de "JspCharSet à Unicode à UTF". Le tableau suivant résume ce processus :

Tableau 2 Processus de conversion « chinois » de JSP vers CLASS

Servlet : le processus du fichier source à la classe.

Le fichier source du servlet est un fichier texte se terminant par ".java". Cette section discutera du processus de compilation du servlet et suivra les modifications chinoises.

Utilisez "javac" pour compiler le fichier source du servlet. javac peut prendre le paramètre "-encoding <Compile-charset>", ce qui signifie "utiliser l'encodage spécifié dans <Compile-charset> pour interpréter le fichier source Serlvet".

Lorsque le fichier source est compilé, utilisez <Compile-charset> pour interpréter tous les caractères, y compris les caractères chinois et les caractères ASCII. Convertissez ensuite les constantes de caractères en caractères Unicode et enfin, convertissez Unicode en UTF.

Dans Servlet, il existe un autre endroit pour définir le CharSet du flux de sortie. Habituellement, avant de générer le résultat, la méthode setContentType de HttpServletResponse est appelée pour obtenir le même effet que la définition de <Jsp-charset> dans JSP, appelée <Servlet-charset>.

Notez qu'un total de trois variables sont mentionnées dans l'article : <Jsp-charset>, <Compile-charset> et <Servlet-charset>. Parmi eux, les fichiers JSP sont uniquement liés à <Jsp-charset>, tandis que <Compile-charset> et <Servlet-charset> sont uniquement liés à Servlet.

Regardez l'exemple suivant :

import javax.servlet.*;

import

javax.servlet.http.*;

{
public void doGet (HttpServletRequest req, HttpServletResponse resp)
lance ServletException, java.io.IOException
{
resp.setContentType("text/html; charset=GB2312");
java.io.PrintWriter out=resp.getWriter();
out.println("<html>");
out.println("#中文#");
out.println("</html>");
}
}

Ce fichier est également écrit avec UltraEdit pour Windows, et les deux caractères « chinois » sont enregistrés sous « D6 D0 CE C4 » (encodage GB2312).

Commencez à compiler. Le tableau suivant montre le code hexadécimal du mot « Chinois » dans le fichier CLASS lorsque <Compile-charset> est différent. Lors de la compilation, <Servlet-charset> n'a aucun effet. <Servlet-charset> n'affecte que la sortie du fichier CLASS. En fait, <Servlet-charset> et <Compile-charset> fonctionnent ensemble pour obtenir le même effet que <Jsp-charset> dans le fichier JSP, car <Jsp- charset >Cela aura un impact sur la compilation et la sortie des fichiers CLASS.

Tableau 3 Le processus de transformation du « chinois » du fichier source du servlet en classe