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):

sub 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; }
With this code, and the under-populated hash my %entity2char = ( amp => '&', quot => '"' ), we have
say decode_entities_old '&#x26;amp;quot;'; => &quot; say decode_entities_old '&amp;#x26;quot;'; => &#x26;quot;
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”.

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, &&#x71;uot;, above. I wonder if decode_entities (not decode_entities_old) handles it correctly?