tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: pageEncoding and Jasper
Date Fri, 08 Feb 2002 08:27:42 GMT
From: "Craig R. McClanahan" <>
Subject: Re: pageEncoding and Jasper
Date: Thu, 7 Feb 2002 20:02:00 -0800 (PST)
Message-ID: <>

> > > If "it" is the pageEncoding attribute of the <%@ page %> directive, then
> > > the answer is yes.
> >
> > Craig, the answer is "no".
> Well, that's not the answer given by the JSP Specification ;-).

At this point, I agree with you. So, I should say "partially no".
There are 2 phases from .jsp to .class, the first one is from 
.jsp to .java, and the second is from .java to .class. The pageEncoding
attribute is applied to the first phase only as the JSP Specification
stated, and for the second phase, container applies UTF-8 only.

> In the JSP 1.2 spec, see section 2.10.1, Table JSP.2-1, bottom of page 52,
> where the "pageEncoding" attribute is defined:
>   Defines the character encoding of the JSP page.

I've read this, and I knew the role of the pageEncoding attribute.
Though it is convenient that .java is written by UTF-8 because .java
file becomes completely readable, I believe that the unicode escape is
more natural in Java. Besides, container doesen't need any encoding
information from .java to .jsp if non-ascii characters are converted
to the unocde escape. Why the JSP Specification doesn't mention about
UTF-8 is used internally. Is this a Tomcat specific technique ?

> If you want to tell the container what character encoding to send on a
> response, use the "contentType" attribute of the <%@ page %> directive:
>   <%@ page contentType="text/html;charset=UTF-8" %>

I appreciate this function. The appropriate encoding management is that
every encodings in every phases including an input/output stream should
be controllable. 
And now, JSP pages became to be a platform independant document.

> I had to do this in my Struts demo at JavaOne Japan, for example, in
> order to display the Japanese characters correctly.  Setting pageEncoding
> would not have done this.

If the pageEncoding is not set, container applies encoding specifed in
contentType attribute, isn't it ? And, if the contentType is not set or
has no charset part, container applies ISO-8859-1 as I think UTF-8 
should be applied. UTF-8 is the most suitable encoding for a default,
because it is a language independent encoding.

Yoko Kamei Harada, Web Studio Ne-Po-Le

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message