Frage

Vor zwei Tagen begann ich Tomahawk mit ExtensionsFilter Komponenten meiner JSF-Anwendung im. Ich bemerkte, dass alle JavaScript-Warnungen keine Sonderzeichen anzeigt wurden (C, E, A ô), zeigt es Dinge wie # 231 statt. Wenn ich ExtensionsFilter aus meiner web.xml-Datei entfernen, JavaScript allright zeigt. Jeder hatte dieses Problem vor?
Vielen Dank im Voraus.

EDIT: Ich konnte das Problem lösen, indem ein Filter vor dem extensionFilter, diese neue Filterkraft der REQUEST charset utf-8 zu schaffen. Aber das ist eine hässliche Lösung, eine bessere Lösung, als balusC sagte, wäre alle Inline-Javascript loszuwerden.
Vielen Dank für die Hilfe!

War es hilfreich?

Lösung

Ein paar andere Ideen:

  • Filter hinzufügen, die setContentType oder setCharacterEncoding und das ist vor allen anderen Filter
  • Legen Sie die Eigenschaft -Dfile.encoding
  • rebind JavaScript window.alert so, dass sie die Zeichen entkommt

Dies scheint zu arbeiten, aber ein sehr, sehr hässlicher Hack wäre. Dies würde auch sehr begrenzt sein und wird nicht funktionieren, wenn Javascript andere Texte stellt, z.B. Inhalt eines div.

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

UPDATE:

Hier ist die Sequenz, die verdächtig ist:

1) ExtensionsFilter fängt die Anforderung

2) ExtensionsFilter enthält

  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 verwendet HtmlResponseWriterImpl die verwendet UnicodeEncoder .

4) Alle "nicht grundlegende lateinische Zeichen" werden dann verschlüsselt.

Fazit

  • Wenn Sie den Inhaltstyp auf etwas ungültig gesetzt ist, wird die ExtensionsFilter auf die „else“ Zweig Standard und wird die Antwort nicht kodieren. Aber dann wird der ExtensionsFilter wahrscheinlich gebrochen.
  • setCharacterEncoding Wechsel hat wahrscheinlich keine Wirkung, weder die file.encoding
  • einen zusätzlichen Filter wird die Antwort wickeln wieder und einige der &#xx; zurückkehren könnte funktionieren, aber ist extrem hässlich.

Ich habe keine andere Ideen im Moment, aber ich bin in der Antwort interessiert, wie ich auf eine Codierung Problem auch gestoßen, die lästig waren.


UPDATE 2:

Sie können einen Versuch AspectJ zu ändern, nur den Teil der MyFaces Bibliothek, die innerhalb des Filters auf die Codierung Form bezieht. Nach meinem Verständnis von cflow und den call pointcut pickings, so etwas wie dies könnte die Codierung abfangen, wenn es aus dem Filter passiert. Wenn diese Definition andere Störungen in der Anforderungsverarbeitung erstellt, möchten Sie vielleicht auch den Anruf betrachten addResource.writeResponse weiter die pointcut zu begrenzen.

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

Andere Tipps

Es entkommt XML-Entitäten. Es ist jedoch auch eine schlechte Praxis zu dienen Javascript-Code inline in einer JSP / XHTML-Datei betrachtet. Externalisieren es in einer eigenen Datei, die Sie in <script src="path/to/file.js"></script> angeben (zumindest sollte die URL durch die Filter nicht abgedeckt werden), und dieses spezielle Problem sollte verschwinden.

Übrigens, haben Sie eine dieser in Ihrem jsp Seiten:

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

oder

<%@ page pageEncoding="utf-8" %>
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top