> 1. addslashes() is not as robust as other solutions like
> mysql_escape_string().
What exactly is the difference between the two?
> 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().
I tried using addslashes() on the string in the query, and then
SELECTing it, and the slashes are included. Does
mysql_escape_string() not do this?
>
> 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.
>
>
--
Joel Kitching
http://midgardmanga.keenspace.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
