>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&noteText=

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]>

Reply via email to