[
http://jira.codehaus.org/browse/DISPL-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=193661#action_193661
]
Lukasz Palka commented on DISPL-471:
------------------------------------
Hi guys,
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.
> Patch to allow displaytag users to specify the target encoding of export files
> ------------------------------------------------------------------------------
>
> Key: DISPL-471
> URL: http://jira.codehaus.org/browse/DISPL-471
> Project: DisplayTag
> Issue Type: New Feature
> Components: Export
> Reporter: Frantz DEGRIGNY
> Original Estimate: 30 minutes
> Remaining Estimate: 30 minutes
>
> 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 message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
displaytag-devel mailing list
displaytag-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/displaytag-devel
