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 "\" :-) :-) :-) -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
