Hi,
Stevan Little wrote:
> On Apr 13, 2005, at 9:20 AM, BÃRTHÃZI AndrÃs wrote:
>> The problem is with this line in sub url_decode():
>>
>> $decoded ~~ s:perl5:g/%([\da-fA-F][\da-fA-F])/{chr(hex($1))}/;
>>
>> Have any idea, how to solve it? I think I should transform this code
>> to recognize multi-bytes, decode the character value, and after it
>> use chr on this value. Or is there a way to do it by not creating
>> character by chr(), but a byte with another function?
> handle multi-bytes itself. In the (non-working) port of CGI-Lite
> (http://tpe.freepan.org/repos/iblech/CGI-Lite/lib/CGI/Lite.pm), I saw
> code which did this:
>
> /%(<[\da-fA-F]>**{2})/{chr :16($1)}/
>
> Of course it was followed by this comment "# XXX -- correct?" so it
> may not be anything official yet.
the "XXX -- correct" refers to the :16 (IIRC, Larry said on p6l that he
liked that, but I wasn't able to find it in the Synopses).
BTW, Pugs' chr does understand input > 255 correctly:
pugs> ord "â"
8364
pugs> chr 8364
'â'
$decoded does contain valid UTF-8, the problem is Pugs' print/say
builtin -- compare:
$ perl -we 'print "\xE2\x82\xAC\n"'
â
$ perl -we 'die "\xE2\x82\xAC"'
â at -e line 1.
$ pugs -we 'say "\xE2\x82\xAC"'
ÃÂ # garbage!
$ pugs -we 'die "\xE2\x82\xAC"'
â # perfectly fine â-sign!
Val (VList [VStr "\226\130\172"])
--Ingo
--
Linux, the choice of a GNU | Black holes result when God divides the
generation on a dual AMD | universe by zero.
Athlon! |
