ENTER converted from \n to \r\n on POST

Asked 28/1, 2014 at 10:14 Answered 12/4 at 3:56

I have this simple test page saved as page1.html.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
  <head>
    <script type="text/javascript">
      function submitForm() {
        alert(escape(document.myform.mytextarea.value));
        return true;
      }
    </script>
  </head>

  <body>
    <form name="myform" action="page2.html" method="post" onsubmit="javascript:return submitForm();">
      <textarea name="mytextarea">xxxyyy</textarea>

      <input type="submit" value="submitForm">
    </form>
  </body>
</html>

And this page saved as page2.html.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
  <body>
    Page2.html
  </body>
</html>

I open page1.html under Firefox (I think version has no importance, but it is 18.0. And same problem with Chrome or IE 10.0). Before I click the submitForm button, I hit one ENTER between values "xxx" and "yyy" like this.

HTML Form

When I click the submitForm button, the alert shows one character between "xxx" and "yyy" which is the \n encoded as "%0A".

Javascript Alert

If I have a look into Firebug of what is posted, I can see two characters which are "\r\n" encoded as "%0D%0A".

Firebug POST

Can you explain why \n is transformed to \r\n on POST and how to prevent that ? I minimized my problem, but it's really problematic for me.

I could test this under Safari on MAC OS, and I also get %0D%0A on POST.

Under IE 8.0 and before, Javascript alerts %0D%0A and I get %0D%0A on POST, so IE 8.0 and before does not behave the same.

Mainstay answered 28/1, 2014 at 10:14 Comment(2)

Depending on your operating sistem, new-line character might be represented with just "\n" or with both "\r" and "\n", although that doesn't seem to be the issue here. – Ararat 28/1, 2014 at 10:22

The ECMA script standard says "\n for newline", and alert is ECMA script. It is POST that uses the "real" data, which, on your windows box, is "\r\n", while it is "\r" on a Macbook or "\n" on a Linux box. – Convolution 28/1, 2014 at 10:32

New line characters are treated differently for different Operating Systems.

\r = CR (Carriage Return) // Used as a new line character in Unix

\n = LF (Line Feed) // Used as a new line character in Mac OS

\r\n = CR + LF // Used as a new line character in Windows

As far as the data in text-area is concerned. When the form is submitted the text-area contents are url-encoded and as per the HTML Spec:

Line breaks, as in multi-line text field values, are represented as CR LF pairs, i.e. `%0D%0A'.

I found a relevant SO Question that addresses a similar issue with line breaks and cross-platform compatibility.

As far as your problem is concerned if you want new lines to be treated uniformly, you could do a simple regex replace in the contents of your text area to take care of the discrepancy.

Isentropic answered 28/1, 2014 at 11:50 Comment(0)

Solution 1:

in c#:

string value = Request.Params["txtValue"].replace("\r\n","\n");

Solution 2:

Or you can add hidden field like:

<input id="txtValue" type="textarea" />
<input id="hiddenTxtValue" type="hidden"/>

and set his value with encodeUriComponent:

$('#hiddenTxtValue').val(encodeUriComponent($('#txtValue').val()));

in c#:

string value = Request.Params["hiddenTxtValue"];

Beisel answered 24/10, 2017 at 11:26 Comment(0)

Thanks to your informations, I wrote this function to count the "submitted" length of my textarea on any browser :

function getFormURLEncodedLength(myValue) {
  return myValue.replace(/(\r\n|\n|\r)/g, '\r\n').length;
}

Mainstay answered 30/1, 2014 at 10:27 Comment(0)

As @vivek-pradhan metioned in his answer, by default, form data is encoded as application/x-www-form-urlencoded before sending to the server. Line breaks are converted to CR LF(\r\n).

If you use multipart/form-data for all form data post, "the overhead of adding all of the MIME headers is going to significantly outweigh any savings from more efficient binary encoding"

If you are verifying the exact string on the server, it is better to stringify the data to a JSON string and send it with application/json encoding, to preserve the exact data.

Elishaelision answered 12/4 at 3:56 Comment(0)

Solution 1:

Solution 2:

Recommended topics

Hot tags