configurar - ¿Qué causa java.io.CharConversionException con los mensajes EOF o isHexDigit en Tomcat?
configurar utf8 en tomcat (4)
Esta excepción da sabor a nuestros registros catalina de producción en una simple llamada ''getParameter ()''.
WARNING: Parameters: Character decoding failed. Parameter skipped. java.io.CharConversionException: EOF at org.apache.tomcat.util.buf.UDecoder.convert(UDecoder.java:82) at org.apache.tomcat.util.buf.UDecoder.convert(UDecoder.java:48) at org.apache.tomcat.util.http.Parameters.urlDecode(Parameters.java:411) at org.apache.tomcat.util.http.Parameters.processParameters(Parameters.java:393) at org.apache.tomcat.util.http.Parameters.processParameters(Parameters.java:509) at org.apache.tomcat.util.http.Parameters.handleQueryParameters(Parameters.java:266) at org.apache.catalina.connector.Request.parseParameters(Request.java:2361) at org.apache.catalina.connector.Request.getParameter(Request.java:1005) at org.apache.catalina.connector.RequestFacade.getParameter(RequestFacade.java:353) at javax.servlet.ServletRequestWrapper.getParameter(ServletRequestWrapper.java:158)
O algunas veces:
java.io.CharConversionException: isHexDigit at org.apache.tomcat.util.buf.UDecoder.convert(UDecoder.java:87) at org.apache.tomcat.util.buf.UDecoder.convert(UDecoder.java:48) at org.apache.tomcat.util.http.Parameters.urlDecode(Parameters.java:411) at org.apache.tomcat.util.http.Parameters.processParameters(Parameters.java:393) at org.apache.tomcat.util.http.Parameters.processParameters(Parameters.java:509) at org.apache.tomcat.util.http.Parameters.handleQueryParameters(Parameters.java:266) at org.apache.catalina.connector.Request.parseParameters(Request.java:2361) at org.apache.catalina.connector.Request.getParameter(Request.java:1005) at org.apache.catalina.connector.RequestFacade.getParameter(RequestFacade.java:353) at javax.servlet.ServletRequestWrapper.getParameter(ServletRequestWrapper.java:158)
Solo hipotetizando aquí. Parece que la decodificación URL de los parámetros o sus valores falla (la codificación URL significa codificar algunos caracteres usando la notación% XX o% XXXX donde XX o XXXX es el código hexadecimal del carácter en ISO-8859-1 o Unicode). En el primer caso, el error podría estar sucediendo porque no hay suficientes caracteres hexadecimales después del carácter%. En el segundo caso, esto podría estar sucediendo porque un carácter después del carácter% no es hexadecimal.
Otra cosa para investigar es la codificación URIE en su configuración de "Conector" de Tomcat. Si el enlace está en una página codificada en UTF-8, codificará la URL en bytes con UTF-8, luego la URL codificará cualquiera de los bytes que lo necesiten. Sin embargo, de forma predeterminada, Tomcat considera que esos bytes son ISO-8859-1, lo que puede generar problemas.
El inverso también puede ser cierto: si la página es ISO-8859-1, y la codificación URIE de Tomcat se ha configurado en UTF-8, podría producirse un error similar.
Aquí hay una discusión útil sobre los problemas en esta área: trampas de charset en contenedores JSP / Servlet
También podría ser esto (de Wikipedia):
Existe una codificación no estándar para caracteres Unicode:% uxxxx, donde xxxx es un valor Unicode representado como cuatro dígitos hexadecimales. Este comportamiento no está especificado por ningún RFC y ha sido rechazado por el W3C. La tercera edición de ECMA-262 aún incluye una función de escape (cadena) que usa esta sintaxis, pero también una función encodeURI (uri) que convierte a UTF-8 y codifica por ciento cada octeto.
Por lo tanto, podría estar usando la antigua función de escape en Javascript, pero dado que las versiones posteriores de Tomcat son más estrictas sobre tales cosas (5.5.17 permiten que esta codificación se desplace), recién ahora comienzan a aparecer excepciones.
Empecé a recibir este error cuando los usuarios enviaban ''%'' sobre una solicitud de Ajax. Resulta que no estaba escapando de los parámetros antes de hacer la solicitud. En esta publicación de blog se aborda una redacción completa de este escenario y solución