myfaces ExtensionsFilter modifica la codifica della pagina?

Question

due giorni fa ho iniziato a utilizzare i componenti Tomahawk ExtensionsFilter nella mia applicazione jsf.ho notato che tutti gli avvisi JavaScript non mostravano caratteri speciali (ç, ã, ó ô), ma mostravano invece cose come #231.Quando rimuovo ExtensionsFilter dal mio file web.xml, Javascript visualizza tutto a posto.Qualcuno ha avuto questo problema prima?
grazie in anticipo.

MODIFICARE:sono riuscito a risolvere il problema creando un filtro prima di extensionFilter, questo nuovo filtro forza il set di caratteri REQUEST su utf-8.Ma questa è una brutta soluzione, una soluzione migliore, come ha detto balusC, sarebbe eliminare tutto il javascript in linea.
Grazie a tutti per l'aiuto!

Answer 1

Alcune altre idee:

• aggiungi il filtro che chiama setContentType O setCharacterEncoding e che è prima di tutti gli altri filtri
• impostare la proprietà -Dfile.encoding
• riassociare il javascript window.alert in modo che sfugga ai personaggi

Sembra funzionare, ma sarebbe un trucco molto, molto brutto.Anche questo sarebbe molto limitato e non funzionerebbe se javascript imposta altri testi, ad es.contenuto di a div.

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

---

AGGIORNAMENTO:

Ecco la sequenza sospetta:

1) Filtro estensioni intercetta la richiesta

2) ExtensionsFilter contiene

  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 usi HtmlResponseWriterImpl che utilizza Codificatore Unicode.

4) Tutti i "caratteri latini non di base" vengono quindi codificati.

Conclusione

• se imposti il ​​tipo di contenuto su qualcosa di non valido, ExtensionsFilter utilizzerà per impostazione predefinita il ramo "else" e non codificherà la risposta.Ma probabilmente ExtensionsFilter è rotto.
• la modifica di setCharacterEncoding probabilmente non ha alcun effetto, né il file file.encoding
• creando un filtro aggiuntivo per racchiudere nuovamente la risposta e ripristinare alcuni dei file &#xx; potrebbe funzionare ma è estremamente brutto.

Non ho altre idee in questo momento, ma sono interessato alla risposta perché mi sono imbattuto anche in problemi di codifica che erano fastidiosi.

---

AGGIORNAMENTO 2:

Potresti fare un tentativo AspettoJ per alterare solo la parte della libreria MyFaces che si riferisce al modulo di codifica all'interno del filtro.Secondo la mia comprensione di cflow e il call selezioni pointcut, qualcosa di simile potrebbe intercettare la codifica quando avviene dal filtro.Se questa definizione crea altre interferenze nell'elaborazione della richiesta, potresti prendere in considerazione anche la chiamata a addResource.writeResponse per limitare ulteriormente il taglio del punto.

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

Si sfugge entità XML. E 'però anche considerata povera pratica di servire codice Javascript inline in un file / XHTML JSP. Esternare nel proprio file che si specifica in <script src="path/to/file.js"></script> (almeno, il suo URL non deve essere coperto dal filtro) e questo particolare problema dovrebbe scomparire.

Answer 3

A proposito, avete uno di questi nelle vostre pagine JSP:

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

o

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