473,241 Members | 1,797 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,241 software developers and data experts.

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

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
14 17857
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
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
How about the nl2br function? It converts newlines to <br />

http://us3.php.net/nl2br

Jan 14 '07 #4
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
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
"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
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
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
..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
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
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
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
..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
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 thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

6
by: Jonathan | last post by:
I want to save textarea contents to a mysql database with the paragraph breaks intact without having to type paragraph or break tags in HTML. How can I do that. So far, although it occurs naturally...
5
by: mailbox | last post by:
Did write it down once, but have forgotten !! How is it you should format your ASP code to that when viewing the resulting HTML text from the browsers "view code" it looks nice with line breaks?
1
by: teknowbabble | last post by:
I would like to know how to convert HTML code that users input into a TEXTAREA box on a HTML FORM into a separate WEBPAGE. I have something like the diagram below on my webpage. The user is...
2
by: Andrew Banks | last post by:
I have a text box which allows users to input the content for a HTML email. I need to maintain the line breaks as the user enters them in the text box when I send the email. I'm assuming I need...
5
by: joelbyrd | last post by:
Didn't know exactly where to post this, but: How do I get line breaks in a textarea? I'm pulling text from a database, and this text definately has line breaks in it, because I replaced all the...
1
by: John Wolff | last post by:
I’m trying to upload a file to a Web Service. I have to submit the file using a standard HTML form with the <input type=“file” /tag. Ultimately, we are submitting the file from a Flash 8...
4
by: Steve Marson | last post by:
I am using a simple form in modx CMS and I need the textarea to retain the line breaks. I'd prefer a javascript solution if possible. This is because the textarea will be used to order food and...
0
by: fareedcanada | last post by:
Hello I am trying to split number on their count. suppose i have 121314151617 (12cnt) then number should be split like 12,13,14,15,16,17 and if 11314151617 (11cnt) then should be split like...
0
by: stefan129 | last post by:
Hey forum members, I'm exploring options for SSL certificates for multiple domains. Has anyone had experience with multi-domain SSL certificates? Any recommendations on reliable providers or specific...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, youll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: Aftab Ahmad | last post by:
Hello Experts! I have written a code in MS Access for a cmd called "WhatsApp Message" to open WhatsApp using that very code but the problem is that it gives a popup message everytime I clicked on...
0
by: Aftab Ahmad | last post by:
So, I have written a code for a cmd called "Send WhatsApp Message" to open and send WhatsApp messaage. The code is given below. Dim IE As Object Set IE =...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.