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

Question

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

Answer 1

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

Answer 2

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

Answer 3

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

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

Вот полезное обсуждение проблем в этой области: Подводные камни в контейнерах JSP / Servlet

Answer 4

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

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

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