It's not getting rid of special characters, it's converting text containing hexadecimal values the corresponding bytes, if the text (either $value or $name) contains a "%" symbol, followed by 1 or more hexadecimal digits.

Read up on regular expressions, and you'll see that the /e switch at the end has the effect of doing an eval on the replacement text.

Also, take a look at the hex function.

Oh, I see. I was wading though the perl documentation on the "pack" function and couldn't see the forest for the trees when I was trying to understand this code. Thanks for the explanation.

You should really, really, really use the CGI module instead.

That looks suspiciously like a CGI parameter decoder.

I quite agree. And if the CGI module is overkill for the problem (since it does so many things), there are other more lightweight solutions, such as CGI::Deurl, which decodes the parameter strings in CGI requests, and that's all it does. Rose::URI and URI::QueryParam are worth having a look at as well. One is bound to find something that suits the problem domain.

And in regards to the OP, whatever solution is chosen, the exact mangling should be encapsulated in a subroutine, so that one calls:

  $name  = decode($name);
  $value = decode($value);
[download]

This way, whatever solution you settle upon, it will be a simple matter to change it to something else when something better comes along, and you won't have to change the rest of your code.

• another intruder with the mooring in the heart of the Perl

I disagree. It depends on the context of the problem.

It's possible the original author wrote the script this way for a number of reasons including

• getting maximum speed by inlining a complex function
• showing off by reimplementing a URL decoder
• lack of experience

It's also possible that the script is not a CGI script, or that it is an exceptionally lightweight CGI script.

For the most part, I would use the CGI module myself, but there are times when I wouldn't.

Sure there are situations where you might not use the CGI module, but
• Optimizing parameter parsing is not going to give you any significant speedup unless you've got tens of thousands of parameters and hardly do anything with them.
• URL decoders are not hard to code, except that people seem to forget to implement the full spec. (See for example & vs ; separators)
• Lack of experience is not a valid reason to keep code that could be replaced with a well-tested core module.
"What should it profit a man, if he should win a flame war, yet lose his cool?"

$value =~ tr/+/ /;
[download]

replaces + characters with spaces

$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C",hex($1))/eg;
[download]

replaces pairs of hex digits preceded by % with the character that has that value. The /e flag causes pack("C",hex($1)) to be executed and the result is used for the substitution string. For example '%41' would become 'A' (assuming ASCII is being used).

my $value = '%22Happy%20Birthday%21%22';
$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C",hex($1))/eg;
print "$value\n";
[download]

Phil