[Resolved] What's the converse of htmlspecialchars()?

Havin_it2

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.

seby

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("&gt;", ">", $htmlchars);
	$htmlchars = str_replace("&lt;", "<", $htmlchars);
	$htmlchars = str_replace("&quot;", "\"", $htmlchars);
	$htmlchars = str_replace("&amp;", "&", $htmlchars);
	return $htmlchars;
}

pyro

http://us3.php.net/manual/en/function.get-html-translation-table.php

Havin_it2

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.

dannys

You could always get around the problem by simply using base64_encode/base64_decode on your data.
The encoded data is on average 33% larger than the original but I think that's the only disadvantage.

http://php.net/base64_encode
http://php.net/base64_decode

nick_perkins

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

Havin_it2

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!😃