>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&referenceId=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 ? Thank you, Soefara _________________________________________________________________ Join the world�s largest e-mail service with MSN Hotmail. http://www.hotmail.com -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
