Edit report at http://bugs.php.net/bug.php?id=52213&edit=1
ID: 52213 Updated by: [email protected] Reported by: tomas at matfyz dot cz Summary: htmlspecialchars() encodes & and — in a wrong way Status: Bogus Type: Feature/Change Request Package: *General Issues Operating System: Linux niobe 2.6.25-gentoo-r8 #1 PHP Version: 5.2.13 New Comment: Because we want to default to the safest case. It is not always safe to skip encoding a & even if it is part of an entity. For example, inside on* handler attributes and style attributes, you have to double-encode or you will be vulnerable to XSS attacks. Previous Comments: ------------------------------------------------------------------------ [2010-06-30 18:23:35] tomas at matfyz dot cz changing to feature request for the documentation ------------------------------------------------------------------------ [2010-06-30 18:22:12] tomas at matfyz dot cz So why it is not the default? This is problem with many PHP functions: that the expected behaviour is not the default one (it is contra intuitive). Or, if not a default value, at least there should be a red box warning in the documentation! ------------------------------------------------------------------------ [2010-06-30 17:57:50] [email protected] That's what the double-encode parameter is for. Set it to false and it won't double-encode. ------------------------------------------------------------------------ [2010-06-30 17:54:45] tomas at matfyz dot cz Description: ------------ The function htmlspecialchars() encodes the & character even if it is part of some html entity like & or — . The workaround is also difficult because the function doesn't allow to disable replacing of the & symbol (I believe it should). PHP version Test script: --------------- echo htmlspecialchars("&"); echo htmlspecialchars("—"); Expected result: ---------------- & — Actual result: -------------- & — ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/bug.php?id=52213&edit=1
