We're using a JSP page with a declaration like:
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"%>
...and textarea within a form, containing a template request document.
However, even after changing the browser's (FF-2, or IE) default
character encoding to iso-8859-1 AND changing the FORM tag like:
<form action="./index.jsp" method="post" name="theForm"
enctype="application/x-www-form-urlencoded; charset=ISO-8859-1"
accept-charset="ISO-8859-1">
</form>
A sniffer shows that when the browser first loads the page (GET), it
sends,
"Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7"
...but when the form is posted, it only sends:
"Content-type: application/x-www-form-urlencoded"
(note, it's without the "; charset=iso-8859-1" sub-value)
On the other hand, this w3.org document states that HTTP-1.1 implies a
default encoding of iso-8859-1, rather then utf-8, so even the above
mentioned steps should not have been necessary, correct?
http://www.w3.org/International/O-HTTP-charset
Does this mean there's no way to test an iso-8859-1 request
document containing accented characters using an HTML FORM POST?
i.e. We can only use a programmatic client?
Thanks,
-Chris W.
-----Original Message-----
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 20, 2008 11:23 AM
To: [email protected]
Cc: Wolf, Chris (IT)
Subject: Re: Dealing with non-UTF-8 messages
Chris,
On Wednesday 20 August 2008 4:50:52 am Wolf, Chris (IT) wrote:
> From looking at the SOAP spec, it seems that it's the responsibilty of
> the transport to indicate the encoding, as these samples show:
>
> http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383490
>
> Note the "Content-Type:" HTTP header.
>
> Also note that the SOAP spec explicitly states that SOAP messages MUST
> NOT (their emphasis) contain processing instructions (e.g. the
> "<?xml...?>"
> declaration)
>
> http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383492
>
>
> I wonder if we change our client to set the outboud content-type
> header to indicate the encoding, if this will fix it. I will look
> into this angle.
Yes, that is the proper fix. The charset in the Content-Type header is
what
is used to create the parser. Thus, you need to make sure the client
sets
the proper charset there.
Dan
> Thanks,
>
> -Chris W.
>
>
> -----Original Message-----
> From: Benson Margulies [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 19, 2008 10:16 PM
> To: [email protected]
> Subject: Re: Dealing with non-UTF-8 messages
>
> This is not a current feature of CXF. If the messages had prologs with
> encodings, all would work.
>
> Better, put an interceptor at the front to transcode to UTF-8 or add
> prologs?
>
> Can you tell us if this problem is specific to some app of yours or
> more generic, to help motivate (or not) effort?
>
> On Tue, Aug 19, 2008 at 4:47 PM, Wolf, Chris (IT)
>
> <[EMAIL PROTECTED]> wrote:
> > We now have some messages that contain iso-8859-1 (but non-ascii)
> > characters, which apparently, are not UTF-8, e.g. accented
> > characters used in Spanish and/or French. These are causing
> > exceptions citing invalid UTF-8 character sequences.
> >
> > I was able to eliminte one source by explicitly setting the encoding
> > to "iso-8859-1"
> > in the parser of one of our interceptors, but not the error simply
> > migrated to one of the CXF built-in interceptors. Is there a way to
> > globally set the encoding?
> >
> > I searched the FAQs and list archives and found nothing helpful.
> >
> > Thanks,
> >
> > -Chris W.
> > --------------------------------------------------------
> >
> > NOTICE: If received in error, please destroy and notify sender.
> > Sender
>
> does not intend to waive confidentiality or privilege. Use of this
> email is prohibited when received in error.
>
> --------------------------------------------------------
>
> NOTICE: If received in error, please destroy and notify sender. Sender
> does not intend to waive confidentiality or privilege. Use of this
> email is prohibited when received in error.
--
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
--------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not
intend to waive confidentiality or privilege. Use of this email is prohibited
when received in error.
