You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Ben Flaumenhaft <Be...@brodia.com> on 2001/07/05 22:40:05 UTC

Encodings on form submits?

Folks,

I'm struggling with how to handle form submissions with non-Latin character
encodings using a Struts action and form beans.

As I understand it, browsers use the character encoding of the form's page
(hex-encoded) for submitting form parameters. I've seen plenty of code to
convert request parameters by hand, e.g.

        try
        {
            return new String(inParam.getBytes("8859_1"), encoding);
        }
        catch (UnsupportedEncodingException e) 
        {
            return inParam;
        }

... but this implies that you know the character encoding. Until Servlet 2.3
is standard, you can't just say request.setEncoding ().

So: how to do this in Struts? Ultimately, what I need is my form beans to
have their Strings set properly.

I can think of a few ways.

(1) Let the form bean handle it on set () methods for Strings. Every form
class could extend a base class with a decodeString (), and every form class
could call this method.

I'm not thrilled about this, since it'd be easy to forget and it's a lot of
extra coding on every set call.

(2) Modify Struts to do this automatically. This isn't trivial, since the
calls to populate beans 
are buried pretty deeply in ActionServlet, RequestUtils, and BeanUtils. 

In either case, the handler (whether Struts utils or the beans themselves)
would need to know the encoding to use! The best I can come up with is that
every form would embed a hidden parameter "encoding" -- this is how iPlanet
handles this, they have a j_encoding parameter on forms which tells the
handler how to decode params. (I could modify html:form to do this
automatically, too ...)

Thoughts?

Thanks,
Ben


Re: Encodings on form submits?

Posted by Martin Cooper <ma...@tumbleweed.com>.
I know this is an old post, but better late than never... :-)

We are doing the following:

1) Specify the content type for the JSP output:

    <%@ page contentType="text/html; charset=utf-8" %>

You can also do this by setting the content type header manually, using
response.setContentType().

2) Specify the content type to the browser:

    <meta http-equiv="content-type" content="text/html; charset=utf-8">

3) Specify the default content type to the container. In our case, we are
using Resin, and so do this:

    <web-app id='/' character-encoding='utf-8' ... >

The first ensures that the JSP page is treated as UTF-8, which can represent
all the characters you need. The second ensures that the browser knows that.
Since the browser uses the encoding of the page to send form data,
submissions will now use UTF-8. The third ensures that the container
interprets all submissions as UTF-8.

Other than figuring it out in the first place :-) we have had no problems
with this. We can correctly display, and interpret input, in any language -
Chinese, Japanese, European languages, etc.

--
Martin Cooper


----- Original Message -----
From: "Ben Flaumenhaft" <Be...@brodia.com>
To: <st...@jakarta.apache.org>
Sent: Thursday, July 05, 2001 1:40 PM
Subject: Encodings on form submits?


>
> Folks,
>
> I'm struggling with how to handle form submissions with non-Latin
character
> encodings using a Struts action and form beans.
>
> As I understand it, browsers use the character encoding of the form's page
> (hex-encoded) for submitting form parameters. I've seen plenty of code to
> convert request parameters by hand, e.g.
>
>         try
>         {
>             return new String(inParam.getBytes("8859_1"), encoding);
>         }
>         catch (UnsupportedEncodingException e)
>         {
>             return inParam;
>         }
>
> ... but this implies that you know the character encoding. Until Servlet
2.3
> is standard, you can't just say request.setEncoding ().
>
> So: how to do this in Struts? Ultimately, what I need is my form beans to
> have their Strings set properly.
>
> I can think of a few ways.
>
> (1) Let the form bean handle it on set () methods for Strings. Every form
> class could extend a base class with a decodeString (), and every form
class
> could call this method.
>
> I'm not thrilled about this, since it'd be easy to forget and it's a lot
of
> extra coding on every set call.
>
> (2) Modify Struts to do this automatically. This isn't trivial, since the
> calls to populate beans
> are buried pretty deeply in ActionServlet, RequestUtils, and BeanUtils.
>
> In either case, the handler (whether Struts utils or the beans themselves)
> would need to know the encoding to use! The best I can come up with is
that
> every form would embed a hidden parameter "encoding" -- this is how
iPlanet
> handles this, they have a j_encoding parameter on forms which tells the
> handler how to decode params. (I could modify html:form to do this
> automatically, too ...)
>
> Thoughts?
>
> Thanks,
> Ben
>
>