[TYPO3-core] RFC: #3527: Bug: Wrongly encoded characters in mail form validation popup

[Martin Kutschker]

Francois Suter schrieb:
> Hi,
> 
>> -1 as this cannot work correctly unless the character set is utf8 as
>> decodeURI() expects utf8 while unescape() expects latin1. If you use
>> decodeURI() you must convert the data to utf8 on the server side before
>> using rawurlencode().
>>
>> But... I think we don't need any escaping for strings *within* JS. The
>> escaping is only needed when passing values via URLs.
> 
> Hmm, indeed I apparently misunderstood your explanations. I tried to
> just remove the unescape() call, but it's worse than before. Do you mean
> the proper solution is to remove both the unescape() calls in the JS
> *and* the rawurlencode() calls in tslib_content?

Yes, but ONLY if tslib_content does something like that:#

$content = <<<EOT
<script>
var dummy = '$foobar';
</script>
EOT;

Ie. it creates a JS string embedded in the HTML code. In this case the
browser should handle the charset all by itself.

IMHO this should work in all modern browsers. In particular I think it
will work for all browsers which implement decodeURI().

Really old browser that require unescape() to handle latin1 will choke
on utf8 no matter what you do :)

The problem is that the server would need in advance what the client is
capable of. To make matters worse the implementation of unescape()
changed over the time! It started of as charset ignorant but later (til)
works ONLY on latin1.

Masi