Set a contenttype using setContentType(String) after the page directive.
e.g.:
<@ page ...>
<%
response.setContentType("text/html;charset=UTF-8");
%>
Do this if possible as the very first thing in your page, but at least
before the
specified buffer is flushed for the first time.
Yep, that's what I do. I don't even let whitespace sneak its way to the
output before I do a setContentType.
> My problem specifically is that I have a JSP page which can dynamically
> select XSLT stylesheets to apply to XML. XSLT stylesheets call out
their
> output MIME type *and* character encoding in one of their tags. One
then
> typically includes HTML META tags that match this or, in the case of XML
> output, XSLT will declare the character encoding in the XML header of
the
> output.
Do not try the HTML META approach - it will not work as it is ignored by
the
engine.
You misunderstand me. I do this in addition to the stuff above to ensure
that the browser has no possibility of misunderstanding the character
encoding -- including after the HTML has been saved away to disk and then is
looked at later....
> With servlets, I simply do response.getOutputStream() and let the XSLT
> library create the correct Writer. With JSP, I get only a JspWriter,
whose
> character encoding I don't seem to have dynamic control over, i.e. I can
> declare it in a page declaration, but I can't say "give me a JSP writer
with
> an encoding of myXSLT.getCharEncoding()". How is this intended to work
in
> reality? DO NOT tell me I have to have 'n' JSP pages for all of my
intended
> character encodings (I only intend one but those using this stuff will
> declare any JVM-valid character encoding in their XSLT). Also, DO NOT
tell
> me that I have to reparse my XSLT output to remove this declaration and
> dynamically replace it with that specified by JSP.
>
> Along these lines, does JSP automatically HTML/XML escape characters
outside
> the bounds of the target character encoding??? For instance, if
outputting
> to Latin-1 are Japanese Unicode characters automatically escaped ala
Ɖ?
No, they aren't.
Sorry, I love Java and the idea of JSP, but the idea of not doing the
HTML/XML escaping for you but not allowing you to let XML tools decide the
encoding and do it for you is *insane*. JavaSoft needs to either add such
escaping to its JspWriter API and/or let one set the encoding of the
JspWriter in a reliable, spec-guaranteed way. The way the JSP spec suggests
an internationalization strategy in an appendix that does not even cover
these bases instead of thoroughly specifying it as a core requirement in the
body of the spec is *shameful*.
> Also, why can't I use an OutputStream from JSP? What if I want to
> dynamically create a GIF or a JPEG? In other words, no, such output
formats
> won't leverage JSP's template nature, but JSP could still be an
attractive
> way of getting a new dynamically generated servlet which called
utilities
> for such.
JSP was designed for textual data. I agree that one could produce binary
data with
it - but maybe then you should rather use a Servlet, just think of all
these
not
wanted newlines and tabs... a nightmare!
Yes and no. I currently am very careful to avoid such newlines and tabs
*now* as I don't want them creeping into XSLT output which while textual may
be whitespace sensitive (e.g. Excel Web Query format is one such example).
> I am mainly trying to understand *intent* on this matter, but I
> really *need* to understand how to synchronize character encodings
between
> dynamically selected XSLT pages and the JspWriter.
>
> What I am doing now, but haven't really tested is simply setting the
> Content-Type header to match my XSLT's MIME and encoding and then using
the
> JspWriter (for the first time, i.e. I don't even have blank lines before
> this) to dump the XSLT output. I have *zero* confidence that JSP
engines
> will parse this ContentType and use the encoding I really need them to
use
> when creating the JspWriter.
And you are right not to have that confidence.
The above mentioned approach is logical and definitely works with some,
maybe all
engines, BUT: it is not explicitly defined in the spec!
And I will state quite explicitly that the spec is clearly broken in this
regard!
Thanks for the info.
--
Jess Holle
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
