By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,156 Members | 1,004 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,156 IT Pros & Developers. It's quick & easy.

Line breaks (\n) from a html form textarea??? HELP!

P: n/a
Hi

I have an HTML form with a textarea on it. When submitted (using 'get'
not 'post') this forms action php file simply does this to retrieve the
values:

$message = $_GET["message"];

Now it all works fine but I get the string in one long string with no
'\n' where the user pressed 'return key'

How can I get the carriage returns in the textarea to be replaced with
a '\n' ??? Its driving me nuts here!!

Jan 13 '07 #1
Share this Question
Share on Google+
14 Replies


P: n/a
Message-ID: <11**********************@s34g2000cwa.googlegroups .comfrom
ghostwalker contained the following:
>I have an HTML form with a textarea on it. When submitted (using 'get'
not 'post') this forms action php file simply does this to retrieve the
values:

$message = $_GET["message"];

Now it all works fine but I get the string in one long string with no
'\n' where the user pressed 'return key'

How can I get the carriage returns in the textarea to be replaced with
a '\n' ??? Its driving me nuts here!!
You may be better off using post instead of get

--
Geoff Berrow (put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/
Jan 13 '07 #2

P: n/a
ghostwalker wrote:
Hi

I have an HTML form with a textarea on it. When submitted (using 'get'
not 'post') this forms action php file simply does this to retrieve the
values:

$message = $_GET["message"];

Now it all works fine but I get the string in one long string with no
'\n' where the user pressed 'return key'

How can I get the carriage returns in the textarea to be replaced with
a '\n' ??? Its driving me nuts here!!
You need to set up the html with a code on the textarea so that
CRs are not thrown away. it is not a php problem.

My mind is creaky this late at night, but I think the code is:
wrap="hard"

bill
Jan 14 '07 #3

P: n/a
How about the nl2br function? It converts newlines to <br />

http://us3.php.net/nl2br

Jan 14 '07 #4

P: n/a
Daz


On Jan 13, 10:49 pm, "ghostwalker" <m...@weblogica.co.ukwrote:
Hi

I have an HTML form with a textarea on it. When submitted (using 'get'
not 'post') this forms action php file simply does this to retrieve the
values:

$message = $_GET["message"];

Now it all works fine but I get the string in one long string with no
'\n' where the user pressed 'return key'

How can I get the carriage returns in the textarea to be replaced with
a '\n' ??? Its driving me nuts here!!
Is there any particular reason that you aren't using POST? Generally,
GET is for getting data, and POST is for posting. Also, I believe that
post encodes and escapes the data, too, so it will arrive as you'd
expect it to. My guess is that there is not URL code for the newline
chracter, as it's a control code, and not meant to be visible.

Also, retrieving the contents of a text area through GET could make for
a _BIG_ URL. I would recommend you use POST for forms, unless they are
seriously limited text input fields (with no special characters/control
codes). Also, what would happen when the GET URL has been submitted,
and the user hits refresh immediately after? The form data would be
submitted again. If you'd used post, the user would have to go back a
page and refresh in order to resubmit the form, and even then, most, if
not all browsers, will alert the user that they are about to repost
data that's already been posted.

I hope this helps.

Daz.

Jan 14 '07 #5

P: n/a
PseudoMega schreef:
How about the nl2br function? It converts newlines to <br />

http://us3.php.net/nl2br
That wont help since the newlines are lost with the GET request. There
is noting to nl2br :-)

Dont use GET in a form. It will turn up in someone's log and
google/yahoo etc is gonna find it. When it tries to spider the url it's
not going to behave the way u want it :-)

Use POST

--
Arjen
http://www.hondenpage.com
Jan 14 '07 #6

P: n/a
"Daz" <cu********@gmail.comwrote:
>
Is there any particular reason that you aren't using POST? Generally,
GET is for getting data, and POST is for posting. Also, I believe that
post encodes and escapes the data, too, so it will arrive as you'd
expect it to.
This is not true. GET and POST requests are both encoded, although they
use different schemes. With the exception of file uploads, there is
nothing you can send with POST that you cannot also send with GET.

HOWEVER, just because one can, doesn't mean one should. Your basic advice
is correct: POST should almost always be used for forms, because the URLs
get too large.
>My guess is that there is not URL code for the newline
chracter, as it's a control code, and not meant to be visible.
Nope. That's not the problem. Another responder nailed it: you have to
tell the <textareathat you want the newlines by saying <textarea
wrap="hard">. Otherwise, it assumes you don't want the newlines at all,
and discards them.
--
Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
Jan 15 '07 #7

P: n/a
Daz

Tim Roberts wrote:
"Daz" <cu********@gmail.comwrote:

Is there any particular reason that you aren't using POST? Generally,
GET is for getting data, and POST is for posting. Also, I believe that
post encodes and escapes the data, too, so it will arrive as you'd
expect it to.

This is not true. GET and POST requests are both encoded, although they
use different schemes. With the exception of file uploads, there is
nothing you can send with POST that you cannot also send with GET.
What I meant by encoded, was encrypted, I think I just chose the wrong
word. I believe that POST requests are encrypted, whereas GET requests
are simply just encoded into URL format.
HOWEVER, just because one can, doesn't mean one should. Your basic advice
is correct: POST should almost always be used for forms, because the URLs
get too large.
My guess is that there is not URL code for the newline
chracter, as it's a control code, and not meant to be visible.


Nope. That's not the problem. Another responder nailed it: you have to
tell the <textareathat you want the newlines by saying <textarea
wrap="hard">. Otherwise, it assumes you don't want the newlines at all,
and discards them.
Well, it was just a guess (as stated). But that is a useful piece of
information to know of, and I was totally unaware of it. I personally
feel it would have been better the other way round, wrap="hard" by
default, as I think it's unlikely that you want the data in any format
other than the format is was entered. Many, many thanks for your input.

Daz.
--
Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
Jan 15 '07 #8

P: n/a
Daz wrote:
Tim Roberts wrote:
>>"Daz" <cu********@gmail.comwrote:
>>>Is there any particular reason that you aren't using POST? Generally,
GET is for getting data, and POST is for posting. Also, I believe that
post encodes and escapes the data, too, so it will arrive as you'd
expect it to.

This is not true. GET and POST requests are both encoded, although they
use different schemes. With the exception of file uploads, there is
nothing you can send with POST that you cannot also send with GET.

What I meant by encoded, was encrypted, I think I just chose the wrong
word. I believe that POST requests are encrypted, whereas GET requests
are simply just encoded into URL format.
Nope. POST requests are sent plain text. No encoding/encrypting at all.
>
>>HOWEVER, just because one can, doesn't mean one should. Your basic advice
is correct: POST should almost always be used for forms, because the URLs
get too large.

>>>My guess is that there is not URL code for the newline
chracter, as it's a control code, and not meant to be visible.


Nope. That's not the problem. Another responder nailed it: you have to
tell the <textareathat you want the newlines by saying <textarea
wrap="hard">. Otherwise, it assumes you don't want the newlines at all,
and discards them.

Well, it was just a guess (as stated). But that is a useful piece of
information to know of, and I was totally unaware of it. I personally
feel it would have been better the other way round, wrap="hard" by
default, as I think it's unlikely that you want the data in any format
other than the format is was entered. Many, many thanks for your input.

Daz.
No, I typically do not want the nl chars in the input data. That's
because I'm going to generally reformat it for display, anyway.
>>--
Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Jan 15 '07 #9

P: n/a
..oO(Tim Roberts)
>HOWEVER, just because one can, doesn't mean one should. Your basic advice
is correct: POST should almost always be used for forms, because the URLs
get too large.
It's also a security issue. Using plain links to change or delete
something on the server can become a problem or even a security risk.
>Nope. That's not the problem. Another responder nailed it: you have to
tell the <textareathat you want the newlines by saying <textarea
wrap="hard">.
That's no HTML.

I've tested Opera, FF, IE and Lynx - all browsers send correct line
breaks from a textarea, regardless of the used method (GET or POST).

Using GET and a simple

| test1
| test2
|
| test3

the line breaks are sent as URL-encoded "\r\n":

....&textfield=test1%0D%0Atest2%0D%0A%0D%0Atest3&. ..

Micha
Jan 15 '07 #10

P: n/a
Daz

Jerry Stuckle wrote:
Daz wrote:
Tim Roberts wrote:
>"Daz" <cu********@gmail.comwrote:

Is there any particular reason that you aren't using POST? Generally,
GET is for getting data, and POST is for posting. Also, I believe that
post encodes and escapes the data, too, so it will arrive as you'd
expect it to.

This is not true. GET and POST requests are both encoded, although they
use different schemes. With the exception of file uploads, there is
nothing you can send with POST that you cannot also send with GET.
What I meant by encoded, was encrypted, I think I just chose the wrong
word. I believe that POST requests are encrypted, whereas GET requests
are simply just encoded into URL format.

Nope. POST requests are sent plain text. No encoding/encrypting at all.
>HOWEVER, just because one can, doesn't mean one should. Your basic advice
is correct: POST should almost always be used for forms, because the URLs
get too large.
My guess is that there is not URL code for the newline
chracter, as it's a control code, and not meant to be visible.
Nope. That's not the problem. Another responder nailed it: you have to
tell the <textareathat you want the newlines by saying <textarea
wrap="hard">. Otherwise, it assumes you don't want the newlines at all,
and discards them.
Well, it was just a guess (as stated). But that is a useful piece of
information to know of, and I was totally unaware of it. I personally
feel it would have been better the other way round, wrap="hard" by
default, as I think it's unlikely that you want the data in any format
other than the format is was entered. Many, many thanks for your input.

Daz.

No, I typically do not want the nl chars in the input data. That's
because I'm going to generally reformat it for display, anyway.
>--
Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
I guess it depends on what you want to use the text for. I personally
can't imagine how or why you'd want to strip them. My personal
prefrerence would be to strip them server side if it was needed, which
would probably allow me to replace them with something else, or format
the data more meaningully. Saying that, I haven't been doing this for
as long as you, so I suppose it's just a question of time and
experience.

Thank you for your input. :)
>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Jan 15 '07 #11

P: n/a
Daz wrote:
Jerry Stuckle wrote:

>>Daz wrote:
>>>Tim Roberts wrote:
"Daz" <cu********@gmail.comwrote:
>Is there any particular reason that you aren't using POST? Generally,
>GET is for getting data, and POST is for posting. Also, I believe that
>post encodes and escapes the data, too, so it will arrive as you'd
>expect it to.

This is not true. GET and POST requests are both encoded, although they
use different schemes. With the exception of file uploads, there is
nothing you can send with POST that you cannot also send with GET.

What I meant by encoded, was encrypted, I think I just chose the wrong
word. I believe that POST requests are encrypted, whereas GET requests
are simply just encoded into URL format.

Nope. POST requests are sent plain text. No encoding/encrypting at all.

>>>>HOWEVER, just because one can, doesn't mean one should. Your basic advice
is correct: POST should almost always be used for forms, because the URLs
get too large.

>My guess is that there is not URL code for the newline
>chracter, as it's a control code, and not meant to be visible.
Nope. That's not the problem. Another responder nailed it: you have to
tell the <textareathat you want the newlines by saying <textarea
wrap="hard">. Otherwise, it assumes you don't want the newlines at all,
and discards them.

Well, it was just a guess (as stated). But that is a useful piece of
information to know of, and I was totally unaware of it. I personally
feel it would have been better the other way round, wrap="hard" by
default, as I think it's unlikely that you want the data in any format
other than the format is was entered. Many, many thanks for your input.

Daz.

No, I typically do not want the nl chars in the input data. That's
because I'm going to generally reformat it for display, anyway.

>>>>--
Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.


I guess it depends on what you want to use the text for. I personally
can't imagine how or why you'd want to strip them. My personal
prefrerence would be to strip them server side if it was needed, which
would probably allow me to replace them with something else, or format
the data more meaningully. Saying that, I haven't been doing this for
as long as you, so I suppose it's just a question of time and
experience.

Thank you for your input. :)
Because HTML is a fluid mechanism, and you can't control the looks of
the page. All you can do is recommend it.

The way to do it is to get rid of the nl chars and let HTML and CSS do
their own formatting.

>>--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Jan 15 '07 #12

P: n/a
Michael Fesser <ne*****@gmx.dewrote:
>
.oO(Tim Roberts)
>>HOWEVER, just because one can, doesn't mean one should. Your basic advice
is correct: POST should almost always be used for forms, because the URLs
get too large.

It's also a security issue. Using plain links to change or delete
something on the server can become a problem or even a security risk.
I don't think that's really what you meant to say. There is no difference
in security between GET and POST. If there's something that is dangerous
as a GET, then it's dangerous as a POST.
>>Nope. That's not the problem. Another responder nailed it: you have to
tell the <textareathat you want the newlines by saying <textarea
wrap="hard">.

That's no HTML.
Of course it is. What would you call it?
>I've tested Opera, FF, IE and Lynx - all browsers send correct line
breaks from a textarea, regardless of the used method (GET or POST).

Using GET and a simple

| test1
| test2
|
| test3

the line breaks are sent as URL-encoded "\r\n":

...&textfield=test1%0D%0Atest2%0D%0A%0D%0Atest3&. ..
Try entering this:

This is a very long line that exceeds the width of the text area without
having any hard carriage returns at all.

With a plain <textarea>, you'll get no separators. With wrap="hard",
you'll get line breaks wherever the user saw them in the <textarea>.
--
Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
Jan 16 '07 #13

P: n/a
..oO(Tim Roberts)
>Michael Fesser <ne*****@gmx.dewrote:
>>
It's also a security issue. Using plain links to change or delete
something on the server can become a problem or even a security risk.

I don't think that's really what you meant to say.
It is.
>There is no difference
in security between GET and POST. If there's something that is dangerous
as a GET, then it's dangerous as a POST.
There's a difference. Just two examples:

1) Web crawlers can follow links, but they usually don't submit forms
(let aside spam bots). In conjunction with other problems and bugs on a
site the result can be very drastic, see

http://thedailywtf.com/Articles/Best...r_of_Doom.aspx

2) The default request method for pages and other resources like images
etc. is GET. This can be abused as well to fool the browser into sending
a malicious request itself, see

http://groups.google.com/group/comp....c80631acf96223

There are good reasons why GET should not be used to change the server
state. That's what POST is for.
>>>Nope. That's not the problem. Another responder nailed it: you have to
tell the <textareathat you want the newlines by saying <textarea
wrap="hard">.

That's no HTML.

Of course it is. What would you call it?
A proprietary NN (or MS) invention. It's not part of the HTML standard.
>>I've tested Opera, FF, IE and Lynx - all browsers send correct line
breaks from a textarea, regardless of the used method (GET or POST).

Try entering this:

This is a very long line that exceeds the width of the text area without
having any hard carriage returns at all.

With a plain <textarea>, you'll get no separators.
Exactly, because there are none. The OP's problem, as he described it,
was explicit line breaks ("user pressed 'return key'") not making it
into his script, which is somewhat different.

Micha
Jan 16 '07 #14

P: n/a
On Jan 16, 12:36 pm, Michael Fesser <neti...@gmx.dewrote:
2) The default request method for pages and other resources like images
etc. is GET. This can be abused as well to fool the browser into sending
a malicious request itself, see

http://groups.google.com/group/comp....c80631acf96223
Michael, that example you linked to (by Joshua Bell) was an intriguing
scenario - I had never thought about that before.

However, there is one way to mitigate that. The ?delete=[id] should
still force a logged in member to re-authenticate (displaying a POST
form). I think this should work, although I haven't implemented
something like this.

Thanks for the food for thought. :)

Curtis

Jan 17 '07 #15

This discussion thread is closed

Replies have been disabled for this discussion.