You are here: Re: [PHP] mysql + addslashes + stripslashes « PHP « IT news, forums, messages
Re: [PHP] mysql + addslashes + stripslashes

Posted by Richard Lynch on 05/17/05 05:00

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 <petzo@mreja.net> 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

 

Navigation:

[Reply to this message]


Удаленная работа для программистов  •  Как заработать на Google AdSense  •  England, UK  •  статьи на английском  •  PHP MySQL CMS Apache Oscommerce  •  Online Business Knowledge Base  •  DVD MP3 AVI MP4 players codecs conversion help
Home  •  Search  •  Site Map  •  Set as Homepage  •  Add to Favourites

Copyright © 2005-2006 Powered by Custom PHP Programming

Сайт изготовлен в Студии Валентина Петручека
изготовление и поддержка веб-сайтов, разработка программного обеспечения, поисковая оптимизация