Tutorial 13: Giving Form to Forms
|
| ||||
| ||||
|
|
Form encoding
As we mentioned, the first thing a form does is give the user the illusion of power in this cruel, unfair world and let him enter some data.
Data is entered via a number of controls. Each of these controls has a name (or at least it better, if you want the form to do anything). After the form is submitted, the data entered by the user is translated into pairs, each consisting of a name and a value. Consider the following form: (You can't submit this one, because I'm just illustrating the concept)
This form creates two pairs of names and values; one with the name firstname and the value Stephanos and another with the name lastname and the value Piperoglou. In a different form, the values might not just a small piece of text, but an entire file.
Next, the data is encoded in a certain way. Encoding means that all the names and values are bunched up together in one long piece of data that can be easily processed by the recieving program. This is nice because you can specify a different encoding depending on what the program that handles the data is expecting. It also nice because you don't have to worry about having strange characters in the names and values; encoding makes sure they are changed to something the receiving program can process. The encoding is specified using the ENCTYPE attribute to the FORM element.
There are basically two alternatives for form encoding. One is called application/x-www-form-urlencoded (don't worry, I've been doing this for years and I still don't know that by heart), and is basically taking all of the names and values and bunching them up, then changing some of the characters, such as spaces and control characters, so that they can appear inside a URL. This is what happens with the ISINDEX element, as we saw above. To illustrate this, the contents of the form above would be encoded like this:
lastname=Piperoglou&firstname=Stephanos
The other commonly used encoding is multipart/form-data. This format is much more legible and useful to programs (I'm sure you jumped up with joy when you saw the word "legible," but that serves you right, now doesn't it? Face it, nobody cares about us petty humans any more), especially if there is a lot of data to be encoded. Our example encoded using this encoding would look like this:
-----------------------------16931435195472910531915358310 Content-Disposition: form-data; name="firstname" Stephanos -----------------------------16931435195472910531915358310 Content-Disposition: form-data; name="lastname" Piperoglou -----------------------------16931435195472910531915358310--
This encoding is the only useful one when sending large files along with forms. Here is an example from a different form, which has three name/value pairs: firstname and lastname as above, and a third field called photo which contains an image in GIF format, so that you can bless anyone recieving the data with your winning smile. I don't actually show you the data of the GIF image, firstly because it could be very large, and secondly because it would resemble Sanskrit written by a chimpanzee having an epilepsy attack (try opening a GIF file with a text editor and you'll see what I mean).
-----------------------------9544700891849786717350528346 Content-Disposition: form-data; name="firstname" Stephanos -----------------------------9544700891849786717350528346 Content-Disposition: form-data; name="lastname" Piperoglou -----------------------------9544700891849786717350528346 Content-Disposition: form-data; name="photo"; filename="b_center.gif" Content-Type: image/gif . . . a GIF image . . . -----------------------------9544700891849786717350528346--
There are many good things about this encoding. First of all, you can tell the browser beforehand (using the ACCEPT-CHARSET attribute to the FORM element) what character sets the data can be in, so the user can be told to enter information in a certain way. We haven't talked about character sets and internationalization yet, but we will in a future tutorial. For now, don't bother with that attribute, as it has a sensible default. You can also tell the browser what types of files can be sent with the form using the accept attribute to the FORM element. So, for example, the FORM element start-tag for the form that produced the output above could be something like this:
<FORM ACCEPT="image/gif, image/jpeg, image/png" ENCTYPE="multipart/form-data" METHOD="post" ACTION="http://www.acme.com/cgi-bin/name.cgi" >
The ACCEPT attribute tells the browser processing this form that the files that can be sent as form data can be of the three types listed in its value. The ENCTYPE attribute tells the browser to encode the data using the multipart/form-data encoding. What do the METHOD and ACTION attributes do? These are useful when we get to form submission, which is what we'll talk about next.
