Bug #68031 [Opn->Nab]: htmlspecialchars returns empty string, sometimes

Edit report at https://bugs.php.net/bug.php?id=68031&edit=1 ID: 68031 Updated by: cmb@php.net Reported by: pfenderd at bellsouth dot net Summary: htmlspecialchars returns empty string, sometimes -Status: Open +Status: Not a bug Type: Bug Package: Filter related Operating System: Linux PHP Version: 5.5.16 -Assigned To: +Assigned To: cmb Block user comment: N Private report: N New Comment: > don't generate an error on log (that's the biggest problem) This can't be fixed, however, see bug #54109 and the tickets linked from there. > Apparently, then, returning an empty string is correct behavior > in the absence of that flag. ACK. Closing. Previous Comments: ------------------------------------------------------------------------ [2015-08-31 13:18:44] antropik at gmail dot com (same problem on htmlentities) ------------------------------------------------------------------------ [2015-08-31 13:15:35] antropik at gmail dot com same problem with html_entity_decode error come with treatment of accent don't generate an error on log (that's the biggest problem) PHP 5.5.9-1ubuntu4.11 ------------------------------------------------------------------------ [2014-10-15 18:51:36] phpbugs at hypertwins dot org In my case, this does seem to be a character set problem: adding ENT_SUBSTITUTE to the "flags" parameter eliminates the blank results. This appears to be consistent with the documentation for that flag, which says it will "Replace invalid code unit sequences with a Unicode Replacement Character U+FFFD (UTF-8) or &#FFFD; (otherwise) instead of returning an empty string." Apparently, then, returning an empty string is correct behavior in the absence of that flag. ------------------------------------------------------------------------ [2014-09-17 19:35:02] pfenderd at bellsouth dot net I have been using PHP for 14 years and I have encountered similar problems wth the PHP script iterpreter that gets solved by rearranging the code statements without actually change the statements themselves. This seems to be one of those cases that will never be resolved. Since I found a coding solution that works for me and I cannot recreate the problem in a simple test case, then I guess that we should not waste any more time on this and close the bug report. ------------------------------------------------------------------------ [2014-09-17 19:17:58] rasmus@php.net If you can't reproduce it, how do you know it wasn't a non-utf8 char in the input? What you describe is exactly what htmlspecialchars() does if it encounters and illegal character in the charset it is in. And from 5.3 to 5.4 the default charset changed from iso-8859-1 to UTF8. Those two things combined with the fact that you said it works fine in 5.3 and broke in 5.4 and 5.5 is a lot of evidence that points to the illegal utf-8 char hypothesis. Your hypothesis that it is somehow in the general processor has 0 data points pointing to it other than a really vague one about you moving your code around a bit. ------------------------------------------------------------------------ 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=68031 -- Edit this bug report at https://bugs.php.net/bug.php?id=68031&edit=1