Checking up on the Safari support found this release note
http://www.opensource.apple.com/darwinsource/Current/JavaScriptCore-5525.18/
ChangeLog-2003-10-25
Which contains:
=== Safari-94 ===
2003-08-17 Darin Adler <[EMAIL PROTECTED]>
Reviewed by Maciej.
- fixed 3247528 -- encodeURI missing from JavaScriptCore (needed by
Crystal Reports)
- fixed 3381297 -- escape method does not escape the null character
- fixed 3381299 -- escape method produces incorrect escape sequences
ala WinIE, rather than correct ala Gecko
- fixed 3381303 -- unescape method treats escape sequences as
Latin-1 ala WinIE rather than as UTF-8 ala Gecko
- fixed 3381304 -- unescape method garbles strings with bad escape
sequences in them
* kjs/function.h: Added constants for decodeURI, decodeURIComponent,
encodeURI, and
encodeURIComponent.
* kjs/function.cpp:
(encode): Added. New helper function for escape, encodeURI, and
encodeURIComponent.
(decode): Added. New helper function for unescape, decodeURI, and
decodeURIComponent.
(GlobalFuncImp::call): Added decodeURI, decodeURIComponent,
encodeURI, and encodeURIComponent
implementations. Changed escape and unescape to use new helper
functions, which fixes
the four problems above.
I also came across this thread which indicates why Ajax libraries must use
encodeURIComponent when submitting forms.
http://bytes.com/forum/thread686800.html
Ian
-----Original Message-----
From: Ian Carr [mailto:[EMAIL PROTECTED]
Sent: 07 October 2008 14:21
To: 'MyFaces Discussion'
Subject: RE: [Trinidad] Problem with form encoding losing UK currency
symbols
Ok, I believe this is a bug!
Tomcat works Ok on Linux as well, but I think that it is actually incorrect!
The submission of the form data should be UTF-8 encoded, as it is from the
full page submission. The fact that the PPR submission is not UTF-8 encoded
causes Websphere to consume the illegal £ (A3) character and, probably
incorrectly, the following one as well (A3 is greater than 7F and so isn't a
legal base character, but neither is it above C0 which are the multibyte
introducers).
I have a patched form of the javascript where the form submission is
correctly encoded for both the PPR and non PPR. With this code Websphere and
Tomcat both work!
I believe the place for this fix is in the JS function:
TrRequestQueue._appendUrlFormEncoded
Which is currently only partly form encoding:
TrRequestQueue._appendUrlFormEncoded = function(
buffer,
key,
value)
{
if (buffer.length > 0)
{
buffer = buffer + "&";
}
return buffer + key + "=" + value.toString().replace(/\%/g,
'%25')
.replace(/\+/g, '%2B')
.replace(/\//g, '%2F')
.replace(/\&/g, '%26')
.replace(/\"/g, '%22')
.replace(/\'/g, '%27');
}
My replacement using the built in function encodeURIComponent is as follows:
TrRequestQueue._appendUrlFormEncoded = function(
buffer,
key,
value)
{
if (buffer.length > 0)
{
buffer = buffer + "&";
}
return buffer + key + "=" + encodeURIComponent(value.toString());
}
I have tested this on Tomcat and Websphere against firefox and IE, and this
seems to fix the problem.
I think this is a fairly urgent problem as it would appear that PPR will
currently not work with common non ASCII characters on correctly functioning
containers!
Note:
From my understanding the function is available as follows:
JavaScript 1.5|JScript 5.5|ECMAScript v3
IE: 5.5+
MOZILLA: 1.0+
Netscape: 6.0+
Opera: 7.0+
Safari: ???Not available???
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Matthias Wessendorf
Sent: 03 October 2008 11:36
To: MyFaces Discussion
Subject: Re: [Trinidad] Problem with form encoding losing UK currency
symbols
I wonder if it is the combi of linux AND websphere.
any chance to test it with linux/tomcat OR websphere/windoze ?
-M
On Thu, Oct 2, 2008 at 7:22 PM, Ian Carr <[EMAIL PROTECTED]> wrote:
> Hi we have an application using Trinidad (live version uses 1.0.4 but the
> problem seems to persist in 1.0.9).
>
> A page contains a text field into which free text can be entered.
>
> Everything (apparently) works fine on Tomcat and windows the user types a
> value into the field which may contain a UK currency symbol £ (pound sign)
> which is correctly round tripped both on the PPR and non PPR submissions.
>
> In Websphere on linux the behaviour is different and the pound sign
followed
> by the next character disappears!
>
> I thought this sounds like a character encoding issue so I used a proxy to
> examine the submissions
>
> If the JSP page contains the following definition:
>
> <jsp:directive.page contentType="text/html;charset=utf-8"/>
>
> Then the PPR triggered submission contains the following unencoded text:
>
> ... id_reviewSubForm:ReviewNeeds=£12345 alkjslkjaslj £2932929
> asasd...
>
> And the non PPR submission contains UTF-8 encoded text with the leading
%C2
> before the %A3 double byte pair for the pound sign:
>
> ... 3AReviewNeeds=%C2%A312345+alkjslkjaslj+%C2%A3292929...
>
> Changing the page to iso-8859-1 changes the encoding for the full
submission
> to the single character %A3 encoding, but has no effect on the PPR
> submission.
>
> ...3AReviewNeeds=%A312345+alkjslkjaslj+%A32932929+asasd...
>
> With either encoding the pound sign disappears from the page on the next
> render apparently after the full submission (ie navigate away and back)
>
> This looks like something somewhere is not interpreting/applying the
> encodings correctly?
>
> Shouldn't the submission from the PPR be encoded?
>
> I notice that the form does not specify the accept-charset?
>
> Any help would be appreciated.
>
> Ian
>
> No virus found in this outgoing message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.173 / Virus Database: 270.7.5/1703 - Release Date: 02/10/2008
> 07:46
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.173 / Virus Database: 270.7.5/1708 - Release Date: 04/10/2008
11:35
No virus found in this outgoing message.
Checked by AVG - http://www.avg.com
Version: 8.0.173 / Virus Database: 270.7.6/1712 - Release Date: 07/10/2008
09:41
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.173 / Virus Database: 270.7.6/1712 - Release Date: 07/10/2008
09:41
No virus found in this outgoing message.
Checked by AVG - http://www.avg.com
Version: 8.0.173 / Virus Database: 270.7.6/1712 - Release Date: 07/10/2008
09:41
