jsp solution au problème chinois (version complète)

===================================
Il est très courant que des caractères tronqués apparaissent lors du développement d'applications Java. Après tout, Unicode n'est pas largement utilisé actuellement dans un système utilisant gb2312 (y compris gbk simplifié et big5 traditionnel),

c'est la condition la plus fondamentale pour implémenter correctement l'affichage et le chinois. stockage de base de données.

==============================
1. Tout d'abord, le développeur doit comprendre pourquoi il rencontre du code tronqué et quel type de code tronqué il rencontre (des symboles dénués de sens, une chaîne de points d'interrogation ou autre chose).
Les novices sont généralement désemparés lorsqu'ils rencontrent un tas de caractères désordonnés. La réaction la plus directe est d'ouvrir Google et de rechercher « java chinois » (cette chaîne est fréquemment interrogée sur les moteurs de recherche),

puis de regarder les caractères des autres un par un. une. Il n’y a rien de mal à faire cela, mais il est difficile d’atteindre l’objectif, pour les raisons mentionnées ci-dessous.
Bref, les raisons des caractères tronqués sont nombreuses, et les solutions sont complètement différentes. Pour résoudre le problème, vous devez d'abord analyser votre propre « contexte ».

============================
2. Plus précisément, quelles informations sont nécessaires pour déterminer la source du code tronqué dans le projet.
a. Le système d'exploitation utilisé par le développeur
b, le nom et la version du conteneur j2ee
c, nom de la base de données, version (version exacte) et version du pilote jdbc
d. Il y a du code source tronqué (par exemple, il vient du système ou il se trouve dans une page jsp. S'il est dans une page jsp, la déclaration d'en-tête est également très importante)

========== === ===============================================
3. Comment analyser initialement les causes des caractères tronqués.
Avec les informations ci-dessus, vous pouvez essentiellement publier pour obtenir de l'aide. Je pense que si vous les publiez sur des forums tels que Javaworld, les experts vous proposeront bientôt des solutions efficaces.
Bien sûr, vous ne pouvez pas toujours compter sur l’aide que vous postez, mais vous devriez également essayer de résoudre le problème vous-même. Comment commencer ?
a. Analysez quel est l'encodage de votre "code tronqué". Ce n'est en fait pas difficile, par exemple
System.out.println(testString);
Il y a du code tronqué dans ce paragraphe, vous pouvez donc aussi bien utiliser la méthode exhaustive pour deviner son format d'encodage réel.
System.out.println(new String(testString.getBytes(”ISO-8859-1″),,”gb2312″));
System.out.println(new String(testString.getBytes(”UTF8″),,”gb2312″));
System.out.println(new String(testString.getBytes(”GB2312″),,”gb2312″));
System.out.println(new String(testString.getBytes("GBK"),"gb2312"));
System.out.println(new String(testString.getBytes("BIG5"),"gb2312"));
Attendez, le code ci-dessus signifie utiliser le format d'encodage spécifié pour lire le "code tronqué" de testString et le convertir en gb2312 (seul le chinois est utilisé comme exemple ici)
Ensuite, vous voyez quel résultat converti est correct, c'est tout. . .

b. Si vous parvenez à obtenir le chinois correct en suivant les étapes ci-dessus, cela signifie que vos données sont bien là, mais qu'elles ne s'affichent tout simplement pas correctement dans l'interface. Ensuite, la deuxième étape consiste à corriger votre vue

. Ce qui doit généralement être vérifié, c'est si le bon encodage de page est sélectionné dans le jsp.

Je voudrais souligner quelque chose qui a été mal compris par beaucoup de gens, à savoir la directive <%@ page contentType="text/html; charset=GB2312″ %> et <META http-equiv=Content-Type

content="text /html; charset= gb2312″>La différence entre les deux. Habituellement, lorsque de nombreux articles sur Internet mentionnent des problèmes chinois, ils disent que le choix du stockage Unicode ou gb2312 dans la base de données peut être résolu

en utilisant

Mais je pense que cette déclaration est tout à fait irresponsable, et elle m'a amené à passer beaucoup de temps à être déprimé à cause de codes tronqués qui n'existaient pas au départ. En fait, le rôle de page

est de fournir une méthode de codage permettant à Java de "lire" la chaîne dans l'expression pendant le processus de compilation de JSP en HTML (un peu similaire au rôle de la troisième instruction ci-dessus), et le

rôle de méta est bien connu. Fournit des options de codage pour les navigateurs IE, qui sont utilisées pour « afficher » les données finales. Mais je n'ai vu personne me le rappeler. J'ai toujours utilisé la page comme méta,

ce qui faisait que les données qui étaient à l'origine iso-8859 étaient lues comme gb2312 par la commande page, donc elles étaient tronquées, j'ai donc ajouté un codage. fonction de conversion pour convertir toutes les données de chaîne. Ils sont tous passés d'iso8859 à gb2312 (

pourquoi

=================================================== =============
4. Quel encodage est le meilleur pour la base de données ?
Les bases de données actuellement populaires incluent principalement SQL Server, MySQL, Oracle, DB2, etc. Parmi elles, MySQL est le leader parmi les bases de données gratuites. Ses performances et ses fonctions sont reconnues. Il est relativement pratique à installer et à configurer, et le pilote

correspondant

. Prenons donc MySQL comme exemple.

Je recommande personnellement d'utiliser le codage par défaut de MySQL pour le stockage, qui est iso-8859-1 (correspondant au latin-1 dans les options de MySQL). Il y a plusieurs raisons principales. Premièrement, l'iso-8859-1 prend bien en charge le

chinois

La stabilité est également meilleure, car la prise en charge du multi-encodage

est fournie par des produits de base de données spécifiques, sans parler de l'incompatibilité avec d'autres bases de données, même différentes versions d'elles-mêmes peuvent avoir des problèmes de compatibilité.

Par exemple, dans les produits antérieurs à MySQL 4.0, de nombreuses solutions chinoises utilisent le champ CharacterEncoding dans la connexion pour définir le codage, tel que gb2312 ou quelque chose du genre. C'est OK

car les données d'origine sont codées en ISO8859_1 et le pilote jdbc utilisera celui spécifié. dans l'URL. Le jeu de caractères est utilisé pour le codage et resultSet.getString(*) supprime la

chaîne codée. De cette façon, vous pouvez obtenir directement les données de gb2312.

Cependant, le lancement de MySQL 4.1 a causé beaucoup de problèmes à de nombreux administrateurs de base de données, car MySQL 4.1 prend en charge le jeu de caractères au niveau des colonnes. Chaque table et colonne peuvent spécifier l'encodage

s'il n'est pas spécifié, ce sera ISO8895_1, donc après que jdbc ait supprimé le. data, il sera basé sur la colonne. Le jeu de caractères est utilisé pour le codage, au lieu d'utiliser un paramètre global pour obtenir toutes les données.

Cela montre également sous un autre aspect que le problème des caractères tronqués est vraiment compliqué et a trop de raisons. Je propose simplement quelques solutions à la situation réelle que j'ai rencontrée. S'il y a des

erreurs

Usage interne uniquement.
Pour toute question, veuillez vous référer à [email protected]
=================================================== ==============

J'ai enfin trouvé la solution la plus parfaite au problème chinois. . . Merci à l'auteur de cet article en ligne. . .
Mon article original est basé sur ma propre expérience. Même s’il n’y avait rien de mal, la cause profonde du problème n’a jamais été trouvée. Après avoir lu cet article, j'ai soudain réalisé, haha,
—————————————————————————————————————————————— ———— ——————-

Étant donné que le problème chinois dans la programmation Java est un problème courant, après avoir lu de nombreuses solutions aux problèmes chinois Java, combinées à la pratique de programmation de l'auteur, j'ai découvert que bon nombre des méthodes discutées dans le passé ne peuvent pas expliquer clairement le problème et résoudre le problème, en particulier le problème chinois en multiplateforme.
J'ai donc donné cet article, qui comprend mon analyse et des suggestions de solutions aux problèmes chinois dans les classes, les Servelets, les classes JSP et EJB fonctionnant sur la console. J'espère que vous pourrez me donner quelques conseils.

Résumé : Cet article analyse en profondeur le processus d'encodage/décodage des fichiers source Java par le compilateur Java et des fichiers de classe par JVM dans la programmation Java. Grâce à l'analyse de ce processus, la cause profonde des problèmes chinois dans la programmation Java est enfin révélée. étant donné La méthode optimale proposée pour résoudre les problèmes Java chinois.

1. La source du problème chinois

.Le codage pris en charge par le système d'exploitation d'origine de l'ordinateur était un codage de caractères sur un seul octet. Par conséquent, tous les programmes de traitement de l'ordinateur étaient initialement traités en anglais avec un codage sur un seul octet.

Avec le développement des ordinateurs, afin de s'adapter aux langues des autres nations du monde (y compris bien sûr nos caractères chinois), on a proposé le codage UNICODE, qui utilise un codage sur deux octets et est compatible avec les caractères anglais. et les codages de caractères à deux octets d'autres pays. Par conséquent, actuellement, la plupart des logiciels internationaux utilisent le codage UNICODE en interne. Lorsque le logiciel est en cours d'exécution, il obtient le format de codage pris en charge par défaut par le système de support local (la plupart du temps, le système d'exploitation). ), puis convertit l'UNICODE dans le logiciel dans le format de codage pris en charge par le système local par défaut. Le format s'affiche.

C'est le cas du JDK et de la JVM de Java. Le JDK dont je parle ici fait référence à la version internationale du JDK. La plupart de nos programmeurs utilisent la version internationalisée du JDK. Tous les JDK suivants font référence à la version internationalisée du JDK. Nos caractères chinois sont un langage de codage sur deux octets Afin de permettre aux ordinateurs de traiter le chinois, nous avons développé nos propres normes telles que gb2312, GBK et GBK2K pour répondre aux besoins du traitement informatique.

Par conséquent, afin de s'adapter à nos besoins de traitement du chinois, la plupart des systèmes d'exploitation ont des systèmes d'exploitation chinois personnalisés. Ils utilisent les formats d'encodage GBK et GB2312 pour afficher correctement nos caractères chinois. Par exemple : Windows chinois utilise le codage GBK pour l'affichage par défaut Lors de l'enregistrement de fichiers dans Windows 2000 chinois, le format de codage utilisé par défaut pour enregistrer les fichiers est également GBK. Autrement dit, le codage interne de tous les fichiers enregistrés dans Windows 2000 chinois utilise GBK. encodage par défaut Remarque : GBK est étendu sur la base de GB2312.

Étant donné que le langage Java utilise le codage UNICODE en interne, lorsque le programme Java est en cours d'exécution, il existe un problème de conversion des entrées et des sorties du codage UNICODE et du format de codage correspondant pris en charge par le système d'exploitation et le navigateur. Ce processus de conversion comporte une série d'étapes. S'il y a une erreur dans l'une des étapes, les caractères chinois affichés seront tronqués. Il s'agit de notre problème commun en chinois Java.

Dans le même temps, Java est un langage de programmation multiplateforme, ce qui signifie que les programmes que nous écrivons peuvent non seulement fonctionner sur Windows chinois, mais également sur Linux chinois et d'autres systèmes. Il est également nécessaire de fonctionner sur des systèmes anglais et autres (. nous voyons souvent quelqu'un transplanter un programme Java écrit sur Windows 2000 chinois pour fonctionner sur Linux anglais). Cette opération de transplantation posera également des problèmes aux Chinois.

En outre, certaines personnes utilisent des systèmes d'exploitation anglais et des navigateurs anglais tels que IE pour exécuter des programmes avec des caractères chinois et parcourir des pages Web en chinois. Ils ne prennent pas en charge le chinois eux-mêmes et causeront également des problèmes liés au chinois.

Presque tous les navigateurs transmettent par défaut les paramètres au format de codage UTF-8 au lieu du codage chinois. Par conséquent, il y aura également des problèmes lors de la transmission des paramètres chinois, ce qui entraînera des caractères tronqués.

En bref, les aspects ci-dessus sont les principales sources des problèmes chinois en Java. Nous appelons les problèmes causés par le mauvais fonctionnement du programme pour les raisons ci-dessus : problèmes Java chinois.

2. Processus détaillé de conversion du codage Java.Nos

programmes Java courants incluent les catégories suivantes :

*Classes qui s'exécutent directement sur la console (y compris les classes d'interface visuelle)

*Classes de code JSP (Remarque : JSP est une variante de la classe Servlets)

*Servelets

classe

* Classe EJB

* autres classes de support qui ne peuvent pas être exécutées directement.

Ces fichiers de classe peuvent contenir des chaînes chinoises, et nous utilisons souvent les trois premiers types de programmes Java pour interagir directement avec les utilisateurs pour les caractères de sortie et d'entrée, tels que : nous utilisons JSP. et Le Servlet récupère les caractères envoyés par le client, et ces caractères incluent également des caractères chinois. Quel que soit le rôle de ces classes Java, le cycle de vie de ces programmes Java est le suivant :

*Les programmeurs choisissent un logiciel d'édition approprié sur un certain système d'exploitation pour implémenter le code du programme source et l'enregistrent dans le système d'exploitation avec l'extension .Java. , par exemple, nous utilisons le Bloc-notes pour éditer un programme source Java dans Windows 2000 en chinois.

*Les programmeurs utilisent Javac.exe dans JDK pour compiler ces codes sources afin de former des classes .class (les fichiers JSP sont compilés par le conteneur appelant JDK).

*Exécutez ces classes directement ou déployez ces classes sur le conteneur WEB pour exécuter et afficher les résultats.

Alors, pendant ces processus, comment le JDK et la JVM encodent-ils, décodent-ils et exécutent-ils ces fichiers ?

Ici, nous prenons le système d'exploitation chinois Windows 2000 comme exemple pour illustrer comment les classes Java sont codées et décodées.

La première étape consiste à utiliser un logiciel d'édition tel que le Bloc-notes pour écrire un fichier programme source Java (y compris les cinq types de programmes Java ci-dessus) dans Windows 2000 en chinois. Lors de l'enregistrement du fichier programme, le fichier programme utilise le format de codage GBK pris en charge par le système d'exploitation par défaut (pris en charge par le système d'exploitation par défaut). Le format est le format file.encoding) formant un fichier .Java, c'est-à-dire qu'avant la compilation du programme Java, notre fichier de programme source Java est enregistré dans le fichier .encoding. format d'encodage pris en charge par le système d'exploitation par défaut. Dans le programme source Java Contient des caractères d'information chinois et des codes de programme anglais ; pour afficher le paramètre file.encoding du système, vous pouvez utiliser le code suivant :

classe publique ShowSystemDefaultEncoding ;
{
public static void main (String[] arguments)
{
Encodage de chaîne =
System.getProperty("file.encoding");
System.out.println(encodage);
}
}

Dans la deuxième étape, nous utilisons le fichier Javac.exe du JDK pour compiler notre programme source Java. Puisque JDK est une version internationale, lors de la compilation, si nous n'utilisons pas le paramètre -encoding pour spécifier le format d'encodage de notre source Java. programme, alors Javac.exe obtient d'abord le format d'encodage utilisé par notre système d'exploitation par défaut. Autrement dit, lors de la compilation d'un programme Java, si nous ne spécifions pas le format d'encodage du fichier du programme source, JDK obtient d'abord le paramètre file.encoding. du système d'exploitation (qui enregistre le format d'encodage par défaut, tel que Windows2000, sa valeur est GBK), puis JDK convertit notre programme source Java du format d'encodage file.encoding au format UNICODE interne par défaut de Java et le met en mémoire.

Ensuite, Javac compile le fichier au format Unicode converti en un fichier de classe .class. À ce stade, le fichier .class est codé en UNICODE et il est temporairement placé dans la mémoire. Ensuite, JDK compile la classe compilée en codage UNICODE. est enregistré sur notre système d'exploitation pour former le fichier .class que nous voyons.

Pour nous, le fichier .class que nous avons finalement obtenu est un fichier de classe dont le contenu est enregistré au format de codage UNICODE. Il contient la chaîne chinoise dans notre programme source, mais pour le moment il a été converti au format UNICODE via le format file.encoding. .

Dans cette étape, le fichier programme source JSP est différent. Pour JSP, le processus est le suivant : c'est-à-dire que le conteneur WEB appelle le compilateur JSP. Le compilateur JSP vérifie d'abord si le format d'encodage du fichier est défini dans le fichier JSP. il n'y a pas de format d'encodage de fichier dans le fichier JSP. Pour définir le format d'encodage du fichier JSP, le compilateur JSP appelle JDK pour convertir d'abord le fichier JSP en une classe Servlet temporaire en utilisant le format d'encodage de caractères par défaut de la JVM (c'est-à-dire le format par défaut fichier.encoding du système d'exploitation où se trouve le conteneur WEB), puis il est compilé dans une classe au format UNICODE et enregistré dans un dossier temporaire.

Par exemple : sous Windows 2000 chinois, le conteneur WEB convertit le fichier JSP du format d'encodage GBK au format UNICODE, puis le compile dans une classe Servlet temporairement enregistrée pour répondre à la demande de l'utilisateur.

La troisième étape consiste à exécuter la classe compilée lors de la deuxième étape, qui se divise en trois situations :
A. Classes qui s'exécutent directement sur la console

B. Classes EJB et classes de support qui ne peuvent pas être exécutées directement (telles que les classes JavaBean)

C. Code JSP et classes Servlet

D. Entre les programmes Java et les bases de données

Examinons ces quatre situations ci-dessous.

R. Dans le cas d'une classe qui s'exécute directement sur la console

, l'exécution de cette classe nécessite d'abord la prise en charge de JVM, c'est-à-dire que JRE doit être installé dans le système d'exploitation. Le processus en cours est le suivant : Tout d'abord, Java démarre la JVM. À ce moment, la JVM lit le fichier de classe enregistré dans le système d'exploitation et lit le contenu dans la mémoire. À ce moment, la mémoire est une classe au format UNICODE. puis la JVM l'exécute. Si à ce moment-là, si cette classe a besoin de recevoir une entrée de l'utilisateur, la classe utilisera le format d'encodage file.encoding par défaut pour encoder la chaîne saisie par l'utilisateur, la convertir en Unicode et l'enregistrer en mémoire. (l'utilisateur peut définir le format d'encodage du flux d'entrée).

Une fois le programme exécuté, la chaîne générée (codée UNICODE) est renvoyée à la JVM. Enfin, le JRE convertit la chaîne au format file.encoding (l'utilisateur peut définir le format d'encodage du flux de sortie) et la transmet au système d'exploitation. l'interface d'affichage et l'envoie à l'interface. Chacune des étapes de conversion ci-dessus nécessite une conversion correcte du format de codage afin que les caractères tronqués n'apparaissent pas à la fin. B. Classes EJB et classes de support qui ne peuvent pas être exécutées directement (telles que les classes JavaBean)

. Étant donné que les classes EJB et les classes de support ne peuvent pas être exécutées directement, elles n'interagissent généralement pas directement avec les utilisateurs pour les entrées et les sorties. pour l'entrée et la sortie, donc après leur compilation dans la deuxième étape, ils forment une classe dont le contenu est encodé UNICODE et sont enregistrés dans le système d'exploitation à l'avenir, tant qu'il n'y a pas d'interaction entre celle-ci et d'autres classes. perdu lors du processus de passage des paramètres, il fonctionnera correctement.

C.

Après la deuxième étape du code JSP et de la classe Servlet, le fichier JSP est également converti en fichier de classe Servlets, mais il n'existe pas dans le répertoire classes comme les Servlets standards. Il existe dans le répertoire temporaire du conteneur WEB. , donc dans cette étape, nous le considérons également comme des servlets.

Pour les Servlets, lorsque le client le demande, le conteneur WEB appelle sa JVM pour exécuter le Servlet. Tout d'abord, la JVM lit la classe Servlet du système et la charge dans la mémoire. Dans la mémoire se trouve le code de la classe Servlet encodé. UNICODE. Ensuite, la JVM exécute la classe Servlet en mémoire. Si le Servlet est en cours d'exécution, il doit accepter les caractères du client, tels que les valeurs saisies dans le formulaire et les valeurs transmises dans l'URL. temps, si le programme n'est pas configuré pour accepter Si le format d'encodage est utilisé comme paramètre, le conteneur WEB utilisera le format d'encodage ISO-8859-1 par défaut pour accepter la valeur entrante et la convertir au format UNICODE dans la JVM et enregistrez-le dans la mémoire du conteneur WEB.

Une fois le servlet exécuté, il génère une sortie et la chaîne de sortie est au format UNICODE. Ensuite, le conteneur envoie directement la chaîne au format UNICODE (telle que la syntaxe HTML, la chaîne de sortie utilisateur, etc.) générée par l'exécution du servlet au client. navigateur et l'envoie vers Si l'utilisateur spécifie le format de codage pour la sortie lors de l'envoi à ce moment-là, il sera envoyé vers le navigateur dans le format de codage spécifié. S'il n'est pas spécifié, il sera envoyé au navigateur du client au format ISO-8859-. 1 encodage par défaut.

D. Entre le programme Java et la base de données

Pour presque tous les pilotes JDBC de base de données, le format de codage par défaut pour le transfert de données entre le programme Java et la base de données est ISO-8859-1. Par conséquent, notre programme transmet des données à la base de données lors du stockage de données contenant du chinois. le programme, JDBC convertit d'abord les données au format d'encodage UNICODE à l'intérieur du programme au format ISO-8859-1, puis les transmet à la base de données. Lorsque la base de données enregistre les données, la valeur par défaut est ISO-8859-1. c'est pourquoi les données chinoises que nous lisons souvent dans la base de données sont tronquées.

3. Plusieurs principes à comprendre lors de l'analyse des problèmes Java chinois courants

.Tout d'abord, après l'analyse détaillée ci-dessus, nous pouvons clairement voir que dans le cycle de vie de tout programme Java, le processus clé de conversion d'encodage est : initialement compilé en classe. fichier Le transcodage et le processus de transcodage final sont envoyés à l'utilisateur.

Deuxièmement, nous devons comprendre que les formats d'encodage suivants couramment utilisés et pris en charge par Java au moment de la compilation sont :

*ISO-8859-1, 8 bits, identique à 8859_1, ISO-8859-1, ISO_8859_1 et autres encodages

*Cp1252, américain Encodage anglais, identique à l'encodage standard ANSI

*UTF-8, identique à l'encodage unicode

*GB2312, identique à gb2312-80, gb2312-1980 et autres encodages

*GBK, identique à MS936, il s'agit d'une extension de gb2312 et d'autres codages, tels que le coréen, le japonais, le chinois traditionnel, etc. Dans le même temps, nous devons prêter attention à la relation de compatibilité entre ces codages comme suit :

Les codages Unicode et UTF-8 ont une correspondance biunivoque. GB2312 peut être considéré comme un sous-ensemble de GBK, c'est-à-dire que le codage GBK est étendu sur gb2312. Dans le même temps, le codage GBK contient 20902 caractères chinois et la plage de codage est : 0×8140-0xfefe. Tous les caractères peuvent être mappés un à un sur UNICODE2.0.

Troisièmement, pour le fichier programme source .Java placé dans le système d'exploitation, lors de la compilation, nous pouvons spécifier le format d'encodage de son contenu, notamment en utilisant -encoding. Remarque : Si le programme source contient des caractères chinois et que vous utilisez -encoding pour spécifier d'autres caractères d'encodage, une erreur se produira évidemment.

Utilisez -encoding pour spécifier la méthode de codage du fichier source comme GBK ou gb2312. Quel que soit le système sur lequel nous compilons le programme source Java contenant des caractères chinois, il n'y aura aucun problème. Il convertira correctement le chinois en UNICODE et le stockera dans le fichier. fichier de classe.

Ensuite, nous devons être clairs sur le fait que le format de codage de caractères par défaut de presque tous les conteneurs WEB utilise ISO-8859-1 comme valeur par défaut. Dans le même temps, presque tous les navigateurs utilisent UTF-8 par défaut lors de la transmission des paramètres. .

Par conséquent, bien que notre fichier source Java spécifie la méthode de codage correcte à l'entrée et à la sortie, il est toujours traité comme ISO-8859-1 lors de son exécution à l'intérieur du conteneur.

4. Classification des problèmes chinois et leurs solutions optimales recommandées.

Après avoir compris les principes ci-dessus du traitement des fichiers Java, nous pouvons proposer un ensemble de solutions optimales suggérées aux problèmes de caractères chinois. Notre objectif est le suivant : les programmes sources Java contenant des chaînes chinoises ou des traitements chinois que nous éditons dans le système chinois peuvent être migrés vers n'importe quel autre système d'exploitation pour fonctionner correctement après la compilation, ou peuvent être compilés dans d'autres systèmes d'exploitation. Ils peuvent fonctionner correctement. transmet les paramètres chinois et anglais et peut communiquer correctement les chaînes chinoises et anglaises avec la base de données. Notre idée spécifique est de restreindre la méthode de codage pour la rendre correcte à l'entrée et à la sortie du transcodage du programme Java et là où le programme Java effectue une conversion d'entrée et de sortie avec l'utilisateur.

Les solutions spécifiques sont les suivantes :

1. Pour les classes qui s'exécutent directement sur la console

, dans ce cas, nous recommandons que lors de l'écriture d'un programme, si vous avez besoin de recevoir une entrée de l'utilisateur pouvant contenir du chinois ou une sortie pouvant contenir du chinois, le programme doit utiliser Les flux de caractères sont utilisés pour gérer les entrées et les sorties. Plus précisément, les types de flux de nœuds orientés caractères suivants sont appliqués :

Pour les fichiers : FileReader, FileWrieter,

ses types de flux de nœuds orientés octets sont : FileInputStream, FileOutputStream

Pour la mémoire (tableau). ) : CharArrayReader,

CharArrayWriter Les types de flux de nœuds sont : ByteArrayInputStream, ByteArrayOutputStream

Mémoire (string) : StringReader, StringWriter

PipedReader, PipedWriter

Les types de flux de nœuds d'octets sont : PipedInputStream, PipedOutputStream

. des flux de traitement orientés doivent être utilisés. Entrée et sortie :

BufferedWriter, BufferedReader,

ses flux de traitement de type octet sont : BufferedInputeStream, BufferedOutputStream

InputStreamReader, OutputStreamWriter,

DataOutputStreamReader et InputStreamWriter sont utilisés pour convertir le

.

flux d'octets en fonction du jeu de codage de caractères spécifié, tel que :

InputStreamReader in = new InputStreamReader(System.in, "GB2312"); OutputStreamWriter out = new OutputStreamWriter (System.out, "GB2312"); exemple : l'exemple de codage Java suivant peut répondre aux exigences :

//Read.Java
importer Java.io.* ;
cours public Lire
{
public static void main (String[] arguments)
jetteIOException
{
Chaîne chaîne =
"nTest chinois, il s'agit de la chaîne interne codée en dur "+"ntest du caractère anglais";
Chaîne chaîne = "" ;
BufferedReader stdin=
nouveau BufferedReader (nouveau
InputStreamReader (System.in, "gb2312"));
//Définit l'interface d'entrée à coder en chinois
Sortie standard BufferedWriter =
nouveau BufferedWriter (nouveau
OutputStreamWriter (System.out, "gb2312"));
//Définit l'interface de sortie à coder en chinois
stdout.write("Veuillez entrer :");
stdout.flush();
strin = stdin.readLine();
stdout.write("Ceci est la chaîne entrée par l'utilisateur :"+strin);
stdout.write(str);
stdout.flush();
}}

Parallèlement, lors de la compilation du programme, nous utilisons la méthode suivante :

Javac -encoding gb2312 Read.Java

2. Pour les classes EJB et les classes de support qui ne peuvent pas être exécutées directement (comme la classe JavaBean),

car ces classes elles-mêmes sont utilisés par d'autres classes. L'appel n'interagit pas directement avec l'utilisateur, donc pour ce type, notre méthode de traitement recommandée est que le programme interne utilise des flux de caractères pour traiter les chaînes chinoises à l'intérieur du programme (en particulier comme dans la section ci-dessus), et en même temps, dans Lors de la compilation de la classe, utilisez le paramètre -encoding gb2312 pour indiquer que le fichier source est codé au format chinois.

3. Pour la classe Servlet

, nous recommandons la méthode suivante :

Lors de la compilation du programme source de la classe Servlet, utilisez -encoding pour spécifier l'encodage comme GBK ou GB2312, et utilisez le setContentType("text" de l'objet de réponse dans l'encodage part lors de la sortie vers l'utilisateur /html;charset=GBK"); ou gb2312 pour définir le format de codage de sortie. De même, lors de la réception des entrées de l'utilisateur, nous utilisons request.setCharacterEncoding("GB2312"); notre classe de servlet est transplantée uniquement sur le client. Si votre navigateur prend en charge l'affichage chinois, il s'affichera correctement. Voici un exemple correct :

//HelloWorld.Java
paquet bonjour ;
importer Java.io.* ;
importer Javax.servlet.* ;
importer Javax.servlet.http.* ;
classe publique HelloWorld
étend HttpServlet
{
initialisation vide publique()
lance ServletException
{
}
public void doGet
(demande HttpServletRequest,
Réponse HttpServletResponse)
lance IOException, ServletException
{
request.setCharacterEncoding("GB2312");
//Définir le format de codage d'entrée
réponse.setContentType
("texte/html;charset=GB2312");
//Définit le format d'encodage de sortie
PrintWriter out = réponse.getWriter();
//Il est recommandé d'utiliser la sortie PrintWriter
out.println(”<hr>”);
out.println("Bonjour tout le monde !
Ceci est créé par Servlet!Test Chinese!");
out.println(”<hr>”);
}
public void doPost (demande HttpServletRequest,
Réponse HttpServletResponse)
lance IOException, ServletException
{
request.setCharacterEncoding("GB2312");
//Définir le format de codage d'entrée
réponse.setContentType
("texte/html;charset=GB2312");
//Définit le format d'encodage de sortie
Nom de la chaîne = request.getParameter("name");
ID de chaîne = request.getParameter("id");
if(name==null) name="";
if(id==null) id="";
PrintWriter out = réponse.getWriter();
//Il est recommandé d'utiliser la sortie PrintWriter
out.println(”<hr>”);
out.println("La chaîne chinoise que vous avez transmise est : " + nom);
out.println("<hr>L'identifiant que vous avez entré est : " + id);
out.println(”<hr>”);
}
public void détruire()
{
}
}

Veuillez utiliser Javac -encoding gb2312 HelloWorld.Java pour compiler ce programme.

Le programme pour tester cette Servlet est le suivant :

< %@page contentType="text/html;
jeu de caractères = gb2312″%>
<%request.setCharacterEncoding("GB2312");%>
<html><head><titre></titre>
<Langage de script="JavaScript">
fonction Soumettre()
{
//Passez la valeur de la chaîne chinoise au servlet via l'URL
document.base.action =
"./HelloWorld?name=中文";
document.base.method = « POST » ;
document.base.submit();
}
</Script>
</head>

<body bgcolor="#FFFFFF"
text=”#000000″ topmargin=”5″>
<form name="base" méthode =
"POST" cible = "_self">
<input name="id" type="text"
valeur=”” taille=”30″>
<a href = « JavaScript : Soumettre()">
Passer au servlet</a>
</form></body></html>

4.

Afin d'éviter des données tronquées lors du transfert de données entre le programme Java et la base de données, nous recommandons les méthodes optimales suivantes pour les gérer :

1. Le programme Java doit être traité selon la méthode spécifiée par nos soins.

2. Modifiez le format d'encodage pris en charge par la base de données par défaut en GBK ou GB2312.

Par exemple : dans mysql, nous pouvons ajouter l'instruction suivante au fichier de configuration my.ini pour y parvenir :

default-character-set=gbk

dans la zone [mysqld]

et ajoutez :

[client]
default-character-set=gbk

Dans SQL Server2K, nous pouvons définir la langue par défaut de la base de données sur le chinois simplifié pour atteindre cet objectif.

5. Pour le code JSP,

puisque JSP est compilé dynamiquement par le conteneur WEB au moment de l'exécution, si nous ne spécifions pas le format d'encodage du fichier source JSP, le compilateur JSP obtiendra la valeur file.encoding du système d'exploitation du serveur pour compiler le Fichier JSP. Oui, il est très probable que cela pose des problèmes lors de la transplantation. Par exemple, un fichier jsp qui peut fonctionner correctement sous Windows 2000 en chinois ne fonctionnera pas sous Linux anglais, même si les clients sont les mêmes. le fichier JSP lors de sa compilation. Causé par différents encodages des systèmes d'exploitation (file.encoding en chinois wink est différent de file.encoding en anglais Linux, et file.encoding en anglais Linux ne prend pas en charge le chinois, il y aura donc des problèmes avec le fichier. classe JSP compilée).

La plupart des problèmes évoqués sur Internet sont de tels problèmes, principalement parce que le fichier JSP ne peut pas s'afficher correctement lorsqu'il est transplanté sur la plate-forme. Pour ce type de problème, nous comprenons le principe de conversion du codage du programme en Java, et il est beaucoup plus facile de le faire. résolvez-le. Nos solutions suggérées sont les suivantes :

1. Nous devons nous assurer que le JSP est généré en codage chinois lors de sa sortie vers le client, c'est-à-dire que, quoi qu'il arrive, nous ajoutons d'abord la ligne suivante à notre code source JSP :

< %@page contentType =" texte/html ;
charset=gb2312″%>

2. Afin de permettre à JSP d'obtenir correctement les paramètres entrants, nous ajoutons la phrase suivante à l'en-tête du fichier source JSP :

<%request.setCharacterEncoding(”GB2312″);
%>

3. Pour que le compilateur JSP décode correctement nos fichiers JSP contenant des caractères chinois, nous devons spécifier le format d'encodage de nos fichiers source JSP dans les fichiers source JSP.

du

fichier source JSP.

Ou < % @ page pageencoding = "gbk"%>

Il s'agit d'une instruction nouvellement ajoutée dans JSP Spécification 2.0.

pour

résoudre les problèmes chinois dans les fichiers JSP.

< % @ page pageencoding = ”gb2312 ″%>
< % @ page contenttype = "text / html;
charse = gb2312 ″%>
<% request.SetcharAtterencoding ("GB2312");
%>
<%
String Action = request.getParameter ("Action");
String name = "";
String str = "";
if (action! = null && action.equals ("envoyé"))
{
name = request.getParameter ("name");
str = request.getParameter ("str");
}
%>
<html>
<tête>
<titre></titre>
<Script linguisse = "javascript">
fonction soumed ()
{
document.base.action =
"? Action = Send & Str = Chinois entrant";
document.base.method = «post»;
document.base.submit ();
}
</Script>
</tête>
<corps bgcolor = ”# ffffff”
text = ”# 000000 ″ topmargin =” 5 ″>
<form name = "base" méthode =
«Post» cible = ”_ self»>
<input type = ”text” name = ”name”
valeur = ”” size = ”30 ″>
<a href = “javascript: soumed ()"> soumettre </a>
</form>
<%
if (action! = null && action.equals ("envoyé"))
{
out.println ("<br> Les caractères que vous avez entrés sont:" + nom);
out.println ("<br> Les personnages que vous avez transmis par l'URL sont:" + str);
}
%>
</corps>
</html>