CR (\r\n) doing my head in 1

[1DMF]

Hi,

I'm a bit confused, nothing new there then!

I have a form, it populates a SQL DB, on it is a textarea for an address, when filled out and saved to the DB, each newline in the textarea is saved as \r\n (carriage return, linefeed).

ok no porblem, but when the data is displayed back again to the form there is a blank line between each line in the textarea.

WHY?

If hitting enter supplies the DB with \r\n , why when displayed back to the textarea it has a gap between each line, as if it is interpreting \r and \n as two separate commands and so creating the space.

if I save back to the DB, and redisplay there are three blank lines between each line in the textarea , and so on and so on...

How do handle these?

i can't simply change them to \r or \n before displaying on the form, because the backend when the field displays on the DB, it shows each line as pipe separated filed and not display correctly.

and I can't before saving back to the DB change any \r or \n back to \r\n , as if a new line was added in the text area i would have some lines \r and some \r\n , so replacing \r would leave some lines as \r\n\n , which creates two lines in the textarea again.

This must be something simple to handle, can someone advise on the standard way of dealing with this please.

Thanks,
1DMF.

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!

 

[1DMF]

lol - on display I do this..

#fix carriage returns
$rs[0]{'Address'} =~ s/\r\n/\n/g;

instead of this....

#fix carriage returns
$rs[0]{'Address'} =~ s/\r\n/\r/g;

man - talk about stupidly obvious!

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!

 

[Kirsle]

Something to note about carriage returns is:

http://en.wikipedia.org/wiki/Line_feed#Newline_in_programming_languages

Basically, \n in Perl (because of C) isn't necessarily LF. It takes the native EOL character set for your operating system. So, on Linux for example, \n is LF and \r is CR, but on Windows systems, \n is CRLF and \r is CR.

So, the following code on Windows:

print "Content-Type: text/html\r\n\r\n";

is essentially doing

print "Content-Type: text/html\r\r\n\r\r\n";

So what I do when EOL characters are seriously important (for example, when talking to a very picky TCP server that will drop and ban your IP if you mess up the EOL characters) is to use them explicitly by their hex codes.

$sock->send ("40|1\x0d\x0a");

# \x0d = \r
# \x0a = \n

It depends on how picky the server is about that and what OS you're running the script on. On Linux, \n is \n and it'd be fine, but the same scripts may break on Windows when \n becomes \r\n and a server isn't expecting that.

-------------
Cuvou.com | My personal homepage
Project Fearless | My web blog

 

[1DMF]

Thanks for the interesting insight.

I found that the textarea was supplying the ActiveState Perl with \n , but that was being interpreted by the SQL server as \r\n when entered into the db (represented by two square blocks)

So when taking data from the DB I have to convert \r\n to \n when putting the data into a text area form field.

I don't have to worry coming back the other way as the SQL server seems to convert the \n into \r\n when being updated.

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!