Bug #61354 [Com]: htmlentities and htmlspecialchars doesn't respect the default_charset

From: Date: Tue, 26 Feb 2013 21:29:02 +0000
Subject: Bug #61354 [Com]: htmlentities and htmlspecialchars doesn't respect the default_charset
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-177428@lists.php.net to get a copy of this message 
Edit report at https://bugs.php.net/bug.php?id=61354&edit=1

 ID:                 61354
 Comment by:         rudibr 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:

What about my third-party modules? Should I change their code as well? Do I now 
need to verify and manually alter code on third-party modules everytime I 
upgrade or install them?

If Im using a component with protected code, do I need to go trough their 
support staff and wait for a correction? What if they provide no reliable 
support or customization, am I now being encouraged to hack and crack in the 
source code just so I can fix this?

It is easy , even redundant , and absolutely justfiable to create a new ini 
setting to control this behavior, that I feel a little bit offended by the 
current attitude of php developers over this issue.

I also feel a little bit offended because the guy who is responsible for this 
change EXPLICITLY stated that the change to UTF-8 defaulting have nothing to do 
with security. It just sounded like a "better default", according to the 
developer. Hardly a seriously thought-trough consideration.

This is becoming quite a sad state of affairs. I guess I will have to consider 
moving on from php if it comes to that.


Previous Comments:
------------------------------------------------------------------------
[2013-01-27 17:32:18] kstirn at gmail dot com

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!

------------------------------------------------------------------------
[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] rasmus@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..

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


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

Thread (44 messages)

« previous php.bugs (#177428) next »