I have a question about jsp:include's specification & implementation.
JSP 1.1 specification says "Content is not parsed; it is included in
place." in "2.7.5 Including Data in JSP Pages".
But current Tomcat 3.2b8 implementation convert its contents from Java
VM's native character encoding to the specified charset in the case
that charset is specified in content-type header.
Is this behavior right? I think that a character set conversion is a
kind of parsing and it may produce errors.
By my guess, a "jsp:include" action calls include method of
RequestDispatcher class, and it probably calls StaticIntercepter class
finally.
And StaticIntercepter create Reader according to Java VM's native
character encoding.
if( res.isUsingWriter() ) {
InputStreamReader r = new InputStreamReader(in);
PrintWriter out=res.getWriter();
Therefore, conversion error is occured when output charset isn't the
same as Java VM's native character encoding.
In Japan, it is a general case to use many character encodings
(ISO-8859-1, ISO-2022-JP, Shift_JIS etc.).
cf.
InputStreamReader(in)
= InputStreamReader(in, ByteToCharConverter.getDefault())
For example, the following is a simple JSP program that switch HTML
files according to browser's accept-language header such as apache's
Multiviews directive. A japanese HTML file's charset is euc-jp.
This program works well on Solaris 2 (Java VM's native character
encoding is euc-jp), but don't work on Windows (Java VM's native
character encoding is MS932) because conversion error is occured.
<%@ page import="java.util.Locale" %>
<%
String language = "en";
String file = "index.html";
Locale locale = request.getLocale();
if (locale != null) {
language = locale.getLanguage();
}
if (language.equalsIgnoreCase("ja")) {
response.setContentType("text/html; charset=euc-jp");
file += ".ja";
} else {
response.setContentType("text/html");
}
%>
<jsp:include page="<%= file %>" flush="true"/>
Kazuhiro Kazama ([EMAIL PROTECTED]) NTT Network Innovation Laboratories
