Description: ------------ simple string with no html has some characters stripped out. seems the repackUTF7* functions do this. Test script: --------------- $parser =& new HTML_Safe(); $x = $parser->parse('a+b-c'); var_dump($x); Expected result: ---------------- string(5) "a+b-c" Actual result: -------------- string(2) "ac"

I've to use next patch: function repackUTF7($str) { return preg_replace_callback('!\+([0-9a-zA-Z/]{2,})\-!', array($this, 'repackUTF7Callback'), $str); } function repackUTF7Callback($r) { $str = base64_decode($r[1]); if ($str === false) { return $r[1]; } $str = preg_replace_callback('/^((?:\x00.)*)((?:[^\x00].)+)/', array($this, 'repackUTF7Back'), $str); return preg_replace('/\x00(.)/', '$1', $str); }

Test script: --------------- $parser = new SafeHTML(); $x = $parser->parse('+49-52 <br />'); var_dump($x); Expected result: ---------------- string(13) "+49-52 <br />" Actual result: -------------- string(12) "�52 <<r></r>"

Isn't it better to replace all "+" with &#43;, disabling UTF-7 decoding, then "repack" them? AFAIR, + is not part of any HTML tag or attribute, and in attribute value &#43; works as well as in text, i.e.: <a href="http://www.google.com/search?q=SafeHTML&#43;UTF-7">test link</a>

replace "then" with "than", sorry.

I figured it will be resolve with the next release, just working and testing on.

You can comment out "$doc = $this->repackUTF7($doc);" this line to solve the problem.

This bug has been fixed in SVN. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.