Details
-
Type:
New Feature
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: Export
-
Labels:None
-
Application server:all
Description
It will be very useful to permit to the displaytag users to choose for the export files a different encoding than the JSP page.
This will solve many national characters problems (as MS Excel cannot read UTF-8 encoded files, for example).
This can be simply done with an ExportDelegate little patch which permits the user to specify the traget encoding in the getMimeType() method of a custom ExportView implementation. :
example :
public class ExcelCsvView extends CsvView {
public String getMimeType() {
return "text/csv; charset=cp1252"; //uses the Windows Latin-1 superset encoding
}
}
ExportDelegate patch :
--- ExportDelegate.java
+++ ExportDelegate.java
@@ -112,124 +112,131 @@
String characterEncoding = wrapper.getCharacterEncoding();
String wrappedContentType = wrapper.getContentType();
if (wrappedContentType != null && wrappedContentType.indexOf("charset") > -1)
{
// charset is already specified (see #921811)
characterEncoding = StringUtils.substringAfter(wrappedContentType, "charset=");
}
+ //the target encoding is already specified in contentType :
+ if( contentType.indexOf("charset") > -1)
+ {
+ characterEncoding=StringUtils.substringAfter(contentType, "charset=");
+ contentType = contentType.substring(0, contentType.indexOf(';')).trim();
+ }
+
if (characterEncoding != null && contentType.indexOf("charset") == -1) //$NON-NLS-1$
{
contentType += "; charset=" + characterEncoding; //$NON-NLS-1$
}
A better solution (but a little more complicated) is to allow the encoding specification with a taglib table property like this :
<display:setProperty name="export.csv.encoding" value="cp1252"/> (But I haven't found how to do this).
Frantz D.
This will solve many national characters problems (as MS Excel cannot read UTF-8 encoded files, for example).
This can be simply done with an ExportDelegate little patch which permits the user to specify the traget encoding in the getMimeType() method of a custom ExportView implementation. :
example :
public class ExcelCsvView extends CsvView {
public String getMimeType() {
return "text/csv; charset=cp1252"; //uses the Windows Latin-1 superset encoding
}
}
ExportDelegate patch :
--- ExportDelegate.java
+++ ExportDelegate.java
@@ -112,124 +112,131 @@
String characterEncoding = wrapper.getCharacterEncoding();
String wrappedContentType = wrapper.getContentType();
if (wrappedContentType != null && wrappedContentType.indexOf("charset") > -1)
{
// charset is already specified (see #921811)
characterEncoding = StringUtils.substringAfter(wrappedContentType, "charset=");
}
+ //the target encoding is already specified in contentType :
+ if( contentType.indexOf("charset") > -1)
+ {
+ characterEncoding=StringUtils.substringAfter(contentType, "charset=");
+ contentType = contentType.substring(0, contentType.indexOf(';')).trim();
+ }
+
if (characterEncoding != null && contentType.indexOf("charset") == -1) //$NON-NLS-1$
{
contentType += "; charset=" + characterEncoding; //$NON-NLS-1$
}
A better solution (but a little more complicated) is to allow the encoding specification with a taglib table property like this :
<display:setProperty name="export.csv.encoding" value="cp1252"/> (But I haven't found how to do this).
Frantz D.
this solution is the only one, that works for me.
I don't know why, but wrapper.getCharacterEncoding() always returns ISO-8859-1. The jsp page directive is ignored and I can't set charset to UTF-8. What's more, even if I set response encoding manualy to UTF-8 in another filter before ResponseOverrideFilter, it will be reset back to ISO-8859-1 after these lines in ExportDelegate.writeExport(...):
// clear headers
if (!response.isCommitted())
{
response.reset(); // <-- it will be reset here
}
The only working solution for me is this patch.