Home/ Questions/Q 7015485
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-27T22:39:29+00:00

I’ve faced a really weird behaviour of textarea today. Have been bugfixing it for

  • 0

I’ve faced a really weird behaviour of textarea today. Have been bugfixing it for the whole day, and I still cannot find the solution. Would appreciate any help, so thanks in advance.

I’m creating a GAE-python app.
And I have this little form here:

<form action="/add" method="post">
<div><textarea name="Name" rows="1" cols="60">name</textarea></div>
<div><textarea name="Email" rows="1" cols="60">email</textarea></div>
<div><textarea name="Comments" rows="6" cols="60">comments</textarea></div>
<div><input type="submit" value="Post"></div>
</form>

And I’m sending data (“comments” field) via POST-request to python script.
But…
Somehow I always get double line-breaks, or double CrLf, in the end which are stored in the database.
But strangely when I debug the request there’s something weird (both in FireFox+Firebug, and Chrome+DevTools).

For example I write and send this comments content via textarea:
c
c
c

In the url-encrypted data I see c%0D%0Ac%0D%0Ac
So it must be cCrLfcCrLfc
But when I copy the not-encrypted var from FireBug(DevTools) to NotePad++, it shows me this:

c CRLF
CRLF
c CRLF
CRLF
c CRLF
CRLF

Why is it doubled in the decoded format?!
And of course when I print the result back from Database to Browser I get all those double break-lines.
(when I look at this TextProperty of the Entity via “Datastore Viewer”, it is written just as “c c c”).

One more thing:
I’m having a flash app which sends post-requests to the same python-script, and all line-breaks made in flash’s textboxs are written correctly.
But if I just try to open that database entity via textarea in browser-s interface and just save it (without editing) I receive all line-breaks doubled again.

Is there any fixes of that?

Thank you.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    By the specifications, and in browser practice, a newline in user input in textarea as transmitted a CR LF pair, %-encoded as %0D%0A. Most probably this is what your server-side script gets, though you could verify this by dumping out the raw data it gets. What happens then is up to your script and its interaction with the database.

    There are varying newline conventions in different operating systems and programs, the most common being CR alone, LF alone, and CR LF pair, and the last one is the Internet practice. So it seems probable that some software component(s) then interpret CR LF as two separate control characters, each of which indicates a line break, and at some later point each of these is canonicalized to CR LF (or something that looks like CR LF).

    • 0