Quelles sont les causes des exceptions java.io.CharConversionException avec EOF ou isHexDigit dans Tomcat?

Question

Cette exception piment notre catalogue de production enregistre sur un simple appel '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)

Ou parfois:

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

Faites juste une hypothèse ici. On dirait que le décodage d'URL des paramètres ou de leurs valeurs échoue (codage d'URL signifie coder certains caractères en utilisant la notation% XX ou% XXXX, où XX ou XXXX est le code hexadécimal du caractère dans ISO-8859-1 ou Unicode). Dans le premier cas, l'erreur peut se produire car il n'y a pas assez de caractères hexadécimaux après le caractère%. Dans le second cas, cela peut se produire car un caractère après le caractère% n'est pas hexadécimal.

Answer 2

Une autre chose à examiner est le URIEncoding dans votre Tomcat " Connector " ; configuration. Si le lien se trouve dans une page codée UTF-8, il codera l’URL en octets avec UTF-8, puis l’URL encodera tous les octets qui en ont besoin. Cependant, par défaut, Tomcat pense que ces octets sont ISO-8859-1, ce qui peut entraîner des problèmes.

L'inverse peut aussi être vrai: si la page est ISO-8859-1 et que le codage URIEncoding de Tomcat est défini sur UTF-8, une erreur similaire pourrait en résulter.

Voici une discussion utile sur les problèmes dans ce domaine: Pièges dans les jeux de caractères dans les conteneurs JSP / Servlet

Answer 3

J'ai commencé à recevoir cette erreur lorsque les utilisateurs envoyaient '%' via une requête ajax. Il s'avère que je n'échappais pas aux paramètres avant de faire la demande. Une description complète de ce scénario et de ce correctif est couverte dans ce article de blog

Answer 4

Cela pourrait aussi être ceci (de Wikipedia):

Il existe un codage non standard pour les caractères Unicode:% uxxxx, où xxxx est une valeur Unicode représentée par quatre chiffres hexadécimaux. Ce comportement n'est spécifié par aucun RFC et a été rejeté par le W3C. La troisième édition de ECMA-262 inclut toujours une fonction d'échappement (chaîne) qui utilise cette syntaxe, mais également une fonction encodedURI (uri) qui est convertie en UTF-8 et codant en pourcentage chaque octet.

Vous pouvez donc utiliser l'ancienne fonction d'échappement en Javascript, mais comme les versions ultérieures de Tomcat sont plus strictes à cet égard (5.5.17 laissent cette diapositive d'encodage), ce n'est que maintenant que vous commencez à voir des exceptions.