Pregunta

Hace dos días que empecé a usar Tomahawk ExtensionsFilter componentes im mi aplicación JSF. me di cuenta de que todos los javascript alertas no se presenta caracteres especiales (C, A, O O), muestra cosas como # 231 en su lugar. Cuando quito ExtensionsFilter de mi archivo web.xml, javascript muestra Allright. Cualquier persona tenía este problema antes?
gracias de antemano.

EDIT: yo era capaz de resolver el problema mediante la creación de un filtro antes de la extensionFilter, esta nueva fuerza filtro de la SOLICITUD juego de caracteres UTF-8. Pero esta es una solución fea, una mejor solución, como dijo balusC, sería para deshacerse de todo el Javascript en línea.
Gracias a todos por la ayuda!

¿Fue útil?

Solución

Algunas otras ideas:

  • añadir filtro que llama setContentType o setCharacterEncoding y que está delante de todos los demás filtros
  • establecer la propiedad -Dfile.encoding
  • volver a vincular el window.alert Javascript para que se escapa de los caracteres

Esto parece funcionar, pero sería un truco muy, muy feo. Esto también sería muy limitado y no funcionará si javascript establece otros textos, por ejemplo, contenido de un div.

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

ACTUALIZACIÓN:

Esta es la secuencia que es sospechoso:

1) ExtensionsFilter intercepta la solicitud

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 utiliza HtmlResponseWriterImpl que utiliza UnicodeEncoder .

4) All "caracteres latinos no básicas" son entonces codificados.

Conclusión

  • Si define el tipo de contenido a algo válido, el ExtensionsFilter será por defecto la rama "si no" y no codificar la respuesta. Pero, a continuación, el ExtensionsFilter es probablemente roto.
  • cambiar setCharacterEncoding tiene probablemente ningún efecto, ni el file.encoding
  • crear un filtro extra para envolver de nuevo la respuesta y revertir algunos de los &#xx; pueden trabajar, pero es muy feo.

No tengo otras ideas en este momento, pero estoy interesado en la respuesta como yo también encontré con el problema de codificación que eran molesto.


ACTUALIZACIÓN 2:

Se podría darle una oportunidad a AspectJ para alterar sólo la parte de la biblioteca MyFaces que se refiere a la forma de codificación dentro del filtro. De acuerdo con mi comprensión de cflow y el punto de corte call cosechas, algo como esto podría interceptar la codificación cuando se pasa desde el filtro. Si esta definición crea otras interferencias en el procesamiento de la solicitud, es posible que desee considerar también la llamada a addResource.writeResponse para limitar aún más el punto de corte.

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
    }
}

Otros consejos

Se escapa entidades XML. Sin embargo, también considera una mala práctica para servir código Javascript en línea en un archivo / XHTML JSP. Exteriorizar en su propio archivo que se especifica en <script src="path/to/file.js"></script> (al menos, su URL no debe ser cubierta por el filtro) y este problema particular, debe desaparecer.

Por cierto, ¿tiene cualquiera de estos en sus páginas JSP:

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

o

<%@ page pageEncoding="utf-8" %>
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top