>Well, I appreciate your input.  But the backslashes are (well, were) there.
>And I wasn't putting them in.  Here's what the sequence was:

If you leave the default of "Magic Quotes" "on" in php.ini, you are adding
the backslashes on every GET/POST/COOKIE data element as it comes in.

>I have a form that an administrator fills out to send an email newsletter.

Magic Quotes will add one set of backslashes at that point, for the POST
which it assumes you are putting into a database, since that's what 90% of
PHP scripts do.  Take GET/POST data, stuff it into a database.

>The form has a confirmation page that it submits to.  At this point the

At this point, you are writing out an HTML page with the "extra" set of
backslashes that Magic Quotes added.  You should have stripslashes() on the
data that you dump out to the confirmation page.

Also, use htmlentities to convert any HTML "special" characters to their
HTML character entities so they don't mess up your HTML.

>admin either goes back to make changes or submits the text and subject to be
>sent out as a newsletter.  It is on this page that the data gets stuck into

Now, on *this* page, the Magic Quotes is actually helping you, since you can
stuff the data into the database and it's already had the addslashes done to
it.  Magic Quotes essentially just calls addslashes on every GET/POST/COOKIE
datum *for* you.

>the database (mysql).  If the user hits 'send email' button the next page
>retrieves the data from the database, and sends out emails based on what it
>gets in the database, after a call to stripslashes.  What was coming in the

If you have correctly managed your data throughout the application "path"
from input to MySQL, then once you have inserted your data to MySQL, there
should be no bogus/extra backslashes in it.

You should *NOT* need, in general, to call stripslashes on data coming *out*
of MySQL.

If you do, you did something wrong a long, long time ago when you inserted
it or collected it.

>mail had three! backslash characters behind everything mysql had escaped.
>More stripslashes calls did nothing, the ereg_replaces you reviewed did
>nothing.  Oddly, the solution turned out to be
>$text = ereg_replace("[\\]+", "", $text);

While I'm happy this "works" for you, it's a very grungy hack that only
masks the real problem, which is described above.

>which would seem to me to be functionally equivalent to either of the calls
>that didn't work, but somehow PHP liked it better.  The data you gave on why
>"\\" wouldn't work as a regex didn't quite make sense to me, as PHP turning
>that into "\" was exactly what I was looking for.  Theoretically, that

You had "\\\\\\" and "\\", both of which are incorrect.

By enclosing the \\ inside of [], Regex apparently automatically understands
that you mean the character \ rather than treating \ as special, which is
does if you have just "\".

Your original "\\" in PHP turns into "\" in Regex, as I described.
And "\\\\\\" turns into "\\\" in the same way.

>should then match every "\" character in the string, but it didn't manage to
>find any - in fact it just gave the error message, and I still don't know
>why. Why wouldn't PHP then just match the "\" characters?  Doesn't make

\ is a special character in PHP strings.
When you have "\" in PHP, it's just inherently "wrong" though you can get
away with it.
But if you have "\\" it turns into "\" internally.

\ is *ALSO* a special character in Regex.
So if you want to get *ONE* \ in Regex, you need "\\\\" in PHP.

>And I'm frankly still a bit of a loss as to where they came from in the
>first place.  Perhaps HTML added a set, then PHP escaped those, then mysql
>figured it had better escape them all.  I don't know.  I tried turning
>magic_quotes off for the script's execution, but this did not cut down on
>the number.  Before the initial call to stripslashes() there were actually
>SIX of them in a row, stripslashes() cut that to 3, but then refused to
>shave them further.

If changing Magic Quotes to "off" only lost half the \'s, then you almost
for sure have an addslashes in your code *SOMEWHERE*.  It might be buried in
some database class you are using, but it's there.

>Why?  Ya got me.

I know why.  Perhaps this time around you'll actually me...

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

Reply via email to