form attribute ENCTYPE   Leave a comment

Attribute for <FORM ...>
ENCTYPE = "multipart/form-data" | "application/x-www-form-urlencoded" | "text/plain"

In most cases you will not need to use this attribute at all. The default value (i.e. if you don’t use this attribute at all) is "application/x-www-form-urlencoded", which is sufficient for almost any kind of form data. The one exception is if you want to do file uploads. In that case you should use "multipart/form-data". See file uploads for more details.

Take a look at what is actually sent to the web server with each ENCTYPE

ENCTYPE determines how the form data is encoded. Whenever data is transmitted from one place to another, there needs to be an agreed upon means of representing that data. Music is translated into written music notation, English is written using letters and punctuation. Similarly, there needs to be an agreed on way of presenting the form data so it’s clear that, for example, there is a field called “email” and its value is “”.


Enctype=”text/plain” – Can someone explain why?


I have created a database and wrote some php to connect to it. I then added another page which contained a form and an input field. When you entered data in the field, it would search a field in the database for a match and then display the results. For some reason the form wasn’t passing the information over the PHP page. In the end I figured out it was because of this:


I don’t know what was causing this to happen. Can someone please explain?

Actually, the POST forms have by default application/x-www-form-urlencoded as the enctype (multipart/form-data must be used in order to be able to upload files). The text/plain enctype specifies that the document in question (the form in your case) is a text container. Therefore, the form doesn’t really exist anymore, as form data must be serialized before submitted to be processed server-side. Since you were using plain text as the form’s contents, there was no data to submit.

enctype defines how the data should be formatted before sending. the two correct formats are application/x-www-form-urlencoded (which essentially sends things as key=valye&anotherkey=anothervalue, with http headers) and multipart/form-data (which splits each key up into a distinct section of data). text/plain means nothing should be done – its behaviour is essentially undefined between browsers, and was only ever used for automated email forms in the days before spam. use application/x-www-form-urlencoded for text forms (or leave this to use the default setting) and multipart/form-data for file attachment uploads

Thanks for your reply. What exactly was the text/plain doing to the value entered in the input field (a number) for it not to pass the data over?

stolen from Form Data Encoding Roundup :


Content-Type: text/plain
baz=The first line.
The second line.



Content-Type: application/x-www-form-urlencoded


Content-Type: multipart/form-data; boundary=---------------------------314911788813839
Content-Disposition: form-data; name="foo"

Content-Disposition: form-data; name="baz"

The first line.
The second line.


you can see how the first one is useful for passing values UNCHECKED directly into an email program (e.g. if your form uses a mailto: address, so it uses your visitor’s email program to send) but is largely useless for programmatic access to fields. only the bottom 2 examples are valid for actual form-based form data


Posted 2011年03月15日 by gw8310 in html


Fill in your details below or click an icon to log in: 徽标

You are commenting using your account. Log Out /  更改 )

Google+ photo

You are commenting using your Google+ account. Log Out /  更改 )

Twitter picture

You are commenting using your Twitter account. Log Out /  更改 )

Facebook photo

You are commenting using your Facebook account. Log Out /  更改 )

Connecting to %s

%d 博主赞过: