Est-ce que le changement myfaces ExtensionsFilter la page de codage?

Question

j'ai commencé il y a deux jours en utilisant des composants Tomahawk ExtensionsFilter im mon application JSF. J'ai remarqué que tous les javascript alertes n'affichaient pas des caractères spéciaux (C, ã, ó ô), il affiche des choses comme # 231 à la place. Quand je supprimer ExtensionsFilter de mon fichier web.xml, javascript affiche Allright. Tout le monde a eu ce problème avant?
merci à l'avance.

EDIT: j'ai pu résoudre le problème en créant un filtre avant la extensionFilter, cette nouvelle force de filtre la demande de charset utf-8. Mais cette solution est laide, une meilleure solution, comme l'a dit balusC, serait de se débarrasser de tout le javascript en ligne.
Merci à tous pour l'aide!

Answer 1

Quelques autres idées:

• ajouter filtre qui appelle setContentType ou setCharacterEncoding et qui est avant tous les autres filtres
• définir la propriété -Dfile.encoding
• rebind le javascript window.alert de sorte qu'il échappe aux caractères

Cela semble fonctionner, mais serait un hack très, très laid. Ce serait également très limité et ne fonctionnera pas si javascript définit d'autres textes, par exemple le contenu d'un div.

var hack = window.alert;
window.alert = function( text ) {
    hack( text + ' was converted' );
};
alert('hello');

---

Mise à jour:

Voici la séquence qui est suspect:

1) ExtensionsFilter intercepte la demande

2) ExtensionsFilter contient

  154   // only parse HTML responses
  155   if (extendedResponse.getContentType() != null && isValidContentType(extendedResponse.getContentType()))
  156   {
        ...
  172        // writes the response
  173        addResource.writeResponse(extendedRequest, servletResponse);
  174    }
  175   else
  176   {
  178        byte[] responseArray = extendedResponse.getBytes();
  180        if(responseArray.length > 0)
  181       {
  182       // When not filtering due to not valid content-type, deliver the byte-array instead of a charset-converted string.
  183       // Otherwise a binary stream gets corrupted.
  184       servletResponse.getOutputStream().write(responseArray);
  185     }

3) DefaultAddResource utilise HtmlResponseWriterImpl qui utilise UnicodeEncoder .

4) Tous les "caractères latins non de base" sont ensuite codées.

Conclusion

• si vous définissez le type de contenu à quelque chose non valide, le ExtensionsFilter par défaut à la branche « else » et ne sera pas coder la réponse. Mais, le ExtensionsFilter est probablement cassé.
• changer setCharacterEncoding n'a probablement aucun effet, ni le file.encoding
• créer un filtre supplémentaire pour envelopper à nouveau la réponse et de revenir certains des &#xx; pourrait fonctionner, mais est extrêmement laid.

Je n'ai pas d'autres idées en ce moment, mais je suis intéressé par la réponse que je aussi cogné sur la question de codage qui était ennuyeux.

---

Mise à jour 2:

Vous pouvez donner un essai AspectJ de modifier uniquement la partie de la bibliothèque MyFaces qui se rapporte à la forme de codage à l'intérieur du filtre. Selon ma compréhension de cflow et la call pointcut cueillettes, quelque chose comme cela pourrait intercepter l'encodage quand il arrive du filtre. Si cette définition crée d'autres interférences dans le traitement des demandes, vous voudrez peut-être envisager aussi l'appel à addResource.writeResponse pour limiter davantage le pointcut.

public aspect SkipEncoding {  
    pointcut encodingInExtFilter() : 
        cflow( * org.apache.myfaces.webapp.filter. ExtensionsFilter.doFilter(..) ) && 
        call ( String UnicodeEncoder.encode( String, bool, bool ));   
    around( String s, bool b1, bool b2 ) : encodingInExtFilter
    {
        return s; // skip encoding
    }
}

Answer 2

Il échappe à des entités XML. Cependant, il est également considéré comme une mauvaise pratique pour servir en ligne de code Javascript dans un fichier JSP / XHTML. Externaliser dans son propre fichier que vous spécifiez dans <script src="path/to/file.js"></script> (au moins, son URL ne doit pas être couvert par le filtre) et ce problème devrait disparaître.

Answer 3

Par ailleurs, avez-vous l'un de ces dans vos pages jsp:

<?xml version="1.0" encoding="utf-8"?>

ou

<%@ page pageEncoding="utf-8" %>