Thank you VERY much for you detailed reply.
Especially that part:
"
MySQL "sees" the \' and "knows" that is an embedded apostrophe and saves
your data as "Joe's Grill" down in the guts of MySQL files. Note that
MySQL does *NOT* *NOT* *NOT* store \' as part of the data. The \ is
simply a marker that the MySQL engine "eats" once it understands that it
means: "The following character is DATA, nor part of my SQL begin/end
marker"
"
It was very informative and I almost knew everything except that part that I
quoted you.
After a little thinking I think that it is a good idea to check if
magic_quotes_runtime is set to On for incoming MySQL data and if the data
will be "slashed" :).
Milen
----- Original Message -----
From: "Richard Lynch" <[EMAIL PROTECTED]>
Newsgroups: php.general
To: "Pieter Breed" <[EMAIL PROTECTED]>
Cc: "Petzo" <[EMAIL PROTECTED]>; <php-general@lists.php.net>
Sent: Tuesday, May 17, 2005 5:00 AM
Subject: Re: [PHP] mysql + addslashes + stripslashes
> On Mon, May 16, 2005 5:16 am, Pieter Breed said:
> > My problem is that I have a large array (without any funnies like
> > self-referencing) getting serialized. There are some funnies in the
string
> > fields though (like `'`s etc). After making a roundtrip to the mysql
> > database, things start to get bad on me since I cannot unserialize the
> > text
> > anymore. This only happens for some of the arrays that I have. Other
> > arrays
> > with similar data can get serialized and unserialized just fine.
> >
> > I do suspect though, that the problem lies with how I am using
addslashes
> > and how I am not using it. Any definitive help would be much
appreciated.
> >
> > On 5/16/05, Petzo <[EMAIL PROTECTED]> wrote:
> >> My question is about the norlmal behaviour of PHP and MYSQL but I cant
> >> explain it without a simple example. Thank you for reading:
> >>
> >> I have the following code:
> >> --------------------------------------------------------------------
> >> <?php
> >> print $t = $_POST['txt'];
> >> print $t = addslashes($t);
>
> For the Record:
>
> If you have Magic Quotes "ON" then Magic Quotes has ALREADY called
> addslashes() on all your $_POST elements, including 'txt'
>
> If you then call addslashes() on that data, you are escaping the escape
> characters, which are then interpreted and stored by MySQL as data.
>
> And while extra extra cherries might be Good; extra extra addslashes is
> very Not Good.
>
> Consider this example:
>
> <form><input name="txt" value="Joe's Grill"></form>
>
> Magic Quotes ON | Magic Quotes OFF
> <?php echo $_POST['txt'];?> | <?php echo $_POST['txt'];?>
> Joe\'s Grill | Joe's Grill
> <?php $t = addslashes($_POST['txt']); ?> | (same code)
> <?php echo $t;?> | <?php echo $t;?>
> Joe\\\'s Grill | Joe\'s Grill
> /* insert into MySQL */
>
> Now, the MySQL engine will INTERPRET the data you hand it:
>
> If there was NO addslashes at all (not shown above) with NO Magic Quotes
> and without you calling addslahes(), your query would look like:
>
> INSERT INTO something VALUES ('Joe's Grill')
>
> That is a SYNTAX ERROR because the ' inside of Joe's looks like the END
> MARKER for the string.
>
> If you had *ONLY* Magic Quotes or *ONLY* addslashes your query is Good:
>
> INSERT INTO something VALUES ('Joe\'s Grill')
>
> MySQL "sees" the \' and "knows" that is an embedded apostrophe and saves
> your data as "Joe's Grill" down in the guts of MySQL files. Note that
> MySQL does *NOT* *NOT* *NOT* store \' as part of the data. The \ is
> simply a marker that the MySQL engine "eats" once it understands that it
> means: "The following character is DATA, nor part of my SQL begin/end
> marker"
>
> Now, finally, if you have *BOTH* Magic Quotes *AND* addslashes() you get:
>
> INSERT INTO something VALUES ('Joe\\\'s Grill')
>
> Because Magic Quotes called addslashes, then *you* ALSO called addslashes,
> so *YOUR* addslashes escaped the escape characters that Magic Quotes had
> already added.
>
> MySQL then believes that both the \ and the ' inside of Joes are DATA and
> not part of your SQL end markers, and MySQL then stores: "Joe\'s Grill"
> which is *NOT* what you want in your data.
>
> You've got to check if Magic Quotes is ON, and if it is ON do *NOT* call
> addslashes() on your data.
>
> If you want the new-fangled Improved Way, you would detect that Magic
> Quotes is ON, use stripslashes() to un-do Magic Quotes' addslashes(),
> validate and scrub the data to be *SURE* it's kosher, and then call
> mysql_real_escape_string on the data to put back in the escape characters
> that Magic Quotes was putting in for you.
>
> ALSO:
> Note that if you take the data *AFTER* Magic Quotes, or addslashes() or
> mysql_real_escape_string, and then you put that data into a FORM or a
> HIDDEN INPUT or even a GET (URL with a ? in it) then you are going to get
> all messed up. Because you'll end up having Magic Quotes and/or
> addslashes and/or mysql_escape_real_string being called on it AGAIN which
> is pretty much the exact same problem outlined above.
>
> Data that has been escaped by Magic Quotes, or addslashes, or
> mysql_escape_real_string was intended to be put into MySQL. It was *NOT*
> intended to be dumped out to the browser in a FORM, nor in a URL, nor
> stored in Cookie, nor stored anywhere else *except* into MySQL.
>
> Hope that helps.
>
> --
> Like Music?
> http://l-i-e.com/artists.htm
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
