asked on

mysqli::real_escape_string creates \r\n problems?

I have a form where the users use TinyMCE to fill out some information, and that form is then POSTed, and stored in a database.
The problem appears to be that mysqli::real_escape_string is turning carriage return line feeds into escaped versions of themselves, and storing them. Well... that is part of the design. But when I re-read the database, and run stripslashes() on the data as it is read from the DB, I get output like this:

Here si some good HTML code
rn
But you can see
rn
that there are annoying
rn
"rn" on blank lines between everything.

How can I store HTML in the DB, and retrieve it without having this \r\n problem?

Cornelia Yoder

You can use htmlentities() function to change all the special characters to their HTML & code equivalents. This will store the codes rather than the special characters themselves.

It is just as safe (in my opinion, safer) than mysql_real_escape_string() and will print exactly the same.

http://us1.php.net/manual/en/function.htmlentities.php is the function documentation.

http://www.ascii.cl/htmlcodes.htm shows you the HTML codes.

The only drawback is that it will take 4-5 bytes in your database to store each special character.

DrDamnit

ASKER

OK. I did that.

I am now using $b = htmlentities($b)

Then storing that in the DB as it is rendered with htmlentities().

When I retrieve it from the DB, I do:

$output = $html_entity_decode($b);

Then:
echo $output.

Here's what I get:

It's printing the literal HTML on the screen. (I am not using <pre>).

DrDamnit

ASKER

Expected Behavior / Actual Behavior / Steps to reproduce are already in the page (This is a our bug tracker).
The code beneath those heading is getting echo'd out.

ASKER CERTIFIED SOLUTION

Dave Baldwin

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

DrDamnit

ASKER

@Dave

I am just as confused as you are.

This is some legacy code that I wrote nearly 10 years ago.

I *think* at the time, I was using mysql_escape_real_string() to prevent sql injection attacks.

The problem now is that I get decent HTML from TinyMCE POSTed to the script, it is loaded into a class that handles this. The class uses mysqli::real_escape_string() prior to storing the data int he DB.

stripslashes is (I guess) supposed to reverse what mysqli::real_escape_string is doing. But from the tone of your comment (as well as the question, "why are you using stip slashes when you didn't use addslashes), it is wholly unneeded?

DrDamnit

ASKER

Your comment got me going in the right direction. I ended up using addslashes and stripslashes.

the htmlentities() suggestion did not work because oddball characters were causing some of the SQL queries to fail.

Dave Baldwin

Glad you got it sorted out. Thanks for the points.

You might try a version without addslashes and stripslashes. I don't think you need them. mysqli::real_escape_string is not supposed to need reversing, it is supposed to 'automatically' be taken care of by the 'mysqli' driver. I know that I'm not adding anything to my code to do that.

DrDamnit

ASKER

@Dave:

I tried it both ways, and while i have not put the data from the POST into a file so I can look at it in a hex editor to see what's actually going, real_escape_string was definately adding the \r\n when inserting HTML from TinyMCE into the DB. It was clear as day in the column when I look at it directly in MySQL workbench.

What's interesting, is that this code has been in use and production for a decade in hundreds of applications. (It's part of a code generator we use to abstract databases), and it has worked flawlessly for 10 years.

It must have something to do with how TinyMCE is interacting with it.

Dave Baldwin

"real_escape_string" is supposed to add those escape sequences on INSERT... and translate them back to the original characters on SELECT. So yes, you should see them in the database when using "real_escape_string" before INSERT.

TinyMCE could be messing up the sequence if it is trying to recode or escape the characters itself before the "real_escape_string".