DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4806>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4806 include HTML page encoding problem [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From [EMAIL PROTECTED] 2001-11-16 10:07 ------- When you use RequestDispatcher.include() or <jsp:include>, it is the responsibility of the included resource (not the servlet container) to return exactly what you want. In the case of static resources served by DefaultServlet, that would require the addition of a non-standard way to indicate the desired character set (perhaps by adding a request parameter on the include) -- and this would be Tomcat-specific because there is no such mechanism defined in the servlet API, so your application would not be portable to any other server. An alternative approach would be to define your own servlet that served out static content, but *did* take a request parameter to define the character set requested. This would be pretty simple logic: * Determine the path of the desired resource via request.getPathInfo() * Call ServletContext.getResourceAsStream() to get an InputStream to the resource * Determine which character encoding is required from a request parameter * Build an InputStreamReader (with the desired character encoding) around the InputStream acquired earlier * Copy the characters from the InputStreamReader to the response writer for this response. In this way, you would be insulating your application from relying on a platform specific feature. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
