Encodings on form submits?

2001-07-05 Thread Ben Flaumenhaft


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?

2001-07-05 Thread RUCH,SCOTT (HP-NewJersey,ex2)


Ben,

Thanks for asking this question - this is almost
exactly the question I posted yesterday.  I didn't get
an answer ;-) but perhaps we can generate some interest
if we keep bringing it up.

The form bean user is out in the cold right now.  Even
with setEncoding() in 2.3, it still has to be called
before the POST data is processed.  By the time the
action servlet gains control, the conversion has happened.

I suggested (like you did) that perhaps the best
place to do this is as an "encoding" tag attribute in the form,
or the individual text tags, etc.

Right now, I rely on app-server specific features to 
set the encoding of POST data on a per-web-application
basis.  I wouldn't mind a similar mechanism in the struts-config
file.  That would be much more portable than what I'm
doing now.

Scott

> -Original Message-
> From: Ben Flaumenhaft [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, July 05, 2001 4:40 PM
> To: '[EMAIL PROTECTED]'
> 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
> 



Re: Encodings on form submits?

2001-07-25 Thread Martin Cooper

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:



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



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" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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
>
>





RE: Encodings on form submits?

2001-09-05 Thread Simon Liang

Hello all:

I have combined both Martin and Jonathan suggestion as i have weblogic 5.1
with SP9. But still can't get input of chinese to work. when i display the
inputed chinese on the resulting jsp page,  it's not readable.

I am using 'utf-8' all the way(on all jsp pages, input and output). I
followed step 1 & 2 on the jsp page level. For step 3, i added the following
to my web app's web.xml file:



weblogic.httpd.inputCharset./*
UTF-8

...


I even followed the weblogic 5.1 sp9 doc and added the following to the
weblogic.properties file:
weblogic.httpd.inputCharset./*=UTF-8

Still no luck on capturing chinese input. I can display chinese fine on the
jsp pages when reading the keyed value from Resource bundle properties
files.

Please help? Am i missing something.
TIA
Simon



-Original Message-
From: Martin Cooper [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 25, 2001 6:37 PM
To: [EMAIL PROTECTED]
Subject: Re: Encodings on form submits?


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:



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



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" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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
>
>

You must configure your web application to DECODE the utf8 encoded stuff.
In weblogic I make this entry in the web.xml file:



weblogic.httpd.inputCharset./*
UTF-8



I'm not sure what you need for tomcat configuration

QUOTING AN E-MAIL FROM HANS BERGSTEN

8859-1 is [currently] the default
encoding of HTTP. When a browser sends a parameter in some encoding, such
as UTF-8, it encodes each character byte value as a hexadecimal string using
the encoding for the page (e.g. UTF-8). At the server, however, the part of
the container that interprets these character values always assumes they
are 8859-1 byte values. So it created a Unicode string based on the byte
values interpreted as 8859-1. In the Servlet 2.3 spec

RE: Encodings on form submits?

2001-09-05 Thread Simon Liang

Hello,

Sorry for mine post again and lack of knowledge on utf-8.

It appears that Martin and Jonathan suggested way of utf-8 encoding on
submit is good when Martin's 3 steps(see below) is followed. However, i
found it's the Strut tag that's _NOT_ handling the utf-8 encoding correctly.
I outputted the following on my result jsp after the chinese is inputted:

Here, the 'name' is inputted in Chinese and encoded as utf-8:


 With the Bean Write tag 
NAME=> 
password ==>

 With the standard Http request object 
Name==><%= request.getParameter("name")%>
password==><%= request.getParameter("password")%>

With the bean:write tag the name is printed out as , while the standard
request object display the chinese characters correctly.

Can someone clarify why this is the case? I thought this would not matter
since reflection is doing the same call using
request.getParameter("property") to map the input to the form's property.

TIA,
Simon





-Original Message-
From: Simon Liang [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 05, 2001 11:16 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Encodings on form submits?


Hello all:

I have combined both Martin and Jonathan suggestion as i have weblogic 5.1
with SP9. But still can't get input of chinese to work. when i display the
inputed chinese on the resulting jsp page,  it's not readable.

I am using 'utf-8' all the way(on all jsp pages, input and output). I
followed step 1 & 2 on the jsp page level. For step 3, i added the following
to my web app's web.xml file:



weblogic.httpd.inputCharset./*
UTF-8

...


I even followed the weblogic 5.1 sp9 doc and added the following to the
weblogic.properties file:
weblogic.httpd.inputCharset./*=UTF-8

Still no luck on capturing chinese input. I can display chinese fine on the
jsp pages when reading the keyed value from Resource bundle properties
files.

Please help? Am i missing something.
TIA
Simon



-Original Message-
From: Martin Cooper [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 25, 2001 6:37 PM
To: [EMAIL PROTECTED]
Subject: Re: Encodings on form submits?


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:



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



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" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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 Bea