RE: XSLT and international characters in parameters

2002-04-03 Thread Tomasz Bech

After deep searching I found that all information were on the mail list, 
  but very distributed.
I think that the subject 'International characters in Tomcat/Cocoon' 
would be good to describe in FAQ (is very common question).

Maybe the content below can be good startup point.
How to setup Tomcat/Cocoon/Java to support fully Unicode (UTF-8)?

1. Problem - unicode characters in xsp/etc code.
add file.encoding to your JVM (for IBM -Dfile.encoding=UTF-8)
2. Problem - request parameters (for xsp/xsl/etc.):
a) use always

b) add filter to web.xml
below is a part of mail "RE: Tomcat and Unicode parameters in URLs ???" 
From: Larry Isaacs

 
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 Accept-Language header, or
based on attributes you have stored in the current session that indicate
what the user will be supplying.  A very simple example of such a filter
is included in the "/examples" webapp shipped with Tomcat 4 -- the source
code for this filter is in file SetCharacterEncodingFilter.java in the
$CATALINA_HOME/webapps/examples/WEB-INF/classes/filters subdirectory.
This example is fairly simpleminded -- you just configure a filter
initialization parameter that is used to set the encoding for all requests
-- but you can use it as a starting point for more sophisticated
processing by subclassing it and overriding the selectEncoding() method.

This filter can be enabled by copying the appropriate class file to your
own WEB-INF/classes directory, and adding a filter definition to your
web.xml file:

   
Character Encoding Filter
filters.SetCharacterEncodingFilter

encoding
UTF-8



Then, you select which requests this filter applies to with a filter
mapping -- the "/*" pattern says apply it to *all* requests:

   
Character Encoding Filter
/*


With filter mappings like this, you can be more selective about which URLs
it applies to by using a more precise URL pattern, or apply different
filters to different URLs -- all without affecting your servlets or JSP
apges at all.  The syntax for the  element in a filter
mapping is the same as that used for a servlet mapping.

Be sure to put these elements in the correct places in your web.xml file
to maintain the element order that is required by the DTD.
 >




I'm sure that it can be done simpler/better. Probably there are still 
some other problems which I didn't find. Post comments, ideas.

Tomasz



-
Please check that your question has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>




RE: XSLT and international characters in parameters

2002-04-02 Thread Vadim Gritsenko

> From: Tomasz Bech [mailto:[EMAIL PROTECTED]]
> 
> Hi all,
>   I found some request about this problem, but no answer.
>   Problem is: when form is in utf8, parameters are encoded as
utf8. But
> server always wants to treat them as iso-something.
> In XSP remedy is:
> 
>   ^^^

Yup.


> But problem appears when I try to use parameters in xsl (as  name='searchtext/>). No idea how to set encoding to proper one?

Try custom action.

 
> More questions:
> 2. Why server doesn't understand encoding of request parameters?

Sounds like question to your server. Is it tomcat? Try tomcat docs/user
list.


> 3. How to set encoding of request globaly (for all and forever)?

You can change encoding of the JVM if you either change locale of the OS
or provide "-D" parameter on the startup of the JVM (see JDK docs)

Vadim

>   Thanks,
>   Tomasz
> 


-
Please check that your question has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>