Re: Re-inserting newlines

On Jun 23, 2005, at 4:13 PM, Richard Lynch wrote:

On Thu, June 23, 2005 11:09 am, Philip Thompson said:

On Jun 23, 2005, at 12:20 PM, John Nichel wrote:

Philip Thompson wrote:

Anyone know how/what to replace the \r\n in the textarea to that it shows up correctly with the actual newlines, not the \r\n???

http://php.net/stripslashes Your mysql_escape_string basically added slashes. Actually, you *MIGHT* have Magic Quotes "on" in which case your real problem is that *TWO* different mechanisms are adding slashes. Magic Quotes calls http://php.net/addslasehes on everything in $_POST (and $_GET) Then, you call mysql_escape_string, and add a *SECOND* set of slashes. Don't do that, first of all. If Magic Quotes is "on" call stripslashes before you call mysql_escape_string, or you'll just corrupt your data before you insert it. Also, the data you are inserting to the database, complete with escaped characters, should not really be the data you are re-presenting to the user if they need to change it. You should be showing them un-escaped data. Now, the data that comes back *OUT* of MySQL when you SELECT data that you previously INSERTed is un-escaped -- The whole *point* of the escape characters is to add characters that the MySQL parser "eats up" when it reads in your data, thus correctly interpreting characters that would otherwise be "special" But the data you just tried to insert into MySQL, and didn't, for whatever reason, is "escaped" data, and not suitable for presenting to the User. If there is a mysql_unescape, use that. If not, in an ideal world, present them with the exact same data they gave you -- Only if you have Magic Quotes "on" then you've already got http://php.net/addslashes called on it, before you ever really saw it, so you still need to do http://php.net/stripslashes to it.

You shouldn't need \r\n. \n should work just fine.

Yes, but... The \r\n came about because his user is on Windows with a Windows browser with Windows newlines. While the browser and TEXTAREA are "smart enough" to handle \r\n or \n or even just \r "the same" there's no need to jump through hoops to strip out the \r for what you send back to the User if the data was "bad" You *DO* want to convert \r\n and \r to \n for consistency in your database, probably... Or maybe not... I prefer to do that, but that's just me, maybe.

How are you 'inserting' the newlines? Single quoted string?

That's the thing, I'm not inserting \r\n at all. When filling in the form, I hit "Enter" to go to the next line in the textarea. When I pull the original data I do:

If you try it from a Linux browser, you're only gonna have \n If you try it from a Mac browser, you're only gonna have \r Windows is sending you \r\n, so that's what you got. Deal with it, and be prepared to deal with just \r and just \n.

$textarea = mysql_real_escape_string($_POST["textarea"], $connection); if ($error) {

     // somehow replace the \r\n that mysql_real_escape string put in

     // then strip all the other slashes remaining: \' becomes '
     $textarea = stripslashes($textarea);

     // return to page

} That clarify it a bit?

If that is what you are doing, and it works, then your REAL problem is, indeed, that Magic Quotes is "on" *AND* you are doing mysql_escape_string, so you are double-addslashing (in effect). Do *NOT* do that. You'll make a mess of your data real fast. Then you'll end up using http://php.net/stripslashes on data coming *out* of MySQL, because it has bogus extra \ in it, because you double-addslashes before you did the INSERT. This is a very common newbie error, and I can guarantee there are millions of "working" scripts out there on the 'net that do exactly that: Magic Quotes "on" does addslashes Naive programmer does addslashes in PHP Naive programmer sees bad data coming out of MySQL and does stripslashes Two wrongs don't make a right. You'll end up having data problems any time you want to use that data anywhere else other than that broken application. Use the example posted earlier to call stripslashes if Magic Quotes is on. Store *THAT* string as what to send back to the User. Use mysql_escape_string on that previous result. Use *that* for your INSERT. If there is a mysql_unescape_string, you could do that instead of storing the result of your possible stripslashes... Kinda ugly, though, particularly if your mysql_escape_string chops of 99% of War and Peace because there is a semi-colon (;) in the first paragraph, and it looks like a hack attempt. The User will not be real happy that your mysql_escape/unescape threw away 99% of what they typed... I'm NOT claiming this is what mysql_escape_string *DOES* -- Only that it's something reasonable like that which it *could* do at some point, if the string looks funky enough to look like an "attack" on MySQL security. --Like Music? http://l-i-e.com/artists.htm

Well, that was a mouthful. I actually am using a Mac and it showed \r\n to me. What I think I will do is not use mysql_real_escape_string until I want to actually insert it into the database. So the information I re-display back to the user *should* be the same as what they wrote. Thanks for your inputs. I appreciate each of you. ~Philip