jsp - Pasar parámetros de solicitud como cadenas codificadas en UTF-8
servlets character-encoding (5)
Esta pregunta ya tiene una respuesta aquí:
Estoy creando una página de inicio de sesión simple y quiero pasar los parámetros de inicio de sesión y contraseña como cadenas codificadas UTF-8. Como puede ver en el siguiente código, la primera línea es donde establezco la codificación para UTF-8, pero parece que esto no tiene sentido porque no funciona. Cuando uso los parámetros de inicio de sesión y contraseña con acentos, la página de resultados recibe caracteres extraños.
¿Cómo configurar la codificación de caracteres correctamente de una manera que funcione en todos los navegadores?
<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>My Page</title>
</head>
<body>
<h1>Welcome to My Page</h1>
<form name="login" action="login.jsp" method="POST">
Login:<br/>
<input type="text" name="login" value="" /><br/>
Password:<br/>
<input type="password" name="password" value="" /><br/>
<br/>
<input type="submit" value="Login" /><br/>
</form>
</body>
</html>
Codificación de caracteres de muestra:
<%@ page language="java" pageEncoding="utf8" contentType="text/html;charset=UTF-8" %>
El pageEncoding solo establece la codificación del carácter de respuesta y el atributo charset del encabezado HTTP Content-Type . Básicamente, le dice al servidor que decodifique los caracteres producidos por JSP como UTF-8 antes de enviarlo al cliente y el encabezado le dice al cliente que los codifique usando UTF-8 y también que lo use cuando cualquier formulario en la misma página es para ser enviado de vuelta al servidor. El contentType ya está predeterminado en text/html , por lo que a continuación es suficiente:
<%@page pageEncoding="UTF-8"%>
La metaetiqueta HTML se ignora cuando la página se sirve a través de HTTP. Solo se ha usado cuando la página está guardada por el cliente como un archivo HTML en un sistema de disco local y luego se abre con un file:// URI en el navegador.
En su caso particular, la codificación del cuerpo de la solicitud HTTP aparentemente no se ha establecido en UTF-8. La codificación del cuerpo de la solicitud debe establecerse mediante ServletRequest#setCharacterEncoding() en el servlet o un filtro antes de realizar la primera llamada en request.getXxx() en cualquier servlet o filtro involucrado en la solicitud.
request.setCharacterEncoding("UTF-8");
String login = request.getParameter("login");
String password = request.getParameter("password");
// ...
Ver también:
El problema depende de eso, qué servidor de aplicaciones se usa. Incluso las páginas están correctamente configuradas, por ejemplo, en UTF8, el intento de obtener el parámetro en forma correcta (según el lenguaje esperado) no da buenos resultados, es decir, request.getParameter (...) no devuelve los caracteres esperados, porque la página de códigos predeterminada para los parámetros mayormente 8859-1. Significa que la página de códigos para parámetros es independiente en la página de códigos de la página JSP y la página de códigos predeterminada para los parámetros influye en el resultado. La mejor descripción que encontré está aquí: [1]: http://docs.cksource.com/CKFinder_2.x/Developers_Guide/Java/Configuration/URI_Encoding . En algunos servidores de aplicaciones, el "request.setCharacterEncoding (...)" no tiene ningún efecto. Debe establecer la codificación de parámetros en el descriptor. Los más complicados son JBoss, Apache Tomcat, en el medio está Glassfish. Mejor es WebLogic, lo mejor es Jetty (UTF-8 es la configuración predeterminada). En mi caso, debo crear el descriptor glassfish-web.xml y poner allí la etiqueta de codificación de parámetros. En mi caso (GlassFish):
<glassfish-web-app error-url="">
<!-- request.setCharacterEncoding("UTF-8") not functioning -->
<parameter-encoding default-charset="UTF-8" />
</glassfish-web-app>
Llamar a ServletRequest # setCharacterEncoding () seguirá fallando en algunos casos.
Si su contenedor sigue cuidadosamente las especificaciones del servlet (al igual que tomcat), interpretará los parámetros de la publicación como ISO-8859-1 de forma predeterminada. Esto puede distorsionar caracteres UTF-8 (como el japonés en el caso reciente en el que trabajé) antes de que lleguen a su código, especialmente si tiene un filtro de servlet que inspecciona los parámetros de solicitud con getParameter() o getParameters() . Esos dos métodos fuerzan la decodificación de los parámetros, y la decodificación solo se realiza una vez.
Aquí hay un enlace para saber cómo solucionar esto en Tomcat si tiene filtros que miren los parámetros de la solicitud. La gente querrá verificar los documentos para su contenedor particular.
http://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q1
La parte clave de eso es:
Añadir
useBodyEncodingForURI="true" URIEncoding="UTF-8"
al elemento de contexto en server.xml de Tomcat y agregar
<filter>
<filter-name>Character Encoding Filter</filter-name>
<filter-class>org.apache.catalina.filters.SetCharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>Character Encoding Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
como antes cualquier filtro que llama getParameter () o getParameters () en web.xml. Descubrí que aunque el enlace anterior hace que los dos atributos del elemento de contexto parezcan alternativas, useBodyEncodingForURI uno es absolutamente necesario o tomcat no establecerá la codificación para la cadena de consulta. Desde Request.java en tomcat 7.0.42:
boolean useBodyEncodingForURI = connector.getUseBodyEncodingForURI();
if (enc != null) {
parameters.setEncoding(enc);
if (useBodyEncodingForURI) {
parameters.setQueryStringEncoding(enc);
}
} else {
parameters.setEncoding
(org.apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING);
if (useBodyEncodingForURI) {
parameters.setQueryStringEncoding
(org.apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING);
}
}
Me encontré con este problema recientemente y no pude encontrar la respuesta aquí. Estoy usando Weblogic y la mayoría de las soluciones son para Tomcat.
Para que la codificación funcione con Weblogic, debe poner esto en su weblogic.xml
<charset-params>
<input-charset>
<resource-path>/*</resource-path>
<java-charset-name>UTF-8</java-charset-name>
</input-charset>
</charset-params>
Fuente: documentos weblogic.xml
NOTA: También tengo estas opciones en mi _JAVA_OPTIONS, pero no sé si son necesarias.
-Dweblogic.webservice.i18n.charset=utf-8
-Dfile.encoding=UTF-8