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.

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?"