Edit report at https://bugs.php.net/bug.php?id=47494&edit=1
ID: 47494
Updated by: nikic@php.net
Reported by: philipp dot feigl at gmail dot com
Summary: htmlspecialchars does not throw E_WARNING on
multibyte problems
Status: Not a bug
Type: Feature/Change Request
Package: Strings related
Operating System: CentOS5
PHP Version: 5.2.8
Block user comment: N
Private report: N
New Comment:
@the disappointed user: PHP 5.4 no longer throws said warning (it was just confusing). Instead there
are several new options for dealing with incorrect encoding. Of particular interest is
ENT_SUBSTITUTE, which will replace invalid code unit sequences with the Unicode Replacement
Character (instead of returning a rather unhelpful empty string). This way you can easily spot where
the string is incorrectly encoded. Furthermore this option has the additional advantage of being
more graceful (it just removed individual incorrectly encoded bytes, not the whole string).
Hope this helps you. More info in the docs: http://de2.php.net/htmlspecialchars
Previous Comments:
------------------------------------------------------------------------
[2012-08-30 19:01:22] another_disappointed_php_programmer at exam
This is very sad.
This is a bug, and it's sad that PHP core developers said that it's a feature and it
won't be fixed. I'm disappointed.
------------------------------------------------------------------------
[2012-07-01 15:34:03] rasmus@php.net
This really isn't a bug. I do agree that the approach isn't ideal, but we
shouldn't throw warnings on bad input here because htmlspecialchars() is
explicitly designed to clean up bad input and it is run directly on user data
most of the time. In order for someone to avoid this warning they would need to
first call something like iconv('utf-8','utf-8') to clean up the input data and
that doesn't make much sense since htmlspecialchars() essentially does that
already. But, in order to help debugging there should be some way to see why an
htmlspecialchars() call failed so a last_error() function similar to how it is
handled for json decoding would make sense.
------------------------------------------------------------------------
[2012-07-01 15:12:31] chris at cbsinteractive dot com
Happening our production servers, can replicate, PHP 5.3.10, Centos 5.6
------------------------------------------------------------------------
[2011-09-27 22:43:02] rudd-o at rudd-o dot com
Reported to /r/lolphp here:
http://www.reddit.com/r/lolphp/comments/kso6p/if_error_reporting_is_on_htmlspecia
lchars_will/
Do you guys realize there is an ENTIRE COMMUNITY of people devoted to the
collective practice of FACEPALMING at PHP's fails?
Hahaha.
------------------------------------------------------------------------
[2011-06-01 18:36:28] larry at garfieldtech dot com
This bug should be reopened, not just documented. Haven't we learned our lesson with
magic_quotes and its ilk? Designing PHP to try and save the user when the user does something
stupid always backfires. Always. MySQL has the same problem, and it backfires there, too.
The current logic is simply backward. "When display_errors is on, you get all errors except
from this function. When display_errors is off, you get no errors except from this one
function." There is no logical reason for that.
I'm working on a project that has been stalled for over a week while we try to figure out
what's wrong with the character encoding configuration on our production server, only to
realize that the data is (probably) bad but we didn't know it because of this bug.
This is a bug and should be fixed, not simply documented as dumb.
If a production server is misconfigured, that's not the job of the language to fix. All that
does is, as another commenter noted, punish those who configure their servers properly. If
anything, it is a security hole for people who DO configure their server properly by turning off
display_errors, as then these strings would get echoed in production. How is that helpful to
anyone?
------------------------------------------------------------------------
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=47494
--
Edit this bug report at https://bugs.php.net/bug.php?id=47494&edit=1