Hi,
I found the portion of the code which add charset string specified in pageEncoding when charset is not specified in contentType in the jasper source code Varidator.java.
public static void validate(Compiler compiler, Node.Nodes page) throws JasperException {
/* * Visit the page/tag directives first, as they are global to the page * and are position independent. */ page.visit(new DirectiveVisitor(compiler));
// Determine the default output content type PageInfo pageInfo = compiler.getPageInfo(); String contentType = pageInfo.getContentType();
if (contentType == null || contentType.indexOf("charset=") < 0) { boolean isXml = page.getRoot().isXmlSyntax(); String defaultType; if (contentType == null) { defaultType = isXml? "text/xml": "text/html"; } else { defaultType = contentType; }
String charset = null; if (isXml) { charset = "UTF-8"; } else { if (!page.getRoot().isDefaultPageEncoding()) { charset = page.getRoot().getPageEncoding(); } }
if (charset != null) {//====== here ======== pageInfo.setContentType(defaultType + ";charset=" + charset); } else { pageInfo.setContentType(defaultType); } }
Can I skip or override this action by doing something in jsp code, or by other means except rebuilding tomcat?
I still don't understand why this action is necessary. If so, I think there should be the way to stop it.
The action is described in JSP spec's.
I think not adding ";charset=ISO-8859-1" does not break the spec's and fixes your problem.
Seiji.
Hi Jan,
Thank you for your reply.
I read the section of the specification. But something is not clear to me.
I have to specify pageEncoding attribute to tell jasper what character encoding is used in the jsp page. At the same time, I have to specify
exact HTTP header content-type string so that Web browser get the right
application. Why the specification deny it?
(I don't want to change coding syntax only for this reason.)
I think pageEncoding attribute should not be used to form content-type
string because you can specify charset string by other means if necessary.
This will happen not only for PDF files but image files or what ever.
Am I wrong?
seiji takegata wrote:
Hi,
I'm trying to generate PDF document from JSP, using itext library.
(http://www.lowagie.com/iText/)
I set contentType attribute to get browser open AdobeReader, and pageEncoding to get right encoding for Japanese characters,
<%@ page contentType="application/pdf" pageEncoding="Shift_JIS" %>
Jasper translates this line to;
response.setContentType("application/pdf;charset=Shift_JIS");
I want to set response type to look like PDF without any particular encoding, and to tell Jasper that my source encoded with "Shift_JIS", because IE does not recognize the contentType if charset option is added.
My question is: 1. Why Jasper adds charset option when I specify pageEncoding attribute? 2. Can I make Jasper not to add charset option when I use pageEncoding?
I posted same question to tomcat-user ML, then I was suggested to post this question to tomcat-dev list.
This is my first message to this list.
Notice that this is consistent with the JSP 2.0 spec (see JSP.4.2: "Response Character Encoding"):
The initial response char encoding is set to the CHARSET value of
the contentType attribute of the page directive. If the page doesn't
provide this attribute or the attribute does not have a CHARSET value
[as in your case], the initial response char encoding is determined as
follows:
* ...
* For JSP pages in standard syntax, it is the character encoding specified
by the pageEncoding attribute of the page directive ...
The reason behind this is that if the page specifies a page character encoding (other than ISO-8859-1), it probably contains non-Latin characters that may get lost if the response switched to another char encoding.
If this is not what you want, you should consider using XML syntax for your JSPs, in which case the response char encoding is set to UTF-8 (under the above circumstances), regardless of the autodetected page source encoding.
Jan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
