Что вызывает java.io.CharConversionException с сообщениями EOF или isHexDigit в Tomcat?

Это исключение переводит нашу производственную каталоги на простой вызов 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)

Или Иногда:

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)

Ответ 1

Просто гипотеза здесь. Похоже, что URL-декодирование параметров или их значения не сработают (кодирование URL означает кодирование некоторых символов с использованием обозначений% XX или% XXXX, где XX или XXXX является шестнадцатеричным кодом символа в ISO-8859-1 или Unicode). В первом случае ошибка может произойти, потому что после символа% не хватает шестнадцатеричных символов. Во втором случае это может происходить, потому что символ после символа% не является шестнадцатеричным.

Ответ 2

Еще одна вещь для изучения - это URIEncoding в вашей конфигурации Tomcat Connector. Если ссылка находится в кодированной UTF-8 странице, он будет кодировать URL-адрес в байты с UTF-8, затем URL-адрес закодирует любой из необходимых ему байтов. Однако, по умолчанию, Tomcat считает, что эти байты ISO-8859-1, что может привести к проблемам.

Обратный также может быть правдой: если на странице есть ISO-8859-1, а для Tomcat URIEncoding установлено значение UTF-8, может возникнуть аналогичная ошибка.

Здесь полезно обсудить проблемы в этой области: Ловушки Charset в контейнерах JSP/Servlet

Ответ 3

Я начал получать эту ошибку, когда пользователи отправляли "%" по запросу ajax. Оказывается, я не избежал параметров перед тем, как сделать запрос. Полная запись этого сценария и исправления рассматривается в этом сообщении .

Ответ 4

Это также может быть (из Википедии):

Существует нестандартная кодировка для символов Unicode:% uxxxx, где xxxx - значение Unicode, представленное в виде четырех шестнадцатеричных цифр. Это поведение не указано никаким RFC и было отклонено W3C. Третья редакция ECMA-262 по-прежнему включает функцию escape (string), которая использует этот синтаксис, а также функцию encodeURI (uri), которая преобразуется в UTF-8 и процент кодирует каждый октет.

Итак, вы можете использовать старую функцию escape в Javascript, но поскольку более поздние версии Tomcat более строгие в таких вещах (5.5.17 пусть этот слайд кодирования), только теперь вы начинаете видеть исключения.