Tutorial 13: Giving Form to Forms - HTML with Style | 17

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)

First Name:
Last Name:

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:

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).

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:

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.