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

Edit report at https://bugs.php.net/bug.php?id=62341&edit=1 ID: 62341 User updated by: bfanger at gmail dot com Reported by: bfanger at gmail dot com -Summary: htmlspecialchars() should work on ascii compatible encodings by default. +Summary: htmlspecialchars() should return NULL on (encoding) failure -Status: Feedback +Status: Assigned Type: Feature/Change Request Package: Strings related PHP Version: 5.4.4 Assigned To: cmb Block user comment: N Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2012-07-03 19:39:32] Bonefish26 at aol dot com Everything is fine with htmlspecialcahrs until someone copies data from their auto formatted ms word document and puts it in the update box. Setting the charset option seems to solve the problem. ------------------------------------------------------------------------ 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