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:
Split on either “&” or “;” to get the fields
Split on “=” to separate the field name and content
(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.