Inumerable hours have gone into devising CGI.pm It is not perfect but it is well tested and reliable. For some scary info on the problem invoked via bad CGI parsing see:

Use CGI or die;

No excuses about not using CGI.pm

and Ovid's CGI tutorial.

You had me worried for a minute there!

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

I asked my brother what about using param() to handle non-standard characters in HTML form input. He said he has a few regexes that do it and he doesn't need Lincoln Stein's code to check input for him.

Way, way back in like 1998 or something in TPJ (bless its little cotton socks) there was an article called something like "Perl Heresies". One of the heresies in this article was that you should <STONG>always use modules.

Before I get jumped on I'll explain the rest of its gist.

The argument went something along the lines that, if it's work related then you have a responsibility to your client/employer/whatever to write good code efficiently and quickly, so, in this situation, modules - particularly ones such as CGI.pm - are a good thing, but that, in certain circumstances it can be much more efficient to write a quick line or two to handle a small portion covered by a module rather than go to the trouble of loading a whopping great module in (I think the example was Date::Manip and figuring out what day it was yesterday or something)
However, when it comes to "messing around", re-inventing the wheel can be really good for you. It will give you a much better understanding of what goes on behind the scenes when you are using other peoples modules and if you ever have to invent the wheel for some reason then you're not going to be totally clueless and starting from scratch.

My apologies to the author of the article if I've totally mis-represented it :)