If you can live with the Servlet 2.2 spec, Tomcat 3.3 has a work around for this. The DecodeInterceptor can accept a URL like the following to specify the encoding as part of the URI:
http://localhost:8080/myapp/index.jsp;charset=UTF-8?param=value For details, see the charsetAttribute attribute of the DecodeInterceptor: <http://jakarta.apache.org/tomcat/tomcat-3.3-doc/serverxml.html#DecodeInterceptor> You are welcome to give it a try. Cheers, Larry > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Monday, March 18, 2002 8:50 PM > To: Tomcat Users List > Subject: Re: Tomcat and Unicode parameters in URLs ??? > > > > > On Tue, 19 Mar 2002, Soefara Redzuan wrote: > > > Date: Tue, 19 Mar 2002 09:20:47 +0800 > > From: Soefara Redzuan <[EMAIL PROTECTED]> > > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Subject: Re: Tomcat and Unicode parameters in URLs ??? > > > > > > >Setting the content type, as you did above, only affects > the *output* > > >of that particular response -- it has nothing to do with > how the next > > >*input* request from that browser will be handled. > > > > > >In order to deal with request parameters in an incoming > request, you > > >must tell Tomcat what encoding to use, *before* processing the > > >parameters. This is done by calling the > > >request.setCharacterEncoding() method that was added in > Servlet 2.3. > > >As long as you call this before calling methods like > > >request.getParameter(), the proper encoding will be applied. > > > > > >One way to do this without modifying your application itself is to > > >use a Filter that looks at incoming requests and decides what > > >encoding should be used -- perhaps by looking at the > > ><code>Accept-Language</code> header, or based on > attributes you have > > >stored in the current session that indicate what the user will be > > >supplying. > > > > But what happens if you really do not know what character set to > > expect ? In our company, the webserver is used for B2B > messaging with > > customers and not purely serving web pages. For example, we can > > accept a message with a query string like this > > > http://vpn.ourcompany.com/servlet/incoming?> company=CustomerName&refere > > nceId=1234¬eText= > > > > The noteText could be in one of several languages since we do > > international business. We're currently considering adding > a language > > parameter such as &Language=English but it would be nicer to > > autodetect the language. Is this possible ? > > > > It would be possible if the HTTP specs defined a way to tell > the server what language the HTTP URL is encoded in, and if > browsers actually sent along that indication. Neither seems > to be the case in general -- even on a POST transaction > (where the browsers really have no excuse for not including > the character encoding in the Content-Type header), many > don't. Thus, you're stuck haveing to figure it out for yourself. > > Note that adding a language parameter to the query string > isn't going to do you much good -- you have to call > setCharacterEncoding() *before* you call > request.getParameter(), so you won't have been able to read > the language field first. > > > Thank you, Soefara > > > > _________________________________________________________________ > > Craig > > > Join the world's largest e-mail service with MSN Hotmail. > > http://www.hotmail.com > > > > > > -- > > To unsubscribe: > <mailto:tomcat-user-> [EMAIL PROTECTED]> > > For > additional commands: > <mailto:[EMAIL PROTECTED]> > > Troubles with the list: > <mailto:[EMAIL PROTECTED]> > > > > > > > -- > To > unsubscribe: <mailto:[EMAIL PROTECTED]> > For additional commands: <mailto:[EMAIL PROTECTED]> > Troubles with the list: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
