Re: WO 5.4 form value encoding problem
Re: WO 5.4 form value encoding problem
- Subject: Re: WO 5.4 form value encoding problem
- From: Kenny Leung <email@hidden>
- Date: Tue, 24 Jun 2008 21:45:22 -0700
Hi Ryan.
Thanks! I just tried this myself, and it works. My problem was not
reading the documentation closely enough. (I blame myself) Zooping
through the docs lead me to this page:
http://java.sun.com/j2se/1.5.0/docs/guide/intl/encoding.doc.html
and I used the name for the old API instead. If there is a bug here,
it's that WOResponse's auto detection doesn't work for ISO8895 encoded
input.
Note that the above page gives the Java names for these encodings,
which I think are based on, but may not be exactly be the same as, the
same names you would use in your html file. I found what I think is
the gospel on encoding names via the W3C:
http://www.iana.org/assignments/character-sets
In the final analysis, going all UTF-8 is probably the way to go to
avoid problems - we have to deal with Chinese and Japanese scripts as
well, so ISO-Latin wouldn't cut it anyway. The only real way to do
that is to add the meta charset tag into the head. You can add accept-
charset to the form and it makes it to the app OK, but when it comes
back to the page it will be all garbled.
For my own edification I wrote a little test WO app to try out all of
the options, which are too numerous (32) for me to want to list here.
For fun, you can find it at
http://www.surfshaksoftware.com/FreeSoftware/Encoding.tar.gz
-Kenny
On Jun 24, 2008, at 4:00 PM, Ryan Klems wrote:
FWIW: I have no issues doing this:
public static void main(String argv[]) {
WOMessage.setDefaultEncoding("ISO-8859-1");
WOApplication.main(argv, Application.class);
}
And having a simple page (foo is just a String in the page, and
goHome just return's null)
<html>
<head>
<title>Test</title>
</head>
<body>
<wo:WOForm>
<wo:textfield value="[foo]"/>
<wo:submit action="[goHome]"/>
</wo:WOForm>
</body>
</html>
And having the é come across just fine into and out of the app...
Using tcpdump, I can see that its passed by the browser as é
POST /cgi-bin/WebObjects/Test.woa/wo/oEUseaM6zFY3cBCQ9labIg/0.1 HTTP/
1.1
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_4; en-us)
AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.2 Safari/525.20.1
Content-Type: application/x-www-form-urlencoded
Referer: http://rk-mbp.local:8000/cgi-bin/WebObjects/Test.woa
Accept: text/xml,application/xml,application/xhtml+xml,text/
html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Content-Length: 47
Connection: keep-alive
Host: rk-mbp.local:8000
1.1=é&1.3=Submit&wosid=oEUseaM6zFY3cBCQ9labIg
So I don't think its a bug in WO, but if you feel otherwise, please
do file a bug.
-Ryan
On Jun 24, 2008, at 2:50 PM, Ryan Klems wrote:
I don't claim to be any expert in encodings, but are you sure
ISO8895_1 is a valid encoding name, or even the encoding that you
want? Are you trying to get ISO-LATIN-1 or ISO-8859-1 ?
-Ryan
On Jun 24, 2008, at 2:30 PM, Kenny Leung wrote:
Hi All.
So, after extensive testing with my little HelloWorld app, these
are the results:
The only thing that seems to work is setting <meta
charset="UTF-8"></meta> in the head of the document. Setting
accept-charset="UTF-8" in the form does not seem to do anything.
I overrode WOApplication.dispatchRequest() to turn
isFormValueEncodingDetectionEnabled() on and off, and the
behaviour does change, but it's wrong both ways. I also tried
using setDefaultFormValueEncoding("ISO8895_1"), and it did change
the behaviour, but it was always the wrong behaviour. It seems
that the only thing that works is to go along with the default
UTF-8 behaviour.
-Kenny
On Jun 24, 2008, at 2:07 PM, Daryl Lee wrote:
Is WORequest.isFormValueEncodingDetectionEnabled() turned on?
What happens if you turn it off/on?
On Jun 23, 2008, at 10:16 AM, Kenny Leung wrote:
Hi All.
I've bumped into an incompatibility between WebObjects 5.3 and
5.4. In 5.3, I could submit a form value with non-ASCII
characters, and their encoding would be correctly interpreted.
In 5.4, the encoding is misinterpreted.
I printed out the actual request contents, and, for instance e-
acute is sent as é, which as far as I know is correct ISO8859
encoding. I read in the release notes that WO 5.4 now defaults
to UTF8 encoding, so I tried to change the request's
defaultFormValueEncoding to ISO8859_1. Then it got interpreted
as a literal é!
Can anybody shed some light on this? I have searched the lists
and the Google, and have come up empty.
Thanks!
-Kenny
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden