Hi,

I'm using htmlspecialchars() as an alternative to addslashes() - it's more reliable for entering RSA-encrypted data into MySQL without messing up the query.

However, the string needs to be returned to its precise original form for decryption, and there's no reverse form of htmlspecialchars(). I believe I could use a series of str_replace() calls, but I'm not clear on the syntax. Should the replace-with arguments be in the form ' " ' or ' \" ' ?

Appreciate any help.

    yeah there's no way to reverse it.

    try this:

    function specialchars($htmlchars)
    {
    	$htmlchars = preg_replace("/(&#)([0-9]*)(;)/esiU", "chr(intval('\\2'))", $htmlchars);
    	$htmlchars = str_replace(">", ">", $htmlchars);
    	$htmlchars = str_replace("&lt;", "<", $htmlchars);
    	$htmlchars = str_replace("&quot;", "\"", $htmlchars);
    	$htmlchars = str_replace("&amp;", "&", $htmlchars);
    	return $htmlchars;
    } 
    

      Thanks seby, this got me a little closer towards a solution.

      In the sense that it got me as far as identifying the next big problem (isn't it always the way...?)

      I realise, now that the data's in the table, that the characters in the encrypted string are from all different character-sets, and couldn't be retrieved. I think that's the case because I formatted the string using htmlentities() this time, but when I looked at the database contents it still contained euro, Yen etc., and lots of unprintable characters.

      I don't know if this is a limitation of PHP, MySQL or both, but I guess to store and preserve all content, I would need to systematically encode everything from every charset - which I get the feeling is just not gonna work (too much potential for error in the retrieval function, I would imagine).

      If you know different, or can point me towards some relevant info about different charsets and related notation, I'd be grateful.

        have you tried html_entity_decode() eg:

        <?php
        $orig = "I'll \"walk\" the <b>dog</b> now";
        
        $a = htmlentities($orig);
        
        $b = html_entity_decode($a);
        
        echo $a; // I'll &quot;walk&quot; the &lt;b&gt;dog&lt;/b&gt; now
        
        echo $b; // I'll "walk" the <b>dog</b> now
        

          Dannys: Thanks, another handy function I didn't know - I'll give it a try.

          Nick_perkins: thanks also. I'll try that when I can update my dev. setup (currently lagging on PHP 4.2.2 🙁 )

          EDIT: YES! The base64_encode worked a treat! The strings I'm working with aren't that big (and won't be stored for long periods anyway), so I think it's a fair trade-off. Not having to define a whole extra function (for multiple uses) saves a hefty amount of processing too.

          If anyone's interested, I'll drop the whole code into the critique section later. This is the culmination of various posts on this board, the goal being a way to avoid online credit-card validation services, store that data online for retrieval by admin, and still assure customers that even the (shared) server's admins can't get at their data (a.k.a. cheapskate eCommerce site 101). Thanks everybody!😃

            Write a Reply...