JSF/Facelets utiliza por defecto UTF-8 para decodificar los parámetros de solicitud HTTP. GlassFish usa por defecto el ISO-8859-1 para decodificar los parámetros de solicitud HTTP. Los parámetros de solicitud HTTP pueden analizarse y decodificarse solo una vez, y esto ocurre siempre que el código solicite un parámetro de solicitud por primera vez, como request.getParameter("name"). Por lo tanto, si se solicita un parámetro de solicitud por primera vez antes de JSF ha establecido la codificación del parámetro de solicitud en UTF-8, entonces se analizará (incorrectamente) utilizando ISO-8859-1.
Cuando JSF tiene que establecer el parámetro de la petición de codificación durante la fase de restauración de vista de la siguiente manera,
request.setCharacterEncoding("UTF-8");
mientras que los parámetros de la petición ya se analizan, a continuación, GlassFish mostrará exactamente esta advertencia.
La consecuencia no deseada es que todos esos parámetros de solicitud HTTP pueden posiblemente terminar en Mojibake. Los datos del formulario se enviaron originalmente y se codificaron utilizando UTF-8. Si decodifica datos UTF-8 usando un juego de caracteres diferente como ISO-8859-1, entonces los caracteres en el rango de 8 bits y más allá (por lo general, son esos "caracteres especiales" como é, à, ö, etc. se corromperán y terminan en é, à , ö, etc.
Técnicamente, la solución correcta es no solicitud de un parámetro de petición HTTP antes JSF ha establecido la codificación correcta. es, básicamente, tiene que comprobar todo el código que se ejecuta antes de la fase de vista de restauración de JSF, como filtros de servlets, oyentes de fase, etc., si no lo están haciendo.
Si parece que no puede encontrarlo, o el código está fuera de su control, puede indicarle a GlassFish que use UTF-8 para decodificar los parámetros de solicitud HTTP, de modo que no necesite cambiarse cuando JSF desee para conseguirlos. Puede hacerlo añadiendo la siguiente entrada al <glassfish-web-app> de su /WEB-INF/glassfish-web.xml archivo:
<parameter-encoding default-charset="UTF-8"/>
(nota: el archivo y entrada de la raíz está llamado anteriormente sun-web.xml y <sun-web-app> respectivamente)
anotados deben ser tan esto es específico de GlassFish y todo esto no funcionará cuando implemente la aplicación web en un servidor diferente.El enfoque independiente del servidor canónica es crear un servlet filter lo que hace básicamente lo siguiente puesto de trabajo en doFilter() método:
request.setCharacterEncoding("UTF-8");
chain.doFilter(request, response);
y asegúrese de que ha sido asignado antes que cualquier otro filtro que necesita para recoger cualquier parámetros de la petición HTTP.
actualización: por qué GlassFish se ha fijado de antemano, es posiblemente causado por PrimeFaces. Ver también esta pregunta relacionada: Unicode input retrieved via PrimeFaces input components become corrupted.
Desde mi experiencia este famoso mensaje se pierde después de actualizar la versión mojarra . Cual estas usando? – Osw
@Osw: de hecho hubo un error relacionado en una de las primeras versiones de Mojarra 2.0.x, pero eso fue causado por un problema levemente diferente y afectó solo las solicitudes de Ajax. Sin embargo, OP está utilizando GF 3.1, que agrupa JSF 2.1. – BalusC
@osw: específicamente estoy usando GF 3.1.1 Build 12. Probablemente no debería, pero dejo que tanto Netbeans como GF descarguen todas las actualizaciones tan pronto como estén disponibles. Sin embargo, recuerdo este problema en casi todos los niveles de versión. Llegué al punto en el que estaba probando muchas páginas, generando suficientes mensajes de error en el proceso, que me estimularon para tomar medidas al respecto. Por cierto, la versión de Mojarra en este paquete es 2.1.3 (FCS b02). – AlanObject