About the URL how it is encoded and POST parameters

Question

The URL is always encoded, as is the encoding, what it encodes, and what importance or need to encode a url?

I have a div, who’s got line breaks and gets something printed like:

1

2

3

in HTML gets:

1<br/>2<br/>3

Unfortunately, when going through POST, it is not coded to the point of receiving on the other side with line break, I end up receiving like this: 123 when going through POST.

How to pass a value of a DIV as I actually left it, with the line breaks in case?

I’ve seen, when the post he respects the line break, it’s encoded getting something like this: mensagem=1%0A2%0A3..

Answer 1

When you submit a request, whether GET or POST, the parameters are first encoded using the URL encoding (by default; if you specify that you want a different encoding than application/x-www-form-urlencoded, the form of coding is another). As far as I know, this is always done, by browser even though it is not necessary for you to do it manually (even trying to do it manually can leave you in the situation of a double encoding).

What are encoded are all "non-reserved" characters. There is a set of characters called "reserved", which are:

!   *   '   (   )   ;   :   @   &   =   +   $   ,   /   ?   #   [   ]

Another set called "non-reserved":

letras ASCII maiúsculas e minúsculas
dígitos ASCII
-   _   .   ~

And the rest of the Unicode characters. Everything that is not in the "non-reserved" list is encoded.

I don’t really understand the HTTP protocol, but it’s easy to assume that the importance of coding is so that the data doesn’t mix with the other protocol delimiters. For example, if you want to pass a dice a&b as a field value x, can’t just walk by x=a&b, otherwise the b would be interpreted as another field.

As to your specific problem, there are two steps going on here, both "correct" but which may be causing an unwanted result:

1) First of all the text of div is being used, not your HTML code. See the difference:

var el = document.getElementById("teste");
var obj = {
  innerHTML: el.innerHTML,
  textContent: el.textContent,
  innerText: el.innerText // Não standard
};

document.querySelector("pre").innerHTML += JSON.stringify(obj, undefined, 4)
    .replace(/\</g, "&lt;");

<div id="teste">1<br/>2
   
 
  
      <br/>
  
  
  3
</div>
<hr/>
<pre></pre>

Note that:

• The innerHTML brought everything: tags and line breaks as they were in the source;
• The textContent removed the tags, only brought the text as it was in the source (the 1 and the 2 got together);
• The innerText, in Firefox, brought nothing... In Chrome, brought that closer than what you see on the page: 1\n2 \n3 (where this space came from, I have no idea...). And from what I read, others browsers have even more bizarre behaviors, so I wouldn’t trust this non-standard property...

After all, one way or another you’ll have to deal with the content of your div before using it. I suggest using the innerHTML (because it preserves more information) and remove/replace what is left, so as to end with the text that you really want to pass to the server.

2) Second, the data associated with the field mensagem receive the URL Encoding. In this case, 1%0A2%0A3 is the correct way to code 1\n2\n3 (as the ASCII code of \n is 0A hexadecimal). If on your server you are not receiving this, the problem must be in the form of it decode the message, because the form of the browser send is correct.