Ist myfaces ExtensionsFilter Änderung Seitencodierung?
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!
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" %>