Joel Kitching <mailto:[EMAIL PROTECTED]>
on Wednesday, June 30, 2004 10:34 AM said:
> What's wrong with addslashes() on the way in and stripslashes() on the
> way out? Why would you want to convert it to it's HTML entity?
1. addslashes() is not as robust as other solutions like
mysql_escape_string().
2. in either case the slashes will be non-existant when the data is
actually inserted into the database.
for example:
$mystring = "hello here is my string. it has an ' (apostrophe) in it.";
$sql = "
INSERT INTO data
(thestring)
VALUES ('$mystring')";
when then is parsed it will look like this:
INSERT INTO data
(thestring)
VALUES ('hello here is my string. is has an ' (apostrophe) in
it.')
as you can see the ' in the original string is going to cause a problem.
by escaping it with mysql_escape_string() (or another comparable
function) you'll get the following:
INSERT INTO data
(thestring)
VALUES ('hello here is my string. is has an \' (apostrophe) in
it.')
this string, although it now contains a slash that we originally did not
want, this slash not exist once the data is actually inserted into the
database. it's merely there to tell the database "hey, please ignore the
' that comes directly after me".
soooo... when you pull the data *out* of the database the \ will not
exist and you therefore do not need to perform stripslashes().
and now to the second part... why use htmlentities()? that is for
displaying data within a form element OR (i hope i have this right)
preventing XSS (Cross Site Scripting attacks).
hope this helps!
chris.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
