Solución de problemas chinos jsp (versión completa)

=====================================
Es muy común que aparezcan caracteres confusos al desarrollar aplicaciones Java. Después de todo, Unicode no se usa ampliamente ahora en un sistema que usa gb2312 (incluido gbk simplificado y big5 tradicional),

es el requisito más básico para implementar correctamente la visualización en chino. almacenamiento de base de datos.

===============================
1. Primero, el desarrollador debe comprender por qué encuentra código confuso y qué tipo de código confuso encuentra (símbolos sin sentido, una cadena de signos de interrogación u otra cosa).
Los principiantes suelen perderse cuando se encuentran con un montón de caracteres desordenados. La reacción más directa es abrir Google y buscar "chino java" (esta cadena se consulta con frecuencia en los motores de búsqueda)

y luego mirar los caracteres de otras personas uno por uno. uno. No hay nada de malo en hacer esto, pero es difícil lograr el objetivo por las razones que se mencionan a continuación.
En resumen, hay muchas razones para los caracteres confusos y las soluciones son completamente diferentes. Para resolver el problema, primero debes analizar tu propio "contexto".

=============================
2. Específicamente, qué información se necesita para determinar la fuente del código confuso en el proyecto.
a. El sistema operativo utilizado por el desarrollador.
b, el nombre y la versión del contenedor j2ee
c, nombre de la base de datos, versión (versión exacta) y versión del controlador jdbc
d. Hay código fuente confuso (por ejemplo, proviene del sistema o está en una página jsp. Si está en un jsp, la declaración del encabezado también es muy importante)

==========. === ===============================================
3. Cómo analizar inicialmente las causas de los caracteres confusos.
Con la información anterior, básicamente puedes publicar en busca de ayuda. Creo que si la publicas en foros como Javaworld, los expertos pronto encontrarán soluciones efectivas para ti.
Por supuesto, no siempre puedes confiar en publicar para obtener ayuda, pero también debes intentar resolver el problema tú mismo. ¿Cómo empezar?
a. Analice qué codificación es su "código confuso". En realidad, esto no es difícil, por ejemplo.
System.out.println(testString);
Hay código confuso en este párrafo, por lo que también puedes utilizar el método exhaustivo para adivinar su formato de codificación real.
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"));
Espere, el código anterior significa usar el formato de codificación especificado para leer el "código confuso" de testString y convertirlo a gb2312 (aquí solo se usa chino como ejemplo)
Luego verás qué resultado convertido está bien, eso es todo. . .

b. Si puede obtener el chino correcto siguiendo los pasos anteriores, significa que sus datos definitivamente están allí, pero simplemente no se muestran correctamente en la interfaz. Luego, el segundo paso es corregir la parte de la vista

. Lo que normalmente hay que comprobar es si se ha seleccionado la codificación de página correcta en el jsp.

Me gustaría señalar algo que muchas personas han malinterpretado, es decir, la directiva <%@ page contentType="text/html; charset=GB2312″ %> y <META http-equiv=Content-Type

content="text /html; charset= gb2312″>La diferencia entre los dos. Por lo general, cuando muchos artículos en Internet mencionan problemas chinos, dicen que elegir almacenamiento Unicode o gb2312 en la base de datos se puede resolver

usando

Pero creo que esta afirmación es muy irresponsable y me hizo pasar mucho tiempo deprimido por códigos confusos que no existían en primer lugar. De hecho, la función de la página

es proporcionar un método de codificación para que Java "lea" la cadena en la expresión durante el proceso de compilación de JSP en HTML (algo similar a la función de la tercera declaración anterior), y la

función de meta es bien conocido Proporciona opciones de codificación para los navegadores IE, que se utilizan para "mostrar" los datos finales. Pero no he visto a nadie recordarme esto. Siempre he usado la página como meta,

lo que resultó en que el comando de página leyera los datos que originalmente eran iso-8859 como gb2312, por lo que estaban confusos, por lo que agregué una codificación. Función de conversión para convertir todos los datos de cadena. Todos cambiaron de iso8859 a gb2312 (

por qué

==================================================== ==============
4. ¿Qué codificación es mejor para la base de datos?
Las bases de datos más populares actualmente incluyen SQL Server, MySQL, Oracle, DB2, etc. Entre ellas, MySQL es el líder entre las bases de datos gratuitas. Su rendimiento y funciones son relativamente convenientes de instalar y configurar, y el controlador

correspondiente

. Tomemos mysql como ejemplo.

Personalmente recomiendo usar la codificación predeterminada de mysql para el almacenamiento, que es iso-8859-1 (correspondiente a latin-1 en las opciones de mysql). Hay varias razones principales: primero, iso-8859-1 tiene un buen soporte para

el chino

productos de base de datos específicos proporcionan soporte

de codificación múltiple

Por ejemplo, en productos anteriores a MySQL 4.0, muchas soluciones chinas usan el campo CharacterEncoding en la conexión para configurar la codificación, como gb2312 o algo así. Esto está bien

porque los datos originales están codificados en ISO8859_1 y el controlador jdbc usará el especificado. en la URL se utiliza el juego de caracteres para la codificación y resultSet.getString(*) extrae la

cadena codificada. De esta forma, podrá obtener directamente los datos de gb2312.

Sin embargo, el lanzamiento de mysql 4.1 ha traído muchos problemas a muchos dbadmins, porque mysql 4.1 admite un juego de caracteres a nivel de columna para cada tabla y columna.

Si no se especifica, será ISO8895_1, por lo que después de jdbc se elimina. datos, se basará en la columna. El juego de caracteres se utiliza para codificar, en lugar de utilizar un parámetro global para obtener todos los datos.

Esto también muestra desde otro aspecto que el problema de los caracteres confusos es realmente complicado y tiene demasiadas razones. Solo proporciono algunas soluciones a la situación real que encontré. Si hay algún

error

Sólo para uso interno.
Cualquier pregunta, consulte [email protected]
==================================================== ===============

Finalmente encontré la solución más perfecta al problema chino. . . Gracias al autor de este artículo en línea. . .
Mi artículo original se basa en mi propia experiencia. Aunque no pasó nada malo, nunca se encontró la causa raíz del problema. Después de leer este artículo, de repente me di cuenta, jaja,
—————————————————————————————————————————————————— ——————-

Dado que el problema chino en la programación Java es un problema común, después de leer muchas soluciones a los problemas chinos de Java, combinado con la práctica de programación del autor, descubrí que muchos de los métodos discutidos en el pasado no pueden explicar claramente el problema y resolver el problema, especialmente el problema chino cuando es multiplataforma.
Por eso le di este artículo, que incluye mi análisis y soluciones sugeridas a los problemas de chino en las clases, Servelets, JSP y EJB que se ejecutan en la consola. Espero que puedas darme algún consejo.

Resumen: Este artículo analiza en profundidad el proceso de codificación/decodificación de archivos fuente Java mediante el compilador Java y archivos de clase mediante JVM en la programación Java. Finalmente, se revela la causa raíz de los problemas chinos en la programación Java. dado El método óptimo propuesto para resolver problemas de Java chino.

1. La fuente del problema chino

. La codificación admitida por el sistema operativo original de la computadora era la codificación de caracteres de un solo byte. Por lo tanto, todos los programas de procesamiento en la computadora se procesaron inicialmente en inglés con codificación de un solo byte.

Con el desarrollo de las computadoras, para adaptarse a los idiomas de otras naciones del mundo (incluidos, por supuesto, nuestros caracteres chinos), se ha propuesto la codificación UNICODE, que utiliza codificación de doble byte y es compatible con los caracteres ingleses. y codificaciones de caracteres de doble byte de otras naciones. Por lo tanto, actualmente, la mayoría del software internacional utiliza la codificación UNICODE internamente. Cuando el software se está ejecutando, obtiene el formato de codificación admitido de forma predeterminada por el sistema de soporte local (la mayoría de las veces, el sistema operativo). ), y luego convierte el UNICODE dentro del software al formato de codificación admitido por el sistema local de forma predeterminada. Se muestra el formato.

Este es el caso de JDK y JVM de Java. El JDK del que estoy hablando aquí se refiere a la versión internacional de JDK. La mayoría de nuestros programadores utilizan la versión JDK internacionalizada. Nuestros caracteres chinos son un lenguaje de codificación de doble byte Para permitir que las computadoras procesen chino, hemos desarrollado nuestros propios estándares, como gb2312, GBK y GBK2K, para satisfacer las necesidades del procesamiento informático.

Por lo tanto, para adaptarse a nuestras necesidades de procesamiento del chino, la mayoría de los sistemas operativos cuentan con sistemas operativos chinos personalizados que utilizan formatos de codificación GBK y GB2312 para mostrar correctamente nuestros caracteres chinos. Por ejemplo: Windows chino utiliza la codificación GBK para mostrar de forma predeterminada. Al guardar archivos en Windows 2000 chino, el formato de codificación utilizado de forma predeterminada para guardar archivos también es GBK. Es decir, la codificación interna de todos los archivos guardados en Windows 2000 chino utiliza GBK. codificación de forma predeterminada Nota: GBK se amplía sobre la base de GB2312.

Dado que el lenguaje Java usa codificación UNICODE internamente, cuando el programa Java se está ejecutando, existe el problema de convertir la entrada y salida de la codificación UNICODE y el formato de codificación correspondiente admitido por el sistema operativo y el navegador. Este proceso de conversión tiene una serie de pasos. Si hay un error en cualquiera de los pasos, los caracteres chinos mostrados serán confusos. Este es nuestro problema común en chino Java.

Al mismo tiempo, Java es un lenguaje de programación multiplataforma, lo que significa que los programas que escribimos no solo pueden ejecutarse en Windows chino, sino también en Linux chino y otros sistemas. También es necesario ejecutarlo en inglés y otros sistemas (. A menudo vemos a alguien trasplantar un programa Java escrito en Windows 2000 en chino para ejecutarlo en Linux en inglés). Esta operación de trasplante también traerá problemas a China.

Además, algunas personas utilizan sistemas operativos y navegadores en inglés, como IE, para ejecutar programas con caracteres chinos y navegar por páginas web en chino. Ellos mismos no admiten chino y también causarán problemas con el idioma chino.

Casi todos los navegadores pasan parámetros en formato de codificación UTF-8 de forma predeterminada en lugar de codificación china. Por lo tanto, también habrá problemas al pasar parámetros chinos, lo que provocará caracteres confusos.

En resumen, los aspectos anteriores son las principales fuentes de problemas chinos en Java. A los problemas causados ​​por el programa que no se ejecuta correctamente por las razones anteriores los llamamos: problemas chinos de Java.

2. Proceso detallado de conversión de codificación Java

Nuestros programas Java comunes incluyen las siguientes categorías:

*Clases que se ejecutan directamente en la consola (incluidas las clases de interfaz visual)

*Clases de código JSP (Nota: JSP es una variante de la clase Servlets)

*Servelets. clase

* clase EJB

* otras clases de soporte que no se pueden ejecutar directamente.

Estos archivos de clase pueden contener cadenas chinas y, a menudo, usamos los primeros tres tipos de programas Java para interactuar directamente con los usuarios para los caracteres de salida y entrada, como por ejemplo: usamos JSP. y El Servlet obtiene los caracteres enviados por el cliente, y estos caracteres también incluyen caracteres chinos. Independientemente del papel de estas clases de Java, el ciclo de vida de estos programas Java es el siguiente:

* Los programadores eligen un software de edición adecuado en un determinado sistema operativo para implementar el código fuente del programa y guardarlo en el sistema operativo con la extensión .Java. , por ejemplo, usamos el Bloc de notas para editar un programa fuente Java en Windows 2000 chino.

*Los programadores usan Javac.exe en JDK para compilar estos códigos fuente para formar clases .class (los archivos JSP son compilados por el contenedor que llama a JDK).

* Ejecute estas clases directamente o impleméntelas en el contenedor WEB para ejecutar y generar los resultados.

Entonces, durante estos procesos, ¿cómo codifican, decodifican y ejecutan JDK y JVM estos archivos?

Aquí, tomamos el sistema operativo chino Windows 2000 como ejemplo para ilustrar cómo se codifican y decodifican las clases Java.

El primer paso es utilizar un software de edición como el Bloc de notas para escribir un archivo de programa fuente Java (incluidos los cinco tipos de programas Java anteriores) en Windows 2000 chino. Al guardar el archivo de programa, el archivo de programa utiliza el formato de codificación GBK admitido por sistema operativo de forma predeterminada (compatible con el sistema operativo de forma predeterminada, el formato es formato file.encoding) formando un archivo .Java, es decir, antes de compilar el programa Java, nuestro archivo de programa fuente Java se guarda en file.encoding. formato de codificación admitido por el sistema operativo de forma predeterminada. En el programa fuente de Java Contiene caracteres de información chinos y códigos de programa en inglés para ver el parámetro file.encoding del sistema, puede utilizar el siguiente código:

clase pública ShowSystemDefaultEncoding;
{
principal vacío estático público (String [] argumentos)
{
Codificación de cadena =
System.getProperty("archivo.codificación");
System.out.println(codificación);
}
}

En el segundo paso, usamos el archivo Javac.exe de JDK para compilar nuestro programa fuente Java. Dado que JDK es una versión internacional, al compilar, si no usamos el parámetro -encoding para especificar el formato de codificación de nuestra fuente Java. programa, luego Javac.exe primero obtiene el formato de codificación utilizado por nuestro sistema operativo de forma predeterminada. Es decir, al compilar un programa Java, si no especificamos el formato de codificación del archivo del programa fuente, JDK primero obtiene el parámetro file.encoding. del sistema operativo (que guarda el formato de codificación predeterminado, como Windows2000, su valor es GBK), y luego JDK convierte nuestro programa fuente Java del formato de codificación file.encoding al formato UNICODE predeterminado interno de Java y lo coloca en la memoria.

Luego, Javac compila el archivo en formato Unicode convertido en un archivo de clase .class. En este momento, el archivo .class está codificado en UNICODE y se coloca temporalmente en la memoria. Luego, JDK compila la clase compilada en codificación UNICODE. se guarda en nuestro sistema operativo para formar el archivo .class que vemos.

Para nosotros, el archivo .class que finalmente obtuvimos es un archivo de clase cuyo contenido se guarda en formato de codificación UNICODE. Contiene la cadena china en nuestro programa fuente, pero en este momento se ha convertido al formato UNICODE a través del formato file.encoding. .

En este paso, el archivo del programa fuente JSP es diferente. Para JSP, el proceso es el siguiente: es decir, el contenedor WEB llama al compilador JSP. El compilador JSP primero verifica si el formato de codificación del archivo está configurado en el archivo JSP. no hay ningún formato de codificación de archivo en el archivo JSP. Para establecer el formato de codificación del archivo JSP, el compilador JSP llama al JDK para convertir primero el archivo JSP en una clase de servlet temporal utilizando el formato de codificación de caracteres predeterminado de la JVM (es decir, el formato predeterminado file.encoding del sistema operativo donde se encuentra el contenedor WEB), y luego se compila en una clase de formato UNICODE y se guarda en una carpeta temporal.

Por ejemplo: en Windows 2000 chino, el contenedor WEB convierte el archivo JSP del formato de codificación GBK al formato UNICODE y luego lo compila en una clase de servlet guardada temporalmente para responder a la solicitud del usuario.

El tercer paso es ejecutar la clase compilada en el segundo paso, que se divide en tres situaciones:
A. Clases que se ejecutan directamente en la consola

B. Clases EJB y clases de soporte que no se pueden ejecutar directamente (como las clases JavaBean)

C. Código JSP y clases Servlet

D. Entre programas Java y bases de datos

Veamos estas cuatro situaciones a continuación.

R. En el caso de una clase que se ejecuta directamente en la consola

, ejecutar esta clase primero requiere soporte JVM, es decir, JRE debe estar instalado en el sistema operativo. El proceso de ejecución es el siguiente: Primero, Java inicia la JVM. En este momento, la JVM lee el archivo de clase guardado en el sistema operativo y lee el contenido en la memoria. En este momento, la memoria es una clase en formato UNICODE. y luego la JVM lo ejecuta, si en este momento esta clase necesita recibir la entrada del usuario, la clase utilizará el formato de codificación file.encoding de forma predeterminada para codificar la cadena ingresada por el usuario y convertirla a Unicode y guardarla en la memoria. (El usuario puede configurar el formato de codificación del flujo de entrada).

Después de ejecutar el programa, la cadena generada (codificada en UNICODE) se devuelve a la JVM. Finalmente, el JRE convierte la cadena al formato file.encoding (el usuario puede configurar el formato de codificación del flujo de salida) y la pasa al sistema operativo. interfaz de visualización y lo envía a la interfaz. Cada uno de los pasos de conversión anteriores requiere una conversión correcta del formato de codificación para que al final no aparezcan caracteres confusos. B. Clases EJB y clases de soporte que no se pueden ejecutar directamente (como las clases JavaBean)

. Debido a que las clases EJB y las clases de soporte no se pueden ejecutar directamente, generalmente no interactúan directamente con los usuarios para la entrada y salida. para entrada y salida, por lo que después de compilarse en el segundo paso, forman una clase cuyo contenido está codificado UNICODE y se guardan en el sistema operativo en el futuro, siempre que no haya interacción entre ella y otras clases. perdido durante el proceso de paso de parámetros, se ejecutará correctamente.

C.

Después del segundo paso del código JSP y la clase de Servlet, el archivo JSP también se convierte en un archivo de clase de Servlets, pero no existe en el directorio de clases como los Servlets estándar. Existe en el directorio temporal del contenedor WEB. , por lo que en este paso también lo veremos como servlets.

Para los servlets, cuando el cliente lo solicita, el contenedor WEB llama a su JVM para ejecutar el Servlet. Primero, la JVM lee la clase de Servlet del sistema y la carga en la memoria. En la memoria está codificado el código de la clase de Servlet. UNICODE Luego, la JVM ejecuta la clase de Servlet en la memoria. Si el Servlet se está ejecutando, debe aceptar caracteres del cliente, como los valores ingresados ​​en el formulario y los valores pasados ​​en la URL. tiempo, si el programa no está configurado para aceptar Si el formato de codificación se usa como parámetro, el contenedor WEB usará el formato de codificación ISO-8859-1 de forma predeterminada para aceptar el valor entrante y convertirlo al formato UNICODE en la JVM y guárdelo en la memoria del contenedor WEB.

Después de ejecutar el servlet, genera una salida y la cadena de salida está en formato UNICODE. Luego, el contenedor envía directamente la cadena en formato UNICODE (como la sintaxis HTML, la cadena de salida del usuario, etc.) generada por la ejecución del servlet al cliente. navegador y lo envía a Si el usuario especifica el formato de codificación para la salida al enviarlo en este momento, se enviará al navegador en el formato de codificación especificado. Si no se especifica, se enviará al navegador del cliente en ISO-8859-. 1 codificación por defecto.

D. Entre el programa Java y la base de datos

Para casi todos los controladores JDBC de bases de datos, el formato de codificación predeterminado para transferir datos entre el programa Java y la base de datos es ISO-8859-1. Por lo tanto, nuestro programa transmite datos a la base de datos cuando almacena datos que contienen chino. En el programa, JDBC primero convierte los datos en el formato de codificación UNICODE dentro del programa al formato ISO-8859-1 y luego los pasa a la base de datos. Cuando la base de datos guarda los datos, el valor predeterminado es guardar ISO-8859-1. Por eso los datos chinos que a menudo leemos en la base de datos están confusos.

3. Varios principios que deben entenderse al analizar problemas comunes de Java chino

. Primero, después del análisis detallado anterior, podemos ver claramente que en el ciclo de vida de cualquier programa Java, el proceso clave de conversión de codificación es: compilar inicialmente en una clase. file La transcodificación y el proceso de transcodificación final enviado al usuario.

En segundo lugar, debemos entender que los siguientes formatos de codificación comúnmente utilizados y admitidos por Java en el momento de la compilación son:

*ISO-8859-1, 8 bits, igual que 8859_1, ISO-8859-1, ISO_8859_1 y otras codificaciones

*Cp1252, estadounidense Codificación en inglés, igual que la codificación estándar ANSI

*UTF-8, igual que la codificación Unicode

*GB2312, igual que gb2312-80, gb2312-1980 y otras codificaciones

*GBK, igual que MS936, es una expansión de gb2312 y otras codificaciones, como coreano, japonés, chino tradicional, etc. Al mismo tiempo, debemos prestar atención a la relación de compatibilidad entre estas codificaciones de la siguiente manera:

las codificaciones Unicode y UTF-8 tienen una correspondencia uno a uno. GB2312 puede considerarse un subconjunto de GBK, es decir, la codificación GBK se expande en gb2312. Al mismo tiempo, la codificación GBK contiene 20902 caracteres chinos y el rango de codificación es: 0 × 8140-0xfefe. Todos los caracteres se pueden asignar a UNICODE2.0 uno a uno.

En tercer lugar, para el archivo de programa fuente .Java colocado en el sistema operativo, durante la compilación, podemos especificar el formato de codificación de su contenido, específicamente usando -codificación. Nota: Si el programa fuente contiene caracteres chinos y utiliza -encoding para especificar otros caracteres de codificación, obviamente se producirá un error.

Utilice -encoding para especificar el método de codificación del archivo fuente como GBK o gb2312. No importa en qué sistema compilamos el programa fuente Java que contiene caracteres chinos, convertirá correctamente el chino a UNICODE y lo almacenará en el. archivo de clase.

Luego, debemos tener claro que el formato de codificación de caracteres predeterminado de casi todos los contenedores WEB usa ISO-8859-1 como valor predeterminado. Al mismo tiempo, casi todos los navegadores usan UTF-8 de manera predeterminada al pasar parámetros. .

Por lo tanto, aunque nuestro archivo fuente Java especifica el método de codificación correcto en la entrada y salida, aún se procesa como ISO-8859-1 cuando se ejecuta dentro del contenedor.

4. Clasificación de problemas chinos y sus soluciones óptimas recomendadas.

Después de comprender los principios anteriores del procesamiento de archivos Java, podemos proponer un conjunto de soluciones óptimas sugeridas para los problemas de caracteres chinos. Nuestro objetivo es: los programas fuente de Java que contienen cadenas chinas o procesamiento chino que editamos en el sistema chino se pueden migrar a cualquier otro sistema operativo para que se ejecuten correctamente después de la compilación, o se pueden compilar en otros sistemas operativos. pasa parámetros en chino e inglés y puede comunicar correctamente cadenas en chino e inglés con la base de datos. Nuestra idea específica es restringir el método de codificación para que sea correcto en la entrada y salida de la transcodificación del programa Java y donde el programa Java tiene conversión de entrada y salida con el usuario.

Las soluciones específicas son las siguientes:

1. Para las clases que se ejecutan directamente en la consola

, en este caso, recomendamos que al escribir un programa, si necesita recibir entradas del usuario que puedan contener chino o resultados que puedan contener chino, el programa debe usar Los flujos de caracteres se utilizan para manejar la entrada y la salida. Específicamente, se aplican los siguientes tipos de flujos de nodos orientados a caracteres:

Para archivos: FileReader, FileWrieter,

sus tipos de flujos de nodos orientados a bytes son: FileInputStream, FileOutputStream

Para memoria (matriz). ): CharArrayReader,

CharArrayWriter Los tipos de flujo de nodos son: ByteArrayInputStream, ByteArrayOutputStream.

Memoria

cadena

): StringReader, StringWriter

Tuberías: PipedReader, PipedWriter.

Se deben utilizar flujos de procesamiento orientados a entrada y salida:

BufferedWriter, BufferedReader,

sus flujos de procesamiento de tipo byte son: BufferedInputeStream, BufferedOutputStream

InputStreamReader, OutputStreamWriter,

sus flujos de procesamiento de tipo byte son: DataInputStream,

DataOutputStreamReader y InputStreamWriter

flujo de bytes de acuerdo con el conjunto de codificación de caracteres especificado. Convierta a un flujo de caracteres, como:

InputStreamReader in = new InputStreamReader(System.in, "GB2312"); Ejemplo: el siguiente ejemplo de codificación Java puede cumplir los requisitos:

//Read.Java
importar Java.io.*;
lectura de clase pública
{
principal vacío estático público (String [] argumentos)
lanzaIOException
{
cadena cadena =
"nPrueba china, esta es la cadena interna codificada "+"ntest carácter inglés";
Cadena cadena = "";
Entrada estándar de BufferedReader =
nuevo BufferedReader (nuevo
InputStreamReader(System.in,”gb2312″));
//Configura la interfaz de entrada para que se codifique en chino
salida estándar de BufferedWriter =
nuevo BufferedWriter (nuevo
OutputStreamWriter(System.out,”gb2312″));
//Configura la interfaz de salida para que se codifique en chino
stdout.write("Ingrese:");
salida estándar.flush();
cadena = stdin.readLine();
stdout.write("Esta es la cadena ingresada por el usuario:"+strin);
stdout.write(cadena);
salida estándar.flush();
}}

Al mismo tiempo, al compilar el programa, utilizamos el siguiente método:

Javac -encoding gb2312 Read.Java

2. Para clases EJB y clases de soporte que no se pueden ejecutar directamente (como la clase JavaBean),

porque estas clases en sí mismas son utilizados por otras clases La llamada no interactúa directamente con el usuario, por lo que para este tipo, nuestro método de procesamiento recomendado es que el programa interno debe usar flujos de caracteres para procesar las cadenas chinas dentro del programa (específicamente como en la sección anterior), y al mismo tiempo, al compilar la clase, use el parámetro -encoding gb2312 para indicar que el archivo fuente está codificado en formato chino.

3. Para la clase Servlet

, recomendamos el siguiente método:

al compilar el programa fuente de la clase Servlet, use -encoding para especificar la codificación como GBK o GB2312 y use setContentType ("texto" del objeto de respuesta en la codificación parte al enviar al usuario /html;charset=GBK”); o gb2312 para configurar el formato de codificación de salida. De manera similar, cuando recibimos la entrada del usuario, usamos request.setCharacterEncoding(”GB2312″); Nuestra clase de servlet se trasplanta solo al cliente. Si su navegador admite la visualización en chino, se mostrará correctamente. Aquí hay un ejemplo correcto:

//HelloWorld.Java
paquete hola;
importar Java.io.*;
importar Javax.servlet.*;
importar Javax.servlet.http.*;
clase pública Hola Mundo
extiende HttpServlet
{
inicio público vacío()
lanza ServletException
{
}
vacío público doGet
(Solicitud HttpServletRequest,
respuesta HttpServletResponse)
lanza IOException, ServletException
{
request.setCharacterEncoding("GB2312");
//Establecer formato de codificación de entrada
respuesta.setContentType
("texto/html;charset=GB2312");
//Establece el formato de codificación de salida
PrintWriter fuera = respuesta.getWriter();
//Se recomienda utilizar la salida PrintWriter
out.println(”<hora>”);
out.println("¡Hola mundo!
¡Esto es creado por Servlet! ¡Prueba chino!");
out.println(”<hora>”);
}
public void doPost (solicitud HttpServletRequest,
respuesta HttpServletResponse)
lanza IOException, ServletException
{
request.setCharacterEncoding("GB2312");
//Establecer formato de codificación de entrada
respuesta.setContentType
("texto/html;charset=GB2312");
//Establece el formato de codificación de salida
Nombre de cadena = request.getParameter("nombre");
ID de cadena = request.getParameter("id");
if(nombre==nulo) nombre="";
if(id==nulo) id="";
PrintWriter fuera = respuesta.getWriter();
//Se recomienda utilizar la salida PrintWriter
out.println(”<hora>”);
out.println("La cadena china que ingresaste es: " + nombre);
out.println("<hr>La identificación que ingresó es: " + id);
out.println(”<hora>”);
}
destrucción de vacío público ()
{
}
}

Utilice Javac -encoding gb2312 HelloWorld.Java para compilar este programa.

El programa para probar este Servlet es el siguiente:

< %@page contentType="text/html;
juego de caracteres=gb2312″%>
<%request.setCharacterEncoding("GB2312");%>
<html><cabeza><título></título>
<Lenguaje de secuencia de comandos="JavaScript">
función Enviar()
{
//Pasamos el valor de la cadena china al servlet a través de la URL
documento.base.accion =
"./HelloWorld?name=中文";
documento.base.method = “POST”;
documento.base.submit();
}
</script>
</head>

<body bgcolor=”#FFFFFF”
texto=”#000000″ topmargin=”5″>
<formulario nombre="base" método =
“POST” objetivo=”_self”>
<nombre de entrada="id" tipo="texto"
valor =”” tamaño =”30″>
<a href = “JavaScript:Enviar()">
Pasar a Servlet</a>
</form></body></html>

4.

Para evitar datos confusos en la transferencia de datos entre el programa Java y la base de datos, recomendamos los siguientes métodos óptimos para manejarlo:

1. El programa Java debe procesarse de acuerdo con el método especificado por nosotros.

2. Cambie el formato de codificación admitido por la base de datos de forma predeterminada a GBK o GB2312.

Por ejemplo: en mysql, podemos agregar la siguiente declaración al archivo de configuración my.ini para lograr esto:

default-character-set=gbk

en el área [mysqld]

y agregue:

[cliente]
default-character-set=gbk

En SQL Server2K, podemos configurar el idioma predeterminado de la base de datos en chino simplificado para lograr el propósito.

5. Para el código JSP,

dado que JSP es compilado dinámicamente por el contenedor WEB en tiempo de ejecución, si no especificamos el formato de codificación del archivo fuente JSP, el compilador JSP obtendrá el valor file.encoding del sistema operativo del servidor para compilar el Archivo JSP Sí, lo más probable es que cause problemas al trasplantar. Por ejemplo, un archivo jsp que puede ejecutarse bien en Windows 2000 en chino no funcionará en Linux en inglés, aunque los clientes sean los mismos. el archivo JSP al compilarlo Causado por diferentes codificaciones de los sistemas operativos (file.encoding en chino wink es diferente de file.encoding en inglés Linux, y file.encoding en inglés Linux no es compatible con el chino, por lo que habrá problemas con el. clase JSP compilada).

La mayoría de los problemas discutidos en Internet son problemas de este tipo, principalmente porque el archivo JSP no se puede mostrar correctamente cuando se trasplanta a la plataforma. Para este tipo de problema, entendemos el principio de conversión de codificación de programas en Java y es mucho más fácil. resolverlo. Nuestras soluciones sugeridas son las siguientes:

1. Debemos asegurarnos de que el JSP se genere en codificación china cuando se envíe al cliente, es decir, pase lo que pase, primero agregamos la siguiente línea a nuestro código fuente JSP:

< %@page contentType =”texto/html;
charset=gb2312″%>

2. Para permitir que JSP obtenga correctamente los parámetros entrantes, agregamos la siguiente oración al encabezado del archivo fuente JSP:

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

3. Para que el compilador JSP decodifique correctamente nuestros archivos JSP que contienen caracteres chinos, necesitamos especificar el formato de codificación de nuestros archivos de origen JSP en los archivos de origen JSP.

de

origen JSP.

O < %@página PageEncoding = "GBK" %>

Esta es una instrucción recientemente agregada en la especificación JSP 2.0.

Recomendamos usar este método para resolver los problemas chinos en los archivos JSP

.
< %@página PageEncoding = ”GB2312 ″ %>
< %@página contentType = "text/html;
Charset = GB2312 ″%>
<%request.setcharacterEncoding ("GB2312");
%>
<%
String Action = request.getParameter ("Acción");
Name de cadena = "";
Cadena str = "";
if (Action! = Null && Action.equals ("enviado"))
{
name = request.getParameter ("nombre");
str = request.getParameter ("str");
}
%>
<html>
<cabeza>
<título></título>
<Script language = "javaScript">
función enviar ()
{
document.base.action =
"? Action = enviado y str = chino entrante";
document.base.method = "post";
document.base.submit ();
}
</script>
</cabeza>
<Body bgcolor = ”#ffffff"
text = ”#000000 ″ topmargin =” 5 ″>
<form de nombre = "base" método =
"Post" Target = "_ Self">
<input type = "text" name = "nombre"
valor = ”” size = ”30 ″>
<a href = "javascript: enviar ()"> enviar </a>
</formulario>
<%
if (Action! = Null && Action.equals ("enviado"))
{
out.println ("<br> Los caracteres que ingresaste son:"+nombre);
out.println ("<br> Los personajes en los que pasaste a través de la URL son:"+str);
}
%>
</cuerpo>
</html>