Questions and answers

Since the same script puts up a form that asks questions and also retrieves the answers to those questions, we need to be able to tell in which phase of the operation we are. We do that by testing $data to find out whether it is full or empty. If it is full, we find that all the data typed into the fields of the form by the user are there, with the fields separated by &. For instance, if the user had typed “Anne” into the first-name box and “Smith” into the surname box, this string would arrive:

xname=Anne&sname=Smith

or, if the browser is being very correct:

xname=Anne;sname=Smith

We have to dissect it to answer the customer’s question, but this can be a bit puzzling. Not only is everything crumpled together, various characters are encoded. For instance, if the user had typed “&” as part of his response, e.g., “Smith&Jones”, it would appear as “Smith%26Jones”. You will have noticed that “26” is the ASCII code in hexadecimal for “&”. This is called URL encoding and is documented in the HTTP RFC. “Space” comes across as “+” or possibly “%20”. For the moment we ignore this problem. Later on, when you are writing real applications, you would probably use the “unescape” function from CGI.pm to translate these characters.

The strategy for dealing with this stuff is to:

  1. Split on either “&” or “;” to get the fields

  2. Split on “=” to separate the field name and content

  3. (Ultimately, when you get around to using it) use CGI::unescape($content), the content to get rid of URL ...

Get Apache: The Definitive Guide, 3rd Edition now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.