This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: XSL and international characters


> From: owner-xsl-list@lists.mulberrytech.com
> [mailto:owner-xsl-list@lists.mulberrytech.com]On Behalf Of Mike Brown
> Sent: Tuesday, December 04, 2001 9:34 PM
> To: xsl-list@lists.mulberrytech.com
> Subject: Re: [xsl] XSL and international characters
>
>
> Marcin K_os wrote:
> > Well, I agree that those are characters are in UTF-8 and that I wanted
> > characters in UTF, the problem is that I passed as parameter
> one two-bye
> > character and each byte of those two was transformed again into
> two-byte
> > characters giving in result four bytes i.e., two two-byte characters.
> >
> > Orginal character was %C5%82 and the result was Å - one
> character and
> > ‚ - second character :(
>
> Everyone else seems to have missed your point. You are running into
> an issue with an underspecified part of the URI, HTTP and HTML specs:
> there is no standard mechanism for declaring what encoding is being
> used when representing non-ASCII characters (x80 and above) in the
> %-escaped format used in URIs and HTML form data submissions.
>
> Tomcat interprets %C5%A2 in the HTTP request as bytes C5 A2, and
> exposes them through the Java/JSP API as 2 chars in a String
> according to an assumed (and probably wrong) iso-8859-1 encoding.
>
> On the receiving end, you must convert these chars back into bytes,
> assuming iso-8859-1, and then convert them to a String again, this
> time assuming UTF-8. I did this in JSPs with WebLogic a while back,
> and it was pretty straightforward. I'm not sure how it works with
> your particular Tomcat/Cocoon setup, though.

It definitively also depends on the Tomcat version. We recently found that
Tomcat 3.3 attempts to detect the URI encoding on the request URI (and fails
in at least some cases). Even worse, the servlet won't see the original
value of the request URI and won't be unable to do proper decoding on it's
own ([1]). I think this slipped in a few days before the final 3.3 release.


[1] <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4416>



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]