Edit report at https://bugs.php.net/bug.php?id=61354&edit=1
ID: 61354
Comment by: aheckmann at m-s dot de
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:
We also have the problem with broken php code in 5.4.
It is really a huge amount of work, to switch old projects.
We scanned our source files and found over 25.000 lines with
htmlspecialchars(), not only written by us, also in many 3rd party libraries.
So we also can not switch these projects to php 5.4.
A solution to set the default encoding vi php.ini/ini_set() back to iso8859-1
would be great.
Previous Comments:
------------------------------------------------------------------------
[2012-05-19 16:46:03] wxiaoguang at gmail dot com
I consider this as a bug, too.
My old code using charsets other than utf-8/ISO-8859-1 is totally
broken by php5.4's new htmlspecialchars.
in php5.3: ISO-8859-1 doesn't break any charset.
in php5.4: gbk/gb2312 characters are broken and I get empty
strings after htmlspecialchars.
It's impossible to find all htmlspecialchars and add the 'utf-8'
parameter to them in old projects.
As a result, I can not upgrade to php5.4
------------------------------------------------------------------------
[2012-04-11 15:37:09] moonwalker at hotbox dot ru
Actually, it's a bug. Or at least a lack of customizability.
You're forcing thousands of PHP developers to move to UTF-8 (and urgently patch
their legacy code) and don't give a choice of default encoding in certain cases.
It would much better not to force determine_charset() in ext/standard/html.c to
return hardcoded cs_utf_8 as default encoding (WTF?) but use default_charset
option value for example. At least it WILL BE CONFIGURABLE without a need to
rewrite all existing htmlspecialchars() / htmlspecialchars_decode() /
html_entity_decode() calls.
Holy crap, you're just wasted so much time with that.
------------------------------------------------------------------------
[2012-03-12 19:29:38] tokul at users dot sourceforge dot net
> if you want them working correctly, you should replace following code
> with new:
> old code:
>
> htmlspecialchars($string);
>
> new code:
>
> htmlspecialchars($string, NULL, 'GB2312');
htmlspecialchars($string, ENT_COMPAT, 'GB2312');
Default is to sanitize double quotes.
------------------------------------------------------------------------
[2012-03-12 18:27:13] tokul at users dot sourceforge dot net
Two small comments.
Could you write your Chinese symbols in hex notation. That way they are more
friendly for pages written in other charset?
Your test code is
-----
<?php
$string = "<pre><p>\xce\xd2\xca\xc7\xb2\xe2\xca\xd4</p></pre>";
echo var_dump(htmlspecialchars($string));
echo var_dump(htmlspecialchars($string, NULL, 'GB2312'));
-----
Expected result - both var_dumps should be the same.
> htmlspecialchars should using charset defined by php.ini default_charset.
htmlspecialchars() should not use charset defined in PHP configuration. It
should use iso-8859-1 for backwards compatibility reasons.
------------------------------------------------------------------------
[2012-03-12 06:12:58] hufeng1987 at gmail dot com
When your project using GB2312 as default charset encoding, when you upgrade
to php 5.4, you will find htmlspecialchars will not working as usual.
if you want them working correctly, you should replace following code with new:
old code:
htmlspecialchars($string);
new code:
htmlspecialchars($string, NULL, 'GB2312');
recoding the full project is a huge work.
especially when the project is old.
------------------------------------------------------------------------
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
