And welcome back.
In these next few lectures, we're going to be talking about the encoding type attribute and yes, it
is just another form attribute.
It's an attribute we place on the form element.
OK, well, what is this attribute and how does it work?
Well, firstly, this is what it looks like.
We wrap it with in the form element, the encoding type attribute.
But let's compare this to what we've just learned.
Remember, we used the accept-charset attribute and a lot of people get confused between the...
accept-charset attribute and the encoding type or the enctype attribute.
What are the differences 🤷‍♀️?
Well, firstly, let me recap that accept-charset attribute. You should be very familiar with that now.
Remember, this is what characters you want to allow users to type into your form.
Usually that's set to utf-8.
And if you don't set it, the default is utf-8.
That's all good and well.
But what is this enctype - this encoding type attribute?
I like to think about it as a way of defining how your form data should be formatted in the body of
the HTTP request.
In other words, the encoding type specifies the formatting of your content.
And as we're going to see in some examples, it defines, or it sets, the content type in your HTTP request 🤨.
It might be a bit confusing.
Let me just try and explain this a bit better in person.
All right.
I don't want you to get confused.
I don't want you to get lost in all the detail.
We've got the...
accept-charset attribute.
What's that?
Well, let's just break it down.
It's the character set, the charset, that you are accepting in your form.
So that makes sense.
Accept charset, the character set that I'm accepting in my form.
OK, and then we've got this enctype attribute.
Well, what is that? Just intuitively think about it as ... enc standing for 'encoding' and 'type' as the type of encoding.
How should we encode the information in order to send it to your server?
In other words, how do we extract the information that we've received from the form, and package it
nicely in the HTTP body and send that to a server?
That's effectively what we're trying to do with this enctype attribute. So please don't get confused.
Don't get lost in the detail.
But enough said, let's jump back into the lecture.
Is it kind of making sense? Don't worry if its not. We're going to get into examples shortly.
But now I want us to jump into the GET request.
This is the default right,
when you submit a form. What you may have not known is that behind the scenes, the way a GET request
submits data to a server, is via the encoding type set to this horrible long word - application/
x-www-form-urlencoded.
This is what was happening behind the scenes.
And what does this application/x-www-form-urlencoded mean?
Well, it just means the browser is going to send the form values as name:value pairs.
These are going to be placed in the header field, and each name:value is going to be separated by the...
ampersand "&" symbol.
Spaces are usually replaced with the plus sign, and all special values are converted to the hex format,
right, %HH. We've seen the URL encoding format before. And with a GET request, with this
default type...
we've seen that these name:value pairs are placed in the URL.
If there's one thing I want you to remember with the GET request, just remember that the encoding type -
application/x-www-form-urlencoded is mandatory for the GET request.
We cannot have anything else when it comes to a GET request.
Kind of makes sense, right?
Because there's only one format with the GET request.
It has to be embedded in that URL.
And because of that, there is only this one type.
But enough talk.
Before we continue, I just want to show you an example.
Let's code up a form 👨‍💻.
Let's code up a GET request, and let me show you this in action.
Let's do that now.