Edit report at https://bugs.php.net/bug.php?id=61354&edit=1
ID: 61354
Comment by: leaflet at leafok 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:
I am facing the same problem.
After upgrading to PHP 5.4.10 in the product environment, all the GB2312
encoding data on the page became blank. This badly influenced the whole site.
It is undoubtedly a backward compatible issue. Wish it could be resolved soon.
Previous Comments:
[2012-12-28 17:36:29] rudibr at gmail dot com
This is a serious backward incompatibility (and not even listed as such).
I am also not able to upgrade to 5.4 because of this, and have advised all of
my
clients which I provide server consulting to do not upgrade as well.
No defaults of any kind should be changed arbitrarily , without notice and
without
possibility of customization. It breaks code, and makes everyone affected very
uneasy on any future relases.
Like all here I hope this get the serious attention it should have gotten
already.
[2012-11-28 09:28:16] x dot bazilio at gmail dot com
This is a bug.
Just upgraded php and got empty string on many projects.
I cant't change code in CMS, because i am not a developer of CMS. I am using
CMS
fore develop web sites.
[2012-08-27 17:04:46] goodwaiter at gmail dot com
because use htmlspecialchars($text,NULL,""); can make works fine;
so php Developer can fix this bug in this easy way:
just make "omitted encoding" works like encoding with "", and all things will
be
ok.
[2012-08-27 16:37:32] goodwaiter at gmail dot com
another fix way in code is that:
use htmlspecialchars($text,NULL,"")
not need to add "utf8" "cp936", or other in "", just leave "" blank, it will
use
the current page's encoding like no this bug.
[2012-08-27 16:24:39] goodwaiter at gmail dot com
the post above is wrong,change from "Non Thread Safe" to "Thread Safe" cant fix
it.
right fix way:
so guys above can change to windows + iis + isapi module + php, or windows +
Apache + fastcgi/isapi module + php, can fix this bug.
I just test, only windows + iis + fastcgi + php will show the bug.
in isapi module or windows + Apache + fastcgi + php works fine.
and I test that,the bug maybe because of iis fastcgi.
in this case, Zend Multibyte Support allways be "provided by mbstring", even if
I change zend.multibyte to off or on, it still "provided by mbstring".
in phpinfo() show below:
mbstring
Multibyte Support enabled
Multibyte string engine libmbfl
HTTP input encoding translation disabled
libmbfl version 1.3.2
mbstring extension makes use of "streamable kanji code filter and converter",
which is distributed under the GNU Lesser General Public License version 2.1.
Multibyte (japanese) regex support enabled
Multibyte regex (oniguruma) version 4.7.1
and I use this code to test on windows + iis6 + fastcgi + php:
echo(mb_internal_encoding());// show ISO-8859-1, right
$text = "ææ¯æµè¯";//use cp936 chinese chars
$ary[] = "ASCII";
$ary[] = "JIS";
$ary[] = "CP936";
$ary[] = "UTF-8";
echo mb_detect_encoding($text, $ary);//show cp936, right
mb_detect_order($ary);//set detect order
echo(htmlspecialchars($text));//show enmty, wrong !!!
echo mb_detect_encoding(htmlspecialchars($text), $ary);//show ASCII(not the guy
think is utf8), wrong
echo(mb_internal_encoding());// show ISO-8859-1, not change, right
this test can show us that, all things goes right except htmlspecialchars(),
where is the "ASCII" from? maybe iis6 + fastcgi cause this bug. but it's really
a php bug.
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
