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

Se reproduce lo siguiente: Los problemas chinos de Java siempre han preocupado a muchos principiantes. Si comprendemos los principios de los problemas chinos en los sistemas Java, podemos resolver fundamentalmente los problemas chinos. La solución más antigua es utilizar la conversión de código de bytes de cadena. Este programa es inconveniente para resolver el problema. Necesitamos destruir la encapsulación del objeto y realizar la conversión de código de bytes. Otro método es codificar el contenedor J2EE. Si el sistema de aplicación J2EE está separado del contenedor, aparecerá un código confuso y la configuración del contenedor especificado no cumple con el principio de separación del sistema de aplicación J2EE y el contenedor. En la operación interna de Java, todas las cadenas involucradas se convierten a codificación UTF-8 para su operación. Entonces, ¿qué conjunto de caracteres tiene la 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. La entrada y salida del sistema Java se basan en la codificación predeterminada del sistema operativo. Por lo tanto, si se pueden unificar la entrada y salida del sistema Java y el conjunto de caracteres de codificación del sistema operativo, el sistema Java puede procesar y mostrar correctamente los caracteres chinos. Este es un principio para que el sistema Java procese caracteres chinos, pero en proyectos reales, es difícil comprender y controlar correctamente las partes de entrada y salida del sistema Java. Debido a que J2EE involucra navegadores y bases de datos externos, el problema de los caracteres chinos confusos es muy importante. Las aplicaciones J2EE se ejecutan en contenedores J2EE. En este sistema, hay muchas formas de ingresar: una es empaquetarla en una solicitud a través de un formulario de página y enviarla al servidor, la segunda es leerla a través de la base de datos y el tercer método de entrada es más complicado, JSP; En el tercero, siempre se compila en un servlet cuando se ejecuta una vez. En este momento, Java utilizará la codificación predeterminada del sistema operativo como codificación inicial. A menos que se especifique lo contrario, se puede especificar un juego de caracteres predeterminado como en Jbuilder/eclipse. Hay varias rutas de salida: la primera 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 también 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, también hay una ruta de salida a la base de datos; envía la cadena 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 varias plataformas. En la compilación y operación reales, pueden estar involucrados diferentes sistemas operativos. Si se permite, Java es libre de determinar la entrada y la salida. conjuntos de caracteres de codificación de salida basados ​​​​en el sistema operativo, lo que sería un caos incontrolable. Es precisamente debido a las características multiplataforma de Java que el conjunto de caracteres debe ser resuelto de manera uniforme por un sistema específico. Por lo tanto, en el sistema de aplicaciones Java, la forma fundamental de resolver caracteres chinos confusos es especificar un conjunto de caracteres unificado en el. todo el sistema de aplicación. Para especificar un juego de caracteres unificado, ¿debería especificar ISO8859_1, GBK o UTF-8? (1) Si se especifica ISO8859_1 de manera uniforme, 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 la codificación unificada Jive se especifica como ISO8859_1, se deben comprender los tres enlaces siguientes: Especifique el juego de caracteres como ISO8859_1 al desarrollar y compilar el código. La codificación predeterminada del sistema operativo debe ser ISO8859_1, como Linux. Declare en el encabezado JSP: . (2) Si se designa uniformemente como el conjunto de caracteres chinos GBK, también se deben completar los tres enlaces anteriores. La diferencia es que solo se puede ejecutar en sistemas operativos con la codificación predeterminada de GBK, como el Windows chino. La codificación unificada es ISO8859_1 y GBK. Aunque resulta conveniente compilar el código, cada uno solo puede ejecutarse en el sistema operativo correspondiente. Pero esto también debilita la superioridad de la operación multiplataforma de Java, que sólo puede ejecutarse 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 que no requiera ninguna configuración adicional para la codificación china aparte del sistema de aplicación? La codificación unificada de los sistemas Java/J2EE se define como UTF-8. La codificación UTF-8 es una codificación 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". Una aplicación J2EE requiere los siguientes pasos: Desarrollar y compilar código que especifique el juego de caracteres UTF-8. JBuilder y Eclipse se pueden configurar en las propiedades del proyecto. Usando un filtro, si todas las solicitudes pasan por el despachador de control del Servlet, entonces use la declaración ejecutable del filtro del Servlet para convertir todas las solicitudes realizadas por el navegador (solicitudes) a UTF-8, porque los paquetes de solicitud realizados por el navegador pueden estar codificados. en varias formas dependiendo de la codificación del sistema operativo en el que se ejecuta el navegador. Frase clave: request.setCharacterEncoding("UTF-8"). com.jdon.util.SetCharacterEncodingFilter en el código fuente de Jdon Framework requiere que web.xml esté configurado para activar el filtro. Declare UTF-8 en el código HTML Jsp: establezca el modo 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=true&characterEncoding=UTF- 8 Las bases de datos generales pueden configurar UTF-8 a través de la administración, y se pueden configurar otras codificaciones cuando interactuar con el mundo exterior, como 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: caracteres confusos causados ​​por la compilación de los propios archivos Java y JSP, y caracteres confusos causados ​​por programas Java que interactúan con otros medios. Primero

En primer lugar, es probable que los archivos fuente de Java (incluido JSP) contengan chino, y los archivos fuente de Java y JSP se guardan en función de flujos de bytes si Java y JSP están en el proceso de compilación en clase. files

Si la codificación utilizada en p>

no coincide con la codificación del archivo fuente, aparecerán caracteres confusos. En base a este tipo de código confuso, se recomienda intentar no escribir chino en archivos Java (los comentarios no participan en la compilación y escribir chino no importa si es necesario escribir

, intente hacerlo). use el parámetro -ecoding GBK o -ecoding gb2312 para compilar manualmente para JSP, agregue <%

@ page contentType="text/html;charset=GBK"%> o <%@ page contentType=<; /p>

"text/html; en el archivo de encabezado; charset=gb2312"%>, ¡básicamente puede resolver este tipo de tonterías! pregunta. 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 los programas Java interactúan con estos medios, se producirá la conversión entre caracteres (char) y bytes (byte). Envíe datos desde el formulario de la página al byte->char

del programa java a la página, muestre char->char

desde el programa java a la página. , mostrar char?> byte de la base de datos al byte del programa java?>char

Del programa java a la base de datos char?>byteDel archivo al byte del programa java->char

Del programa java al archivo char-> byteDe la secuencia al programa java byte->char

Del programa java a la secuencia char->byte Si la codificación utilizada en la conversión anterior es inconsistente con la codificación original del byte, los caracteres confusos se probable que aparezca. 2. Solución Como se mencionó anteriormente, el proceso de conversión entre 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 caracteres confusos es garantizar que la codificación utilizada durante la conversión sea consistente con los bytes codificados originales, lo cual se analiza a continuación (consulte la Parte 1 para conocer los caracteres confusos generados por Java o JSP). 1. Caracteres confusos entre JSP y los parámetros de la página

JSP

Obtener parámetros de página generalmente se utilizan para obtener la codificación predeterminada del sistema, si el tipo de codificación de los parámetros de la página es consistente con la codificación predeterminada del sistema. Si el tipo de codificación de los parámetros de la página no coincide con el tipo de codificación predeterminado del sistema, es probable que se produzcan caracteres confusos. La forma básica de resolver este problema confuso es especificar la codificación de los parámetros de solicitud antes de la página

: request.setCharacterEncoding("GBK") o

request.setCharacterEncoding(" 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") para resolver el problema. vschool.web.Net.

codificación

GBK

CharacterEncodingFilter< ./filter-name>

/*

CharacterEncodingFilter.java: la clase pública CharacterEncodingFilter implementa el filtro

{codificación de cadena protegida = null; public void init(FilterConfig filterConfig) lanza ServletException

{

this.encoding = filterConfig.getInitParameter("codificación"); /p>

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

{

request.setCharacterEncoding(codificación);

response.setContentType("text/html;charset="+encoding);

Cadena. doFilter(solicitud,respuesta);

}}

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

Grande

Algunas bases de datos Todas admite 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 bases 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 el parámetro URL del controlador, como el controlador mysql de mm: jdbc:mysql://localhost/WEBCLDB?useUnicode=true&

CharacterEncoding=GBK. 3. Java y código confuso de archivos/transmisiones

Las clases más utilizadas en Java para leer y escribir archivos 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, que eliminan la necesidad de convertir entre bytes y caracteres. Sin embargo, los constructores de estas dos clases utilizan la codificación del sistema de forma predeterminada, por lo que si el contenido del archivo no coincide con la codificación del sistema, pueden aparecer caracteres confusos.

En este caso, se recomienda utilizar las clases principales 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

El método anterior debe ser. capaz de resolver la mayoría de los problemas de código confuso. Si aparecen caracteres confusos en otros lugares, es posible que deba modificar el código manualmente. La clave para resolver el problema confuso de Java es que en el proceso de convertir bytes a caracteres, debe saber cómo están codificados los bytes originales o los bytes convertidos y la codificación utilizada durante el proceso de conversión

Debe ser coherente con esta codificación. Solíamos usar el servidor Resin para cargar archivos usando el componente smartUpload. Se pueden obtener los parámetros chinos pasados ​​​​al cargar el archivo y no habrá confusión de codificación. Cuando configuramos Resin como servicio en Linux, los parámetros chinos de los archivos cargados estaban confusos. Este problema nos preocupó durante mucho tiempo. Más tarde analizamos el archivo fuente del componente smartUpload. Debido a que la carga de archivos es un flujo de bytes, los nombres y valores de los parámetros que contiene también son flujos 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 es que el componente smartUpload no tiene ningún código basura. El problema es que smartUpload utiliza la codificación predeterminada del sistema al convertir el flujo de bytes en una cadena. Después de configurar Resin en

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

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

String value = new String(m_binArray, m_ startData, (m_endData - m_startData) + 1);

Cambiar a

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

Finalmente resolvió esta confusión.