Edit report at http://bugs.php.net/bug.php?id=47494&edit=1
ID: 47494
Comment by: trueleader at gmx dot de
Reported by: philipp dot feigl at gmail dot com
Summary: htmlspecialchars does not throw E_WARNING on multibyte
problems
Status: Bogus
Type: Bug
Package: Strings related
Operating System: CentOS5
PHP Version: 5.2.8
New Comment:
Why the developer of the language create a workaround for bad configured
servers and/or applications?
If a configuration variable tells that errors are shown on screen then I
think all errors (dependent on reporting level) are shown - and not that
they can be only logged if the configuration variable is turned off.
I think/hope this is not only my opinion.
We just lost some data, because we fill a JS confirm message on a HTML
click event with a string from a PHP language variable. Nobody knows
that we missed to utf8_encode because all developers use display_errors
on and therefor no error is shown/logged for this problem
Previous Comments:
------------------------------------------------------------------------
[2009-11-20 20:24:21] s...@php.net
The idea is to return an error but not display it (i.e. log it or allow
custom error handlers to process it).
The reason for it is that, unfortunately, people run servers in
production with display_errors=On, and php_escape_html_entities_ex can
be triggered from all kinds of code that usually doesn't produce errors,
which can reveal sensitive information on public sites. So we chose to
go after lesser of two evils and not generate the error in this
context.
For debugging, I would suggest always logging errors and checking the
error log, as some errors may be hard to spot in display anyway
(especially true if your script produces something like JSON).
------------------------------------------------------------------------
[2009-02-25 13:48:11] j...@php.net
It's intentional. If you disagree, please ask s...@php.net why it is
like this (I once reverted that :)
------------------------------------------------------------------------
[2009-02-24 13:57:32] philipp dot feigl at gmail dot com
Description:
------------
When using htmlspecialchars with a invalid multibyte string and using
UTF-8 as encoding, there are two possible outcomes based on the
"display_errors" ini setting:
1. display_errors=1
=> empty string is returned
2. display_errors=0
=> E_WARNING is thrown
This is exactly what the code states. Can be viewed in
http://cvs.php.net/viewvc.cgi/php-src/ext/standard/html.c?view=markup
on line 1147
However this is VERY confusing as a developer point of view. As I have
display_errors always set to "1" for debugging purposes, I never
realized, one of our locale strings was corrupt, as it was just emptied
out.
Now in the production environment, our error handler terminates the
script because of the E_WARNING beeing thrown.
While both of the ways (empty string / error) are acceptable for me -
because ofcourse the input string is invalid, it is very confusing to
have different behaviors of PHP based on the display_errors setting.
Reproduce code:
---------------
echo 'a' . htmlspecialchars(substr(utf8_encode('aü'), 0, 2), ENT_QUOTES,
'UTF-8') . 'b';
Expected result:
----------------
Either 'ab'
Or PHP E_WARNING
However not both based on display_errors
Actual result:
--------------
display_errors=1 => 'ab'
display_errors=0 => E_WARNING
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/bug.php?id=47494&edit=1
