why encoded?

i have a POST form and when i enter value contain + example

a+b

and click the submit button then it is converted into a%2Bb

i noticed that + is converted into %2B

why this happens when we post data from html form?

is there a way to post directly + in place of %2B ?

It's called URLEncoding... and it's normally done with forms that have an action of GET... because the data has to be safely passed through the URL so non alphanumerics get converted to their Hex value (2B in the case of a +). on the receiving end it then needs to be run through a URLUnencode process. POSTed data (where the form action = POST) on the other hand usually gets handled differently... and doesn't usually go through the URLEncoding... so are you sure you're POSTing and not GETting?

-tg

Quote:

---

Originally Posted by techgnome

It's called URLEncoding... and it's normally done with forms that have an action of GET... because the data has to be safely passed through the URL so non alphanumerics get converted to their Hex value (2B in the case of a +). on the receiving end it then needs to be run through a URLUnencode process. POSTed data (where the form action = POST) on the other hand usually gets handled differently... and doesn't usually go through the URLEncoding... so are you sure you're POSTing and not GETting?

-tg

---

yes im sure my form method is post not get.

where this a%2b showing ? in another input or somewhere in forum ? you can convert the %2 to + if its bothering u...
as TG mentioned its usually for Get Method like when you use space it shows with %20 anyway here's a solution for changing it before echo it out :

Code:

---

$text = "hello%20Bye";
$text_replace = str_replace('+', '%20', $text);

---

I don't recommend using replace... there is a URLUnencode (or URLDecode) function in most languages (you didn't specify what you're suing, but PHP and .NET both have one) specifically for this reason... you start using replace and you'll be writing A LOT of code trying to account for all possibilities.

Also, you may want to mention the language you are using on the server end and how you are getting your values from the submission...

-tg

yup there is urldecode for php since this thread is in php :
string urldecode ( string $str )
Decodes any %## encoding in the given string. Plus symbols ('+') are decoded to a space character.

its so simple so it doesnt require an example
Goodluck

no... it won't replace the + with a space... the + was encoded to %2b ... so the %2b will be dencoded back to "+" .... that's it... now, if + was passed into the decode function... then yes... the + would be replaced with a space... so would %32 ... but since the + isn't being passed into the decode... it's irrelevant.

-tg

you are right so i had to edit the post... if the + wont get encoded to %2b then it will be decoded to space otherwise as you said it will be back to + :wave:

Quote:

---

Originally Posted by techgnome

It's called URLEncoding... and it's normally done with forms that have an action of GET... because the data has to be safely passed through the URL so non alphanumerics get converted to their Hex value (2B in the case of a +). on the receiving end it then needs to be run through a URLUnencode process. POSTed data (where the form action = POST) on the other hand usually gets handled differently... and doesn't usually go through the URLEncoding... so are you sure you're POSTing and not GETting?

-tg

---

Actually, both GET and POST requests tend to be encoded in the same format (key1=val1&key2=val2, etc., with URL encoding applied):

Attachment 100687

The distinction is purely semantic... with the exception of multi-part POST requests (with the MIME type multipart/form-data), which let you embed binary streams in the request body. These work in the same way as multi-part emails: a 'boundary' string is defined (a series of characters which doesn't appear in any of the binary parts) which delimits the parts of the request.