¿Cómo resolver el problema de los caracteres chinos confusos al ejecutar Java en doc?

La siguiente es una reimpresión: los problemas chinos de Java siempre han preocupado a muchos principiantes. Si comprendemos los principios de los problemas chinos en el sistema Java, podemos encontrar soluciones fundamentales a los problemas chinos. La solución más antigua es utilizar la conversión de código de bytes de cadena. El problema con esta solución es que es inconveniente. Necesitamos destruir la encapsulación del objeto y realizar la conversión de código de bytes. Otra forma es codificar el contenedor J2EE. Si el sistema de aplicación J2EE se separa del contenedor, se producirá un código confuso y la configuración del contenedor especificada no cumplirá con el principio de separación de aplicaciones y contenedores J2EE. En las operaciones internas de Java, todas las cadenas involucradas se convertirán a codificación UTF-8 para su operación. Entonces, ¿qué conjunto de caracteres tiene una cadena antes de que Java la convierta? Java siempre determina la codificación inicial de una cadena en función del conjunto de caracteres de codificación predeterminado del sistema operativo, y la entrada y salida del sistema Java adoptan la codificación predeterminada del sistema operativo. Por lo tanto, si los conjuntos de caracteres codificados de entrada, salida y sistema operativo del sistema Java se pueden unificar, el sistema Java podrá procesar y mostrar correctamente los caracteres chinos. Este es un principio para tratar con caracteres chinos en el sistema Java, pero en proyectos reales, es difícil comprender y controlar correctamente las partes de entrada y salida del sistema Java. En J2EE, debido a la participación de navegadores y bases de datos externos, el problema de los caracteres chinos confusos es muy destacado. Las aplicaciones J2EE se ejecutan en contenedores J2EE. En este sistema, hay muchas formas de entrada: una se empaqueta en una solicitud a través de un formulario de página y se envía al servidor, la segunda se lee a través de la base de datos y la tercera entrada es más complicada, JSP es el primero El primer tiempo de ejecución; Siempre se compila en un servlet y JSP a menudo contiene caracteres chinos. Al compilar usando javac, Java utilizará la codificación predeterminada del sistema operativo como codificación inicial. A menos que se especifique lo contrario, el juego de caracteres predeterminado se puede especificar en Jbuilder/eclipse. Hay varios canales de salida: el primero es la salida de la página JSP. Dado que la página JSP se ha compilado en un servlet, al generar, la codificación de salida se seleccionará de acuerdo con la codificación predeterminada del sistema operativo, a menos que se especifique el método de codificación de salida, la ruta de salida es la base de datos y la cadena se genera; a la base de datos. Desde este punto de vista, la entrada y salida de un sistema J2EE son muy complejas y cambian dinámicamente, y Java se ejecuta en forma multiplataforma. En la compilación y operación reales, pueden estar involucrados diferentes sistemas operativos. Si se permite que Java sea libre Dependiendo de. En el sistema operativo, se determina el conjunto de caracteres de codificación para entrada y salida, lo que resultará en caracteres confusos incontrolables. Es precisamente debido a la naturaleza multiplataforma de Java que los problemas del juego de caracteres deben ser resueltos de manera uniforme por sistemas específicos. Por lo tanto, en un sistema de aplicación Java, la forma fundamental de resolver los caracteres confusos chinos es especificar claramente un juego de caracteres unificado para el. todo el sistema de aplicación. Al especificar un juego de caracteres unificado, ¿debería especificar ISO8859_1, GBK o UTF-8? (1) Si se designa uniformemente como ISO8859_1, debido a que la mayoría del software actualmente es compilado por occidentales, su conjunto de caracteres predeterminado es ISO8859_1, incluido el sistema operativo Linux y la base de datos MySQL, etc. De esta manera, si especifica la codificación unificada Jive como ISO8859_1, entonces hay tres pasos que deben seguirse: Especifique el juego de caracteres como ISO8859_1 al desarrollar y compilar el código. La codificación predeterminada del sistema operativo en ejecución debe ser ISO8859_1, como Linux. Declare en el encabezado JSP: . (2) Si el conjunto de caracteres chinos se designa uniformemente como GBK, también se deben completar los tres pasos anteriores. La diferencia es que solo se puede ejecutar en sistemas operativos con la codificación predeterminada de GBK, como el Windows chino. Aunque la codificación unificada de ISO8859_1 y GBK brinda comodidad en la codificación, cada uno solo puede ejecutarse en el sistema operativo correspondiente. Pero también destruye la superioridad de la operación multiplataforma de Java y solo funciona dentro de un cierto rango.

Por ejemplo, para que la codificación GBK se ejecute en Linux, configure la codificación de Linux en GBK. Entonces, ¿existe una solución fundamental para la codificación china que no requiera configuraciones adicionales además del sistema de aplicación? Defina la codificación unificada del sistema Java/J2EE como UTF-8. La codificación UTF-8 es un método de codificación que es compatible con todos los idiomas. El único problema es encontrar todas las entradas y salidas del sistema de aplicaciones y luego usar UTF-8 para "ligarlo". Un sistema de aplicación J2EE debe realizar los siguientes pasos: Especificar el juego de caracteres como UTF-8 al desarrollar y compilar el código. Tanto JBuilder como Eclipse se pueden configurar en las propiedades del proyecto. Usando un filtro, si todas las solicitudes pasan por un despachador de control de Servlet, entonces use la declaración de ejecución del filtro del Servlet para convertir todas las solicitudes del navegador a UTF-8, porque el paquete de solicitud enviado por el navegador se basa en la codificación del sistema operativo del navegador. donde se encuentra puede haber varias formas de codificación. La frase clave: request.setCharacterEncoding("UTF-8"). El código fuente de este filtro está disponible en línea. En el código fuente del marco Jdon, com.jdon.util.SetCharacterEncodingFilter debe configurarse en web.xml para activar el filtro. Declare en el encabezado JSP: . En el código HTML Jsp, declare UTF-8: establezca el método de conexión de la base de datos en UTF-8. Por ejemplo, cuando se conecte a MYSQL, configure la URL de la siguiente manera: jdbc: mysql://localhost: 3306/test?useUnicode=trueamp; CharacterEncoding=UTF-8. Las bases de datos generales pueden configurar UTF-8 a través de la configuración de administración. debe configurarse al interactuar con el mundo exterior. Configure UTF-8 al leer archivos, operar XML, etc. 1. El origen del problema chino de Java: los archivos principales y de clase de Java se basan en Unicode, lo que hace que los programas Java sean buenos para varias plataformas, pero también trae algunos problemas con los caracteres chinos confusos. Hay dos razones principales: el problema del código confuso causado por la compilación de los propios archivos Java y JSP, y el problema del código confuso causado por la interacción de los programas Java con otros medios. En primer lugar

En primer lugar, es probable que los archivos fuente Java (incluido JSP) contengan chino, y el método de guardado de los archivos fuente Java y JSP se basa en flujos de bytes si Java y JSP se compilan en. archivos de clase

, si el método de codificación utilizado no es consistente con la codificación del archivo fuente, aparecerán caracteres confusos. Basado en este tipo de código confuso, se recomienda no escribir chino en archivos Java (la parte del comentario no participa en la compilación y no importa si escribe chino, si debe escribirlo, intente compilarlo). manualmente con el parámetro -ecoding GBK o -ecoding gb2312 ; para JSP, agregue lt;

@ page contentType="text/html; charset=GBK"gt;@ page contentType=

"text/ html;charset=gb2312"gt; básicamente puede resolver este tipo de problema de código confuso. Este artículo se centrará en el segundo tipo de código confuso, que es el código confuso que se genera cuando los programas Java interactúan con otros medios de almacenamiento.

Muchos medios de almacenamiento, como bases de datos, archivos, secuencias, etc., se basan en secuencias de bytes. Cuando un programa Java interactúa con estos medios, se producirá la conversión entre caracteres (char) y bytes (byte). : Enviar datos desde el formulario de la página al programa java byte-gt; char

Desde el programa java a la página mostrar byte desde la base de datos al programa java byte?gt; p>

Del programa java al archivo char?gt; byte del archivo al programa java byte-gt;

del programa java al archivo char-gt del flujo al programa java byte-gt; ; char

Desde el programa Java para transmitir el byte char-gt; si el método de codificación utilizado en el proceso de conversión anterior no coincide con la codificación original del byte, es probable que aparezcan caracteres confusos. 2. Solución Como se mencionó anteriormente, el proceso de conversión de caracteres y bytes cuando los programas Java interactúan con otros medios, si estos procesos de conversión son propensos a caracteres confusos. La clave para resolver estos problemas de código confuso es garantizar que el método de codificación utilizado durante la conversión sea coherente con el método de codificación original de los bytes, que se analizan por separado a continuación (consulte la primera parte para conocer los códigos confusos generados por Java o JSP). ). 1. Caracteres confusos entre JSP y los parámetros de la página

JSP

Al obtener los parámetros de la página, generalmente se utiliza el método de codificación predeterminado del sistema si el tipo de codificación de los parámetros de la página no es consistente con el sistema. tipo de codificación predeterminado, es probable que aparezcan caracteres confusos. El método básico para resolver este tipo de problema de código confuso es especificar por la fuerza el método de codificación de la solicitud para obtener parámetros antes de obtener los parámetros en la página: request.setCharacterEncoding("GBK") o

request. "gb2312").

Si aparecen caracteres confusos cuando JSP envía variables a la página, puede configurar

response.setContentType("text/html; charset=GBK") o Response.setContentType

("text/html;charset=gb2312") resuelto.

Si no desea escribir estas dos frases en cada archivo, una forma más sencilla es utilizar el filtro en la especificación del Servlet para especificar la codificación típica y el código principal del filtro en la web. .xml Como sigue:

web.xml:lt;filtergt;

lt;filter-namegt;CharacterEncodingFilterlt;/filter-namegt;

lt;filter -classgt; net.vschool.web.CharacterEncodingFilterlt;/filter-classgt;

lt;init-paramgt;

lt;param-namegt;encodinglt;/param-namegt;

lt;param-valuegt;GBKlt;/param-valuegt;

lt;/init-paramgt;

lt;/filtergt;

lt ;filter-mappinggt;

lt;filter-namegt;CharacterEncodingFilterlt;/filter-namegt;

lt;url-patternngt;/*lt;/url-patternngt;

lt;/filter-mappinggt;CharacterEncodingFilter.java: la clase pública CharacterEncodingFilter implementa el filtro

{protected String encoding = null public void init(FilterConfig filterConfig) lanza ServletException

{

this.encoding = filterConfig.getInitParameter("encoding");

}public void doFilter (solicitud ServletRequest, respuesta ServletResponse, cadena FilterChain) lanza IOException, ServletException

{

request.setCharacterEncoding(codificación);

response.setContentType("text/html; charset=" codificación);

chain.doFilter (solicitud, respuesta);

}}

2. Código confuso entre Java y la base de datos

La mayoría de ellos

Algunas bases de datos lo admiten utilizando codificación Unicode, por lo que la forma más inteligente de resolver el problema confuso entre Java y la base de datos es utilizar directamente la codificación Unicode para interactuar con la base de datos. Muchos controladores de bibliotecas de datos admiten automáticamente Unicode, como el controlador SQLServer de Microsoft.

La mayoría de los demás controladores de bases de datos se pueden especificar en los parámetros de URL del controlador, como el controlador mysql de mm

: jdbc: mysql://localhost/WEBCLDB?useUnicode=trueamp;

CharacterEncoding =GBK. 3. Caracteres confusos entre Java y archivos/streams

Las clases más utilizadas para leer y escribir archivos en Java son

FileInputStream/FileOutputStream y FileReader/FileWriter. Entre ellos, FileInputStream

y FileOutputStream se basan en flujos de bytes y se utilizan a menudo para leer y escribir archivos binarios. Para leer y escribir archivos de caracteres, se recomienda utilizar FileReader y

FileWriter basados ​​en caracteres, lo que elimina la necesidad de conversión entre bytes y caracteres. Sin embargo, los constructores de estas dos clases utilizan el método de codificación del sistema de forma predeterminada. Si el contenido del archivo no coincide con el método de codificación del sistema, pueden aparecer caracteres confusos.

En este caso, se recomienda utilizar la clase principal de FileReader y FileWriter:

InputStreamReader/OutputStreamWriter, que también se basan en caracteres, pero el tipo de codificación se puede especificar en el constructor:

InputStreamReader(InputStream in, Charset cs) y OutputStreamWriter

(OutputStream out, Charset cs). 4. Otros

Los métodos mencionados anteriormente deberían poder resolver la mayoría de los problemas de código confuso. Si todavía aparecen códigos confusos en

otros lugares, es posible que deba modificar el código manualmente. . La clave para resolver el problema confuso de Java es que durante el proceso de conversión de bytes y caracteres, debe conocer el método de codificación de los bytes originales o de los bytes convertidos. La codificación utilizada durante la conversión debe ser coherente con esta codificación. acercarse. Usamos el servidor Resin en el pasado y usamos el componente smartUpload para cargar archivos. Los parámetros chinos pasados ​​al cargar los archivos se obtuvieron sin caracteres confusos

. Cuando Resin se configura como un servicio en Linux, los parámetros chinos obtenidos al cargar archivos son confusos. Este problema nos ha preocupado durante mucho tiempo. Más adelante analizamos el archivo fuente del componente smartUpload. Debido a que la carga del archivo utiliza un flujo de bytes, los nombres y valores de los parámetros que contiene también se transfieren en un flujo de bytes. El componente smartUpload lee el flujo de bytes y luego analiza los nombres y valores de los parámetros del flujo de bytes. El problema ocurre cuando smartUpload usa la codificación predeterminada del sistema al convertir el flujo de bytes en una cadena. Después de configurar Resin como el servicio

, es posible que la codificación predeterminada del sistema haya cambiado, lo que genera caracteres confusos. Más tarde, cambiamos el archivo fuente de smartUpload, agregamos un conjunto de caracteres de atributo y el método

setCharset(String), y extrajimos la declaración del parámetro del método upload():

Valor de cadena = new String(m_binArray, m_startData, (m_endData - m_startData) 1);

Cambiado a

Valor de cadena = new String(m_binArray, m_startData, (m_endData - m_startData) 1, conjunto de caracteres) ;

Finalmente resolvió este problema de código confuso.