How can I un-escape content when I use mysql_escape_string? 2

[southbeach]

I use mysql_escape_string() to write to MySQL tables. I have ran into a problem where operators open/edit/save records regularly and each time they save the record, an extra backslash is added to escape characters like quotes (most commonly used).

How do I reverse the escaped string so that I do not keep on adding \ as operators repeatedly save the records?

Thanks!


--
SouthBeach
The good thing about not knowing is the opportunity to learn - Yours truly, 2008.

 

[southbeach]

Well, I just found that I am using a deprecated function; I should be using mysql_real_escape_string instead. Further, it looks like stripslashes should do the trick.

What say you?


--
SouthBeach
The good thing about not knowing is the opportunity to learn - Yours truly, 2008.

 

[Foamcow]

Yes.
Sorry to be brief but that's sort of it

--
Tek-Tips Forums is Member Supported. Click Here to donate

<honk>*:O)</honk>

Tyres: Mine's a pint of the black stuff.
Mike: You can't drink a pint of Bovril.

 

[jpadie]

a few notes:

you need to instantiate the database connection before you can make use of mysql_real_escape_string().

you cannot reliably unescape string that have been escaped with this function. the charsets used for the addslashes and mysql_real_escape_string do not necessarily overlap.

best practice is that you escape the variables inside sql, rather than, for example, escaping the entirety of the $_POST superglobal. alternatively write all variables into an array and walk that array when you need to.

best of all is to use something like PDO and prepared statements (you don't need PDO to use prepared statements, but i prefer it). they will handle all escaping and enquoting.

something like this for example

$pdo  = new PDO($dsn, $username, $password);
$s = $pdo->prepare("Select * from tablename where id=?, name=?");
$s->execute(array(5, 'jpadie');
$results  = $s->fetchAll();
echo "<pre>".print_r($results, true) . "</pre>";

 

[southbeach]

@Foamcow, thanks!

@jpadie, As I read your post and looked up on the air and asked if a supersonic jet just flew over my head ... ???

I need to learn about PDO() and since I never seen/used prepare() nor execute(), fetchAll() I need to learn about those as well. I do not even know if these are PHP functions, some sort of a class (which appears to be a class judging from your syntax) or a custom solution you use.

Putting all thin on my agenda and I'm off to do my homework.

http://www.tipmaster.com/images/morning.gif

Thank you guys!



--
SouthBeach
The good thing about not knowing is the opportunity to learn - Yours truly, 2008.

 

[jpadie]

sorry.

mysql_real_escape_string checks out the character set in use by mysql and decides what to escape based on that information. this could be greater than those chars that are escaped by addslashes (which are just the single quote, double quote, the backslash and the null byte (NUL).

stripslashes reverses the effect of addslashes, it does not necessarily reverse the effect of mysql_real_escape_string, but it will do for those characters that do overlap.

i'm a big fan of db abstraction layers like db, mdb2 and pdo. in fact i'm a big fan of all abstraction layers, providing they are customisable. PDO is not quite a simple class, as it must be compiled in or installed by PECL. but it does behave just like a class.

 

[AdaHacker]

in fact i'm a big fan of all abstraction layers,

You know the old saying: Every problem in programming can be solved by adding a layer of abstraction (except the problem of too many layers of abstraction).

Seriously, though, while I agree with everything jpadie said - especially the PDO recommendation - I just wanted to add that the underlying problem (extra escape characters) sounds like a configuration issue. Perhaps you have magic_quotes_gpc and/or magic_quotes_runtime turned on. Explicitly "unescaping" stuff coming out of your database really shouldn't be necessary at all.

 

[southbeach]

AdaHacker,

I had magic_quotes_runtime OFF - They both are ON now.

If I am not misunderstanding you, this means:

If I use $table['field']=mysql_real_escape_string($var) when saving to a table, I should not do anything special when loading value back onto a form where user may edit and save record

Correct?





--
SouthBeach
The good thing about not knowing is the opportunity to learn - Yours truly, 2008.

 

[southbeach]

Had to turn magic_quote_runtime back OFF - My printing scripts stopped working :-(



--
SouthBeach
The good thing about not knowing is the opportunity to learn - Yours truly, 2008.

 

[jpadie]

please don't use magic_quotes of any sort. both runtime and GPC are unnecessary evils. I believe them both to be deprecated, if not removed, in php6.

Adahacker was suggesting that your original problem of double escaping might have been caused by some implicit escaping done through magic_quotes_runtime or, more likely, magic_quotes_gpc. This seems very likely. make sure that both of these are off. check the values in php.ini or phpinfo().

then you will have to cleanse the existing dataset.

 

[AdaHacker]

Sorry if I wasn't clear on that. I was thinking, for example, that you had magic_quotes_gpc turned on and were still manually escaping your data, which would lead to extra escape characters. You definitely don't want to turn either of those on if they're already off. They're both really stupid ideas that never should have been implemented in the first place. And, as jpadie said, they've been removed in PHP 6, so you shouldn't rely on them.