Re: Problem with BAction

A couple of comments:

Once we move to using the new encode function, we must then handle the
possibility of a UnsupportedEncodingException being thrown here. It
would actually be nice if that were thrown on the setEncoding(String
enc), that Christian mentioned below.

DefaultServletRequestWrapper extends
javax.servlet.ServletRequestWrapper, which already has
getCharacterEncoding and setCharacterEncoding methods. These should be
used when calling the URLDecoder.decode method.

As much as I agree with Christian, that if no character encoding is set
we return UTF-8. I also think that we may want to be consistent with
the getCharacterEncoding and setCharacterEncoding methods in
HttpServletRequest and ServletRequestWrapper, which return the encoding
type returned by System.getProperty("file.encoding").

Denny

Christian Cryder wrote:

Ok, here's what I'd like to recommend -

1. I think we need to create a method in BComponent called
setEncoding(String enc)

2. calling getEncoding() would look to see if current encoding is set,
if not return the parent encoding (which would iterate up the chain).
If there is no encoding specified, "UTF-8" would be used. THis
basically gives us the ability to set the encoding for an entire
component structure, or just a subset.

3. we can then modify the renderers to take advantage of the encoding
by querying the components.

I think this should pretty much solve Denny's problem.

Now I have an additional question - searching the code to see where
else we reference encodings, I found this block of code in
DefaultServletRequestWrapper:

//csc_110102.1_start - fix deprecation issues

//csc_110402.1 - revert

//jrk_20030731.1_start - catch runtime exceptions in the decode() method

try {

queryString =
java.net.URLDecoder.decode(queryString);

} catch (Exception e) {

logger.warn("failed to decode queryString, but
allowing to continue", e);

}

//jrk_20030731.1_end

/*

try {

queryString =
java.net.URLDecoder.decode(queryString, "UTF-8");

} catch (UnsupportedEncodingException e) {

System.out.println("Encoding Exception: "+e);

e.printStackTrace();

}

*/

//csc_110102.1_end

What I'm trying to understand here is this - it looks like we
originally changed the code so as to specify UTF-8 (and thus not use
the deprecated method). Then it looks like Jake changed it back to the
default method (which is deprecated).

Does anyone remember why we did this???? I have a feeling there is a
reason, and I'm reluctant to just change it back without understanding
the implications...

THanks,

Christian

Denny Chambers wrote:

Hi
ALL

I have run across a problem in the BAction class. In my Barracuda
webapp, I am sending all data to the browser as UTF-8, however my local
Operating System which is running my webapp server may be in different
character encoding formats, such as UTF-8, CP1252, ISO-8859-1, etc. Now
when my OS is in UTF-8, I don't have any real problem sending extended
characters (Characters outside of the ASCII range, i.e. greater than
decimal 127). But when I am in a different code page like CP1252, I run
into a problem sending extended characters in URLs created by
BLink/BAction. In the method BAction.getAction(...) the parameter list
is passed to the java.net.URLEncoder.encode(String s). For one, this
method had been deprecated in favor of the
java.net.URLEncoder.encode(String s, String enc) method which allows
you to encode the String based on a particular character encoding
format. Since Barracuda is using the older encode method, which takes
no encoding parameter, the encoding is being done based on the JVM
default encoding, which is set as a system parameter "file.encoding".
This means the non-ASCII characters in my URL parameters are getting
coded using the byte sequence from the default OS character encoding,
instead of the UTF-8 character encoding I want. It looks like the
BAction classes need to allow for an encoding parameter to be
specified, so that URL encoding is done properly.

FYI - The W3C recommends that character encoding be done based on a
UTF-8 character set -
http://www.w3.org/TR/html40/appendix/notes.html#non-ascii-chars

Thanks,

--

Foo bar rama

Christian

----------

Christian Cryder

Internet Architect, ATMReports.com

----------

"Coffee? I could quit anytime, just not
today"

http://seelifedifferently.blogspot.com

--
=========================================================
Denny Chambers

Unix IS user friendly - it's just picky about it's friends.