Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@www.apache.org Received: (qmail 50355 invoked from network); 21 Jul 2004 16:18:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 21 Jul 2004 16:18:22 -0000 Received: (qmail 45846 invoked by uid 500); 21 Jul 2004 16:17:58 -0000 Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org Received: (qmail 45743 invoked by uid 500); 21 Jul 2004 16:17:57 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 45720 invoked by uid 99); 21 Jul 2004 16:17:56 -0000 X-ASF-Spam-Status: No, hits=1.1 required=10.0 tests=NO_REAL_NAME,UPPERCASE_25_50 X-Spam-Check-By: apache.org Received: from [192.18.33.10] (HELO exchange.sun.com) (192.18.33.10) by apache.org (qpsmtpd/0.27.1) with SMTP; Wed, 21 Jul 2004 09:17:55 -0700 Received: (qmail 26274 invoked by uid 50); 21 Jul 2004 16:19:20 -0000 Date: 21 Jul 2004 16:19:20 -0000 Message-ID: <20040721161920.26273.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: tomcat-dev@jakarta.apache.org Cc: Subject: DO NOT REPLY [Bug 28875] - Multi-byte characters in default error page aren't printed out correctly. X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28875 Multi-byte characters in default error page aren't printed out correctly. ------- Additional Comments From moriyoshi@at.wakwak.com 2004-07-21 16:19 ------- I haven't been looking into this problem much and maybe I'm wrong somewhat. Regarding the latest patch, I'm wondering if there is any reason to drop setLocale() from that portion. Invocation of either setCharacterEncoding() or setContentType() that precedes setLocale() seems to prevent setLocale() from changing the character encoding for the request. --------------------------------------------------------------------- To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org