Asgaut wrote:
I have recently been struggling with a utf-8 to ISO-8859-1 problem with Ajax
and Struts2.

The problem is basically that our application requires iso-8859-1 characters
and Ajax is configured to only post utf-8 (ajax is utf-8 either way, can not
be changed). So some kind of conversion has to take place at some level.

My problem can be divided into two parts:
1. Make Struts2 understand that there is a incoming utf-8 POST, even though
struts.xml (which set the struts2 default encoding) is configured to use
iso-8859-1
2. Convert the characters from utf-8 to iso-8859-1

3. Change your default encoding to utf-8, which should have no effect on any of your code but will allow greater flexibility in the range of characters you can display and read. Is there any reason you must use iso-8859-1?

[...]

If you take a look at this piece of code, you can see that it overrides the
encoding if it is set as defaultEncoding (from struts.xml). This is OK, the
problem is this check:
if (encoding != null) {
            try {
                request.setCharacterEncoding(encoding);
            } catch (Exception e) {
                LOG.error("Error setting character encoding to '" + encoding
+ "' - ignoring.", e);
            }
        }

I think the correct thing would be to also do a check if the
request.getCharacterEncoding was already set. I should look like this:
if (encoding != null && request.getCharacterEncoding() == null ) {
            try {
                request.setCharacterEncoding(encoding);
            } catch (Exception e) {
                LOG.error("Error setting character encoding to '" + encoding
+ "' - ignoring.", e);
            }
        }
With this change utf-8 would be kept as the request character encoding and I
could do my conversion in my interceptor.
This would solve my problem number 1. Am I correct when I say this is a bug?

I don't know if I'd call that a bug, but it does seem like a reasonable enhancement. It would probably require some testing with different browsers to make sure getCharacterEncoding() really is returning null in the 'normal' cases, but assuming that's true you could open a ticket in JIRA and attach a patch.

The way I went around it was to create a filter which is executed before
FilterDispatcher in struts2. In this filter I check if it is a uft-8 post
and if it is, I wrap the HttpServletRequest into my own
CharsetRequestWrapper. In my wrapper I will override getParameterMap which
converts my characters, put them back into the map and return them. I also
run a req.getParameter("foo"); after my wrapping to populate the parameters
on the request.

It works, but it took me a couple of days to work it out.

Any comments on this?

It might be simpler for your filter to call setCharacterEncoding("utf-8") and use a trivial request wrapper that delegates all calls to the wrapped request *except* setCharacterEncoding(), making that a no-op. It would make it clearer what the filter was acutaly doing with less code :-) Otherwise, seems like a reasonable work-around.

L.


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

Reply via email to