CGI/Perl Guide | Learning Center | Forums | Advertise | Login
Site Search: in

  Main Index MAIN
INDEX
Search Posts SEARCH
POSTS
Who's Online WHO'S
ONLINE
Log in LOG
IN

Home: Perl Programming Help: Beginner:
String Dilemma

 



waherne
Novice

Jun 20, 2000, 4:56 AM

Post #1 of 7 (1413 views)
String Dilemma Can't Post

Hi all,

This string dilemma is beginning to wear me down. I would appreciate any assistance that you can provide.

Basically, the situation is as follows:

1) A form on a webpage has a textarea named Box. A user can fill in several paragraphs of text.
2) A perl script sends the form output to the server and declares that $string=param(box).
3) The script then prints $string to a database (text or dat file).

My problem is in relation to (3). I want each $string entry to appear on one line in the database file. However, $string contains several paragraphs with the result that the database record will contain a new line for each paragraph in $string.

The irony is that when $string is then sent back to the browser, I want it to appear in its original format i.e. on several lines.

Any advice would be greatly appreciated.

Thanks again,

Willie


Kanji
User / Moderator

Jun 20, 2000, 11:04 AM

Post #2 of 7 (1413 views)
Re: String Dilemma [In reply to] Can't Post

You could probably get away with just ...

$string =~ s/\n/<br>/g;

... but I don't recall if the CGI spec standarizes EOLs (end of line) in input, so ...

$string =~ s/\n|\r\n|\r/<br>/g;

... may be better to catch the different types of EOLs.

Both assume you'll be returning the string to the browser as HTML. If not, you'll have to reverse the process, which could be awkward if there were some valid <br>'s in the string before you added more.

In vary rare instances, you might need to change those escaped characters to something more meaninful to your enviroment.


DrZed
User

Jun 20, 2000, 7:45 PM

Post #3 of 7 (1413 views)
Re: String Dilemma [In reply to] Can't Post

While the first answer was indead correct, I just wanted to offer the following two subroutines. They can be used anytime you need to avoid certain character (like you were trying to avoid newlines).

Example:

$string=encode($string,'\n');
# All newlines are now encoded

$string=decode($string);
# Any encoded charcters are now restored

Now, you wanted to 'hide' the newlines, I would assume, due to the way your data is formatted.

Sometimes you will also want to encode characters which you use to seperate bits of data on each line. For example, if your data was as follows:

name|password|date
....

Then you might want to do the following:
$string=encode($string,'\n|');

----------------------------------------

sub encode
{
my ($line,$chars) = @_;
my (@hex) = ('0','1','2','3','4','5','6','7','8','9','A','B','C','D','E','F');

if ($chars!~m/\%/) { $chars.='%'; }
$line =~ s|([$chars])|'%'.@hex[int(ord($1)/16)].@hex[ord($1)%16]|ge;
return $line;
}

sub decode
{
my ($line) = @_;

$line =~ s/\%([0-9A-Fa-f]{2})/chr(hex($1))/ge;
return $line;
}

----------------------------------------

Hmm... it occurs to me that the following two lines....

if ($chars!~m/\%/) { $chars.='%'; }
$line =~ s|([$chars])|'%'.@hex[int(ord($1)/16)].@hex[ord($1)%16]|ge;

....could simply be one line.

$line =~ s|([\%$chars])|'%'.@hex[int(ord($1)/16)].@hex[ord($1)%16]|ge;

Note, it's not technically the same, but the effect should be the exact same (and that's what matters).

The two-line version simply avoided the possibility that there would be two hashes in the string. However, given the nature of the search, it shouldn't matter.

Anyone, feel free to correct me if I'm wrong. I only added the 'forced' % just now. In my scripts, I've just made sure to include it in the list of chars to encode. I wanted this to be a bit more error-proof.

Dr. Zed

P.S. I edited the post to insert the missing line.

[This message has been edited by DrZed (edited 06-22-2000).]


waherne
Novice

Jun 21, 2000, 1:33 PM

Post #4 of 7 (1413 views)
Re: String Dilemma [In reply to] Can't Post

Thanks to both of you for replying.

I am using Dr. Zed's suggestion for the time being.

The encoding works a treat and puts all the paragraphs on one line as I wanted - perfection!

However, the decoding does not seem to work. I looked at the string before and after decoding and the black square followed by % is not removed after decoding. Dr Zed, I would really appreciate if you would look at the code again for me (or indeed anyone else that sees and understands! what's going on within the code).

Thanks,

Willie


DrZed
User

Jun 22, 2000, 7:53 PM

Post #5 of 7 (1413 views)
Re: String Dilemma [In reply to] Can't Post

Actually, I think it's the encoding that's actually failing and the decoding just can't make sense of the result.

I forgot on key bit:

my (@hex) = ('0','1','2','3','4','5','6','7','8','9','A','B','C','D','E','F');

The above is used by the encoding and should be added to it.

Also, in my example I used '\n' and it should have been "\n", unless your looking to hide a backslash and the letter n.

Dr. Zed

[This message has been edited by DrZed (edited 06-22-2000).]


waherne
Novice

Jun 23, 2000, 12:45 PM

Post #6 of 7 (1413 views)
Re: String Dilemma [In reply to] Can't Post

Folks,

I got it to work.

Thank you so much for helping me out here. I have learned so much over the last few days and several new tricks of the trade.

I hope that I can return the favour some time.

My next battle is to password protect certain files that I have on the server
- wish me luck!


Regards,

Willie


dws
Deleted

Jun 23, 2000, 4:22 PM

Post #7 of 7 (1413 views)
Re: String Dilemma [In reply to] Can't Post

If your TEXTAREA fields contain line breaks, the browser will send these to the webserver a <cr><lf> (\r\n). If you then slam these into a database field, depending on the database and depending on the field type, you might find that the database is doing some form of newline translation on your behalf, such that what you get back out is subtly different from what you put in.

You can strip out the \r by doing

s/\r\n/\n/g;

on your input field.

 
 


Search for (options) Powered by Gossamer Forum v.1.2.0

Web Applications & Managed Hosting Powered by Gossamer Threads
Visit our Mailing List Archives