[Seaside] WAUrl class>>#decodePercent:

[Philippe Marschall]

On Fri, Aug 30, 2013 at 9:27 PM, jtuchel at objektfabrik.de
<jtuchel at objektfabrik.de> wrote:
> Okay, this message costs me some courage now ;-)
>
> Philippe, of course Seaside is decoding. Otherwise I would never have gotten
> an Exception from decodePercent: in the first place. So I am expecting the
> right thing from Seaside and am getting it.
>
> The real problem in my case is that I am using ISO-8859-15 in my
> application. So the result of getting the text field's contents using val()
> is an ISO-8859-15 encoded String.

AFAIK that should be UTF-16 for JavaScript.

> encodeURI and encodeURIComponent not only escape characters, but also
> convert special characters into UTF-8. In my case this were German umlauts.
> So I fell hostage to a side effect of encodeURI and the fact that VA ST
> doesn't yet support Unicode and somehow didn't understand this.
>
> So what I did was not wrong per se, I just ignored the whole UTF-8 thing. I
> should have started my search in that area, because it is not the first time
> AJax and its UTF-8 nature bit me.
> For Pharo/Squeak/Gemstone users, this UTF-8 stuff is a non-issue, and
> therefor readers of my posts had absolutely no chance to see the forest
> between all the trees.

Just for completeness' sake you could try to fake it, accept UTF-8 and
translate it to ISO-8859-15 but then the question is what you do with
everything of Unicode that doesn't fit into ISO-8859-15. Also we have
to option of running UTF-8 but not decoding it. This makes it possible
to run UTF-8 on non-Unicode-capable systems but you have to be very
careful especially with the backend.

> All I had to do to make things work was to use .escape() instead of
> .encodeURI().
> .escape() does escape special characters in ISO-Latin character sets and
> encodes them with %XX. It is the poor man's encodeURI function so to say ;-)
>
> Readers: please be aware that .escape() is not the right solution for Ajax
> calls if your server speaks UTF-8. Always try encodeURI first!

You may want to do special testing with €ŠšŽžŒœŸ which are part of
ISO-8859-15 but not ISO-8859-1. Also you may want to test what happens
when somebody enters non-ISO-8859-15 input [1].

> Thanks for reading and answering. I would not have dug as deep as I did
> without your inspiration and sparks. They all made me see clear after a
> while and helped me solve my problem.

I'm glad you found the issue, my world makes sense again.

 [1] http://www.columbia.edu/~fdc/utf8/

Cheers
Philippe