Categories
HTML Tutorials

Configuring the Data Encoding

The enctype attribute specifies how the browser encodes and presents the data to the server. There are three allowed values for this attribute, which are described in the table below. 

To understand how the different encodings work, you need to have two input elements in your form as shown below.

<html>
  <head>
    <title>Example</title>
    <meta name="author" content="Adam Freeman"/>
    <meta name="description" content="A simple example"/>
    <link rel="shortcut icon" href="favicon.ico" type="image/x-icon" />
  </head>
  <body>
    <form method="post" action="http://titan:8080/form">
      <input name="fave"/>
      <input name="name"/>
      <button>Submit Vote</button>
    </form>
  </body>
</html>

You need two input elements so that you can collect two items of data from the user. As you may have guessed, you are building up a form that will allow users to vote for their favorite fruits. The second input element will be used to gather their names. As you can see above, we set the name value of this element to be name. To demonstrate the effect of the different form encodings, we have to add the enctype attribute to the form and set it to each of the supported encoding types.

 In each instance, I enter the same data into the text boxes. In the first text box I enter Apples, and in the second I enter Adam Freeman (with the space between my first and second names). Now let’s see how this data is encoded by the different techniques.

The application/x-www-form-urlencoded Encoding

This is the default encoding, and it is suitable for every kind of form except those that upload files to the server. The name and value of each data item is encoded using the same scheme that is used to encode URLs (hence, the urlencoded part of the name). This is how the encoding is applied to the data in the example form:

fave=Apples&name=Adam+Freeman

Special characters are replaced with their HTML entity counterpart. The name of the data item and the value are separated by the equals sign (=) and data/value tuples are separated by the ampersand character (&).

The multipart/form-data Encoding

The multipart/form-data encoding takes a different approach. It is more verbose and more complex to process, which is why it tends to be used only for forms that need to upload files to the server— something that can’t be done using the default encoding. Here is how the data from the example form is encoded:

------WebKitFormBoundary2qgCsuH4ohZ5eObF
Content-Disposition: form-data; name="fave"
Apples
------WebKitFormBoundary2qgCsuH4ohZ5eObF
Content-Disposition: form-data; name="name"
Adam Freeman
------WebKitFormBoundary2qgCsuH4ohZ5eObF--
fave=Apple
name=Adam Freeman
The text/plain Encoding

This encoding should be used with caution. There is no formal specification as to how data should be encoded when using this scheme, and the mainstream browsers encode data in different ways. For example, Google Chrome encodes data in the same way as for the application/x-www-form-urlencoded scheme, whereas Firefox encodes the data as follows:

fave=Apple
name=Adam Freeman

Each data item is placed on a line, and special characters are not encoded. We recommend avoiding this encoding. The variations between browsers make it unpredictable.