What Does MySQL_Real_Escape_String() Do That Addslashes() Doesn'T

What does mysql_real_escape_string() do that addslashes() doesn't?

Addslashes is generally not good enough when dealing with multibyte encoded strings.

mysql_real_escape_string VS addslashes

What you quote is probably from the doc, but as far as I know it's not necessarily true.

addslashes adds slashes to characters that are commonly disturbing. mysql_real_escape_string escapes whatever MySQL needs to be escaped. This may be more or less characters than what addslashes takes care of.

Also, mysql_real_escape_string will not necessarily add slashes to escape. While I think it works if you do it that way, recent versions of MySQL escape quotes by putting two of them together instead of by putting a slash before it.

I believe you should always use your data provider's escape function instead of addslashes, because addslashes may either do too much or not enough work for the purpose you use it. On the other hand, mysql_real_escape_string knows what to do to prepare a string for embedding it in a query. Even if the specs change about how to escape stuff and suddenly it's not backslashes that you should use anymore, your code will still work because mysql_real_escape_string will be aware of it.

Why use mysql_real_escape_string, doesn't addslashes prevent everything?

There is a great article about this here. And this discussion also points out the pros and cons of each solution.

addslashes() was from the developers
of PHP whereas
mysql_real_escape_string uses the
underlying MySQL C++ API (i.e. from
the developers of MySQL).
mysql_real_escape_string escapes EOF
chars, quotes, backslashes, carriage
returns, nulls, and line feeds. There
is also the charset aspect.

What is the difference between mysql_real_escape_string and addslashes?

string mysql_real_escape_string ( string $unescaped_string [, resource $link_identifier ] )

mysql_real_escape_string() calls MySQL's library function mysql_real_escape_string, which prepends backslashes to the following characters: \x00, \n, \r, \, ', " and \x1a.

string addslashes ( string $str )

Returns a string with backslashes before characters that need to be quoted in database queries etc. These characters are single quote ('), double quote ("), backslash (\) and NUL (the NULL byte).

They affect different characters. mysql_real_escape_string is specific to MySQL. Addslashes is just a general function which may apply to other things as well as MySQL.

Confusion about mysql_real_escape_string and strip_slashes

Thank you everyone for the answers. I will award the +50 out, but I wanted to tell my real solution here, all which people did help with...

I was performing mysql_real_escape_string on all of the data AS SOON as it posted (before any processing). So, a slash was added to escape the ' character that was submitted. This, we know is normal.

However, there was no reason that the backslash \ should show up in the DB entry, right? The escape was there to be sure the ' was entered.

Turns out, AFTER escaping, I would then save the variable to be reloaded to the page in the session, in case the user had an error that PHP found while validating all of the form fields. In this case, the user's input (formerly O'riley was now printed to their screen as O\'riley. Then, the user didn't catch this - so they would often just fix their error that PHP caught during validation (unrelated to the name field), and thus the O\'riley would land in the database because mysql_real_escape_string would escape the characters.

Lesson:
When processing a form, FIRST save data for form-refill use. SECOND validate form fields. THIRD escape the data for processing into the database.

Or better yet, use PDO and avoid this =).

Comments welcome. THANKS ALL!

mysql_real_escape_string strange apostrophe behaviour?

What's happening is this:

mysql_real_escape_string escapes all the characters that should be escaped by adding a slash in front of a character being escaped. But adding just a slash will lead to storing the character as unescaped within the DB, therefore also the slash must be escaped prior to inserting...

That's why You have My BDay\\\'. If this value is stored into a DB the final result will be My BDay\'.

But when You do str_replace("'", "", 'My BDay\\\''); You will end up with My BDay\\\ and after calling stripslashes on this You will get My BDay\ - that is absolutely correct!

So don't bother with how the string looks like after calling mysql_real_escape_string, just store that value into the DB and after retrieving it You will end up with My BDay' again...

EDIT How You come to just one slash from the three after calling stripslasshes? The function goes from the start of the string to its end and looks for any slash escaped characters to remove the escaping slash. So it finds first two slashes and removes one, but still two remains (the one just processed and the third one), so it processes next two slasshes it finds that will result in just one slash remaining...

If You'd call stripslashes on the string My BDay\\\' - that will lead to My BDay'...

EDIT2 My bad... The next two slashes are added probably because You have magic_quotes_gpc ON - turn that off or call mysql_real_escape_string(stripslashes($string)).

The mysql use of addslashes()

addslashes is the rough equivalent of str_replace($str, "'", "\\'"). You can bypass it trivially with any number of unicode sequences that evaluate down to ' in mysql, but look completely different to addslashes().

Mysql_real_escape_String() on the other hand, uses the actual internal mysql escaping function, which knows exactly what to look for and fix to make it "safe" for mysql. What works for mysql may not work for another database, as each has slightly different escaping semantics and requirements, but if you're working with mysql, then the "real escape string" is the way to go.

---

Related Topics