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=10671>. 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=10671 Major issues with jsp:param in jsp:include and jsp:forward ------- Additional Comments From [EMAIL PROTECTED] 2003-10-23 01:30 ------- I agree that passing non-ISO-8859-1 characters (or whatever your platform default is) via <jsp:param> is broken in 4.1.27. A suggested work-around: While this work-around won't be suitable for all applications, it is handy where an included page (or a page that is always the target of a forward) wants to receive characters that would otherwise not work. Basically encode the value of the parameter into something that can be represented in ISO-8859-1 before passing it to <jsp:param>, and then do the reverse encoding in the called page. Using Java 1.4's URLEncoder.encode (string, "UTF-8") before giving the string to <jsp:param> is one such encoding that does this. This causes: [non ISO-8859-1 suitable string] (encode using URLEncoder.encode(string, "UTF-8")) [string that can be represented in ISO-8859-1] (pass to <jsp:include> or <jsp:forward> via <jsp:param>) (Tomcat calls URLEncoder.encode(string)) (Tomcat calls the included or forwarded page) (Tomcat calls URLEncoder.decode(string)) [string that can be represented in ISO-8859-1] (decode using URLDecoder.decode(string, "UTF-8")) [original string] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
