Req #62341 [Asn->Opn]: htmlspecialchars() should return NULL on (encoding) failure

Edit report at https://bugs.php.net/bug.php?id=62341&edit=1 ID: 62341 Updated by: cmb@php.net Reported by: bfanger at gmail dot com Summary: htmlspecialchars() should return NULL on (encoding) failure -Status: Assigned +Status: Open Type: Feature/Change Request Package: Strings related PHP Version: 5.4.4 -Assigned To: cmb +Assigned To: Block user comment: N Private report: N New Comment: > I still think it would be useful if we could somehow get access > to the encoding error. At least for now you could use ENT_SUBSTITUTE, and check whether the returned string contains REPLACEMENT CHARACTERs (and their position, if desired). Previous Comments: ------------------------------------------------------------------------ [2016-06-30 16:31:46] bfanger at gmail dot com Updated the summary as requested. From: "htmlspecialchars() should work on ascii compatible encodings by default." To: "htmlspecialchars() should return NULL on (encoding) failure" I still think it would be useful if we could somehow get access to the encoding error. ------------------------------------------------------------------------ [2016-06-29 14:13:06] cmb@php.net > The default charset for htmlspecialchars should be "ASCII > compatible" This is not an option, as has been explained by Rasmus. > I now disagree with the decision of the empty string, with php > flexible typing this should have been false or null. If you still feel that the return value should be changed, please adjust the title of this feature request. ------------------------------------------------------------------------ [2012-09-07 06:38:43] andreas dot rieber at t-online dot de OK, understood. So i will go for a wrapper function where i can set the charset global and report an error in any case (to identify user problems, potential xss trouble or simply wrong database entries). ------------------------------------------------------------------------ [2012-09-06 15:43:59] rasmus@php.net The problem with setting it to 8859-1 is that it lets everything through. If your page is actually in UTF-8 it means you are now vulnerable to 0xE0 XSS invalid UTF-8 style attacks. In PHP 5.4 we have addressed this by adding an ENT_SUBSTITUTE option that lets you substitute any invalid chars instead of returning an empty string. ------------------------------------------------------------------------ [2012-09-06 15:36:43] andreas dot rieber at t-online dot de I also spotted that problem on an older iso-8859-1 application. I could now convert the database to utf-8 or change ca. 150 places in the old code. Then i checked the problem a bit closer: it is user input, so we don't really know what charset it is. We can only assume it is the charset we published the page in. That might be wrong but with the new htmlspecialchars behavior we would show nothing instead of partly wrong input. I made some tests and it looks like best is to change my code (even for applications which use utf-8) to: htmlspecialchars( $text, 0, "iso-8859-1"); There must be a better way... To return nothing is not really good. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=62341 -- Edit this bug report at https://bugs.php.net/bug.php?id=62341&edit=1