Edit report at https://bugs.php.net/bug.php?id=62341&edit=1
ID: 62341
Updated by: cmb@php.net
Reported by: bfanger at gmail dot com
Summary: htmlspecialchars() should work on ascii compatible
encodings by default.
-Status: Open
+Status: Feedback
Type: Feature/Change Request
-Package: *Unicode Issues
+Package: Strings related
PHP Version: 5.4.4
-Assigned To:
+Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
> 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.
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2012-06-18 14:26:23] rasmus@php.net
EUC-JP is heavily used, supported by htmlspecialchars and it is not ASCII
compatible.
------------------------------------------------------------------------
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