Citat:
I think I understand Jared's confusion. I've seen tutorials that tell you
to addslashes() on inserting into the db and stripslashes() on the way out.
Chris Shiflett:
I understand.
Unfortunately, there are many bad practices taught in articles. This particular example isn't as bad as some I've seen. It has two flaws that are immediately evident, based upon your brief description:
1. addslashes() needs to be considered a last resort. It can help, and I do recommend that people use it when there is nothing else, but if you are using a popular database such as MySQL, there is going to be a better alternative. Articles need to be teaching people to look for a native escaping function specific to their database before resorting to addslashes().
2. Instructing people to use stripslashes() when they receive data from the database makes them believe that the escaping modifies the data. As you correctly point out, this isn't true. Thus, rather than the article helping developers understand how something works, it is hurting them. Another minor point is that this step modifies the data. For example, if the string is:
Code:
Escape single quotes (') with a backslash (\').
The escaped string will be:
Code:
Escape single quotes (\') with a backslash (\\\').
What is stored in the database is:
Code:
Escape single quotes (') with a backslash (\').
What is returned after stripslashes() is run is:
Code:
Escape single quotes (') with a backslash (').
That's probably not the desired behavior. :-)
Citat:
The escape characters themselves are not stored in MySQL
That's right. The escaping is only to make sure the query isn't modified by the data. The data itself is preserved, which is the whole point of escaping.
Am I right on this?
Yep. :-)
Chris