Link to home
Create AccountLog in
Avatar of DrDamnit
DrDamnitFlag for United States of America

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?
Avatar of Cornelia Yoder
Cornelia Yoder
Flag of United States of America image

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.
Avatar of 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:
User generated image
It's printing the literal HTML on the screen. (I am not using <pre>).
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
Avatar of Dave Baldwin
Dave Baldwin
Flag of United States of America image

Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
@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?
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.
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.
@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.
"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".