Edit report at https://bugs.php.net/bug.php?id=61354&edit=1
ID: 61354
Comment by: kstirn at gmail dot com
Reported by: hufeng1987 at gmail dot com
Summary: htmlentities and htmlspecialchars doesn't respect
the default_charset
Status: Not a bug
Type: Bug
Package: Strings related
Operating System: Linux/Windows/
PHP Version: 5.4.0
Block user comment: N
Private report: N
New Comment:
It will soon be a year since the release of PHP 5.4 and there still is no easy
way (read: a global PHP setting) to overcome this huge
backwards-incompatibility.
PHP developers, I understand the security concerns, but please don't be so
stubborn and give us an option to set a default setting without having to
modify *all* legacy code to work with 5.4.
Your action (or lack thereof) is producing the opposite results of desired -
instead of moving to PHP 5.4, thousands of servers (including several we own)
will stay with 5.3.x even after end of life cycle in March 2013.
*Fact*
A simple global setting (an optional php.ini value) would solve the issue for
thousands of users while addressing security issues by explicitly defining the
default charset to be used by affected functions - all without having to
rewrite existing code.
PHP team please do reconsider this and help everyone not using UTF-8 move to
PHP 5.4.
Thank you!
Previous Comments:
------------------------------------------------------------------------
[2013-01-05 17:39:04] x dot bazilio at gmail dot com
Ok. If i did not set defautlt time zone, i get E_WARNING.
Let us set default encoding for htmlspecialchars. It is not posible to persuade
developers of Drupal, joomla, wordpress, bitrix, ets., and developers of
modules
for that CMS to rewrite their code.
I wrote to tech support of bitrix (russian cms). They said that i must use PHP
5.3.x. They not going to rewrite code.
------------------------------------------------------------------------
[2013-01-05 16:05:31] leaflet at leafok dot com
I understand your consideration. Maybe a global configuration in PHP.ini or
page
lifecycle set function could be provided for encoding setting of these
functions.
Developers would be glad to handle this setting centrally by a include header
file
for each pages.
------------------------------------------------------------------------
[2013-01-05 15:17:56] ras...@php.net
I have explained that a few times. We can't default it automatically because
the
encoding may not match the output encoding. Only the developer knows that. If
we
did that automatically it would break even more sites. The sites where the
encodings differ need to set it explicitly.
------------------------------------------------------------------------
[2013-01-05 09:54:44] hufeng1987 at gmail dot com
pass null and empty string that could improve security? no sense..
------------------------------------------------------------------------
[2013-01-05 09:53:01] x dot bazilio at gmail dot com
Please, fix it.
It is so simple to provide default params. Wy should we put NULL and empty
string? Where is security problem to not put NULL and empty string if they are
will be default values of that params?
------------------------------------------------------------------------
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=61354
--
Edit this bug report at https://bugs.php.net/bug.php?id=61354&edit=1
