Edit report at https://bugs.php.net/bug.php?id=61228&edit=1

 ID:                 61228
 Updated by:         cataphr...@php.net
 Reported by:        keisial at gmail dot com
 Summary:            htmlspecialchars() silently failing
-Status:             Open
+Status:             Wont fix
 Type:               Bug
 Package:            Unknown/Other Function
 PHP Version:        5.4.0RC8
 Block user comment: N
 Private report:     N

 New Comment:

This is intentional. The way PHP "warns" of invalid multibyte sequences is to 
return an empty string. The "hesitant" warning in 5.3 was not a good idea.


Previous Comments:
------------------------------------------------------------------------
[2012-03-01 22:47:38] ni...@php.net

The main problem with that error was that it was very inconsistent:

It only was generated when error display was *disabled*. That basically meant 
that you would never see that error in development, but it would flood your log 
in production.

This was done for security reasons, in order to protect people who had 
display_errors=1 on production servers.

Especially as PHP 5.4 provides ENT_SUBSTITUTE I think that this error doesn't 
make much sense anymore.

But probably I'm wrong :)

------------------------------------------------------------------------
[2012-03-01 20:39:49] keisial at gmail dot com

Description:
------------
htmlspecialchars() no longer provides warnings in PHP 5.4
This is specially worrying as 5.4 changes its default charset
from ISO-8859-1 to UTF-8.
So the same string that passed flawlessly through 5.3, will 
now silently output nothing in 5.4 (and htmlspecialchars
is one of the last things to check!).

In 5.3 the following can produce:
var_dump( htmlspecialchars("a\237a", ENT_COMPAT, 'UTF-8') );

PHP Warning:  htmlspecialchars(): Invalid multibyte sequence in argument in php 
shell code on line 1
string(0) ""

whereas in 5.4:
var_dump( htmlspecialchars("a\237a", ENT_COMPAT, 'UTF-8') );
string(0) ""


The explicit UTF-8 is to make both work the same, 
htmlspecialchars("a\237a") *works* in 5.3 (but it may not be 
in your page encoding).

The reason is clear, php_error_docref() of php_escape_html_entities_ex 
is gone in 5.4 and trunk.

I attach a patch against 5.4 branch readding the warning (should apply fine in 
trunk, moved 5 lines below)




------------------------------------------------------------------------



-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61228&edit=1

Reply via email to