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: Instead of moving on to PHP 5.4 and PHP 5.5 thousands of servers will stay with legacy PHP 5.3 due to this single, easy to solve (ini setting) issue that the PHP team has decided to ignore. Previous Comments: ------------------------------------------------------------------------ [2013-07-12 10:57:40] tototation at gmail dot com Yes, i'm interested too to understand that fact. I recently upgrade my server, and ALL my code is unusable ! A search in code found +470 000 words htmlentities or htmlspecialchars !!!!! HOW TO CHANGE ALL THIS ????? THAT'S IMPOSSIBLE !!!!!!!! Thanks, we must stop all our services and websites. Just for a stupid thing. ------------------------------------------------------------------------ [2013-06-15 22:51:31] jbolder42 at yahoo dot com I was wondering if someone could enlighten me by explaining why this: htmlspecialchars($str, ENT_QUOTES, "ISO-8859-1"); ... would be considered any more secure than something like this: ini_set("html.default_charset", "ISO-8859-1"); htmlspecialchars($str, ENT_QUOTES); Thank you! ------------------------------------------------------------------------ [2013-05-20 18:14:25] kstirn at gmail dot com @minder at ufive dot unibe dot ch Yes, this can be done, but still means we would have to manually modify hundreds of legacy scripts on the server (many third party and many obfuscated/encoded) to be able to upgrade to PHP 5.4. It would be really easy to fix with an ini setting and it would indeed make sense to have a setting for such a huge default change. I am disappointed that the PHP dev team has decided to completely ignore the issue. ------------------------------------------------------------------------ [2013-05-19 13:10:13] minder at ufive dot unibe dot ch For legacy projects in latin1 we substitute htmlspecialchars with the self-made function htmlXspecialchars according to these instructions: http://ufive.unibe.ch/?c=php54entitiesfix&q=&l=e ------------------------------------------------------------------------ [2013-02-26 21:29:02] rudibr at gmail dot com 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. ------------------------------------------------------------------------ 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