Richard Lynch schrieb:
On Wed, November 29, 2006 11:55 pm, Johannes Lindenbaum wrote:
But... magic_quotes.
If my understanding is correct magic quotes will give ', " and \ (for
ASCII characters, e.g. \n) a preceding backslash to escape it. I also
see that magic_quotes_gpc() is On by default. So all data in $_POST
and
$_GET etc. has escaping backslashes.
Yes, but the problem is that *ALL* data in GET/POST has the escaping
backslashes as if it were ASCII data, and it may *NOT* be ASCII data.
It might be UTF-8.
It might be UTF-16.
It might be some charset you've never even heard of.
And guess what?
addslashes() on non-ASCII data, UTF-8 for example, is like a condom
with a hole in it.
If in a .htaccess I should set
php_flag magic_quotes_gpc Off
That would lead to $_POST data like Jingle's Bells to be passed as
Jingle's Bells, not Jingle\'s Bells. Usually most of my $_POST data
gets
written into a MySQL table to which I perform addslashes().
Switch to:
http://php.net/mysql_real_escape_string
And on
retrieval stripslashes().
No, no, and no.
You do *NOT* use stripslashes() on the data coming OUT of MySQL.
Unless you've already screwed up and done BOTH addslashes() and
MagicQuotes, which in essence did addslashes() twice, so you added
bogus data to your database.
Jingle's Bells
+ [magic quotes] ===> Jingle\'s Bells
+ [addslashes] ===> Jingle\\\'s Bells
========================================
Corrupt data in MySQL: Jingle\'s Bells
The whole point of this escaping is to identify characters that MySQL
should store as data, rather than interpret as "non-data"
Jingle's Bells
+ [magic quotes *OR* addslashes *OR* mysql_real_escape_string]
=====> Jingle\'s Bells
==============================================================
Correct data in MySQL: Jingle's Bells
Once you've done that correctly, what MySQL actually stores is the
data, not the escapes it needed to identify the data.
So if you find yourself using stripslashes() on your MySQL data to get
it "right", then, in reality, you've already screwed up and stored
non-data as data.
So go back and fix your script to NOT double-escape the input, then
fix your bad data in MySQL to NOT have non-data (\ escape character)
as part of your data.
This is going to be a major pain, I know, but you'll only make it
worse the longer you put it off.
It will be a whole lot easier if you can "freeze" the input routines
to not take anything in between the time you fix those and when you
fix the data within the database...
If not, you'll want to note EXACTLY which rows have corrupted extra
backslashes and which do not, so you can apply stripslashes() to only
the corrupt data.
If I keep on doing that - and just start coding with magic_quotes_gpc
Off - my scripts shouldn't alter behaviour upon PHP 6 arrival, should
they?
You are correct that turning off magic_quotes_gpc is a good way to
prepare for PHP 6.
This has been rant #53, brought to you by the character "\"
:-) :-) :-)
Thank you very much all of you - I know what I'm doing with my weekend.
I think I was disillusioned by the fact that I had a couple Queries
screw up because they were of the format (example):
INSERT INTO table (text) VALUES( '".$_POST['data']."');
where $_POST['data'] was filled with something similar to Jingle's Bells
(a single quote), thus screwing up the query, because it was trying to
do VALUES( 'Jingle's Bells');
So by pure ignorance I just added addslashes infront of my queries.
I've come a long way since then, and I'll probably just end up writing a
smartQuoting function for my MySQL class that will use
mysql_real_escape_string() on INSERTS so I have the correct data in my
table. :)
Thanks again!
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
