in reply to Re^4: Wierd behaviour with HTML::Entities::decode_entities()
in thread Wierd behaviour with HTML::Entities::decode_entities()
The source for decode_entities_old, which I thought was just a pure-Perl version of decode_entities, looks roughly like this (I've stripped out some context dependence):
With this code, and the under-populated hash my %entity2char = ( amp => '&', quot => '"' ), we havesub decode_entities_old { my $array = [ @_ ]; my $c; for (@$array) { s/(&\#(\d+);?)/$2 < 256 ? chr($2) : $1/eg; s/(&\#[xX]([0-9a-fA-F]+);?)/$c = hex($2); $c < 256 ? chr($c) : $1/ +eg; s/(&(\w+);?)/$entity2char{$2} || $1/eg; } return @$array; }
We would get (essentially) the opposite behaviour if we switched the second and third substitutions; that's what I mean by “This is very particular to the ordering”.say decode_entities_old '&amp;quot;'; => " say decode_entities_old '&#x26;quot;'; => &quot;
Of course, your example shows that decode_entities (which I guess is implemented in XS—I couldn't find it in the source) doesn't exhibit this buggy behaviour, so I guess that there's a reason that the sub I quoted has _old postpended. :-)
UPDATE: I just noticed that I'd mangled my intended bug-inducer, &quot;, above. I wonder if decode_entities (not decode_entities_old) handles it correctly?
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^6: Wierd behaviour with HTML::Entities::decode_entities()
by ikegami (Patriarch) on Dec 14, 2009 at 18:05 UTC | |
by Baz (Friar) on Dec 14, 2009 at 19:05 UTC | |
by ikegami (Patriarch) on Dec 14, 2009 at 19:53 UTC |
In Section
Seekers of Perl Wisdom