I'm using a custom PHP VolumeDriver (which you can see here: https://github.com/flack/openpsa/blob/master/lib/org/openpsa/documents/elFinderVolumeOpenpsa.php), and since I upgraded to 2.1.31, I get tons of warnings that all look like this:
Warning: htmlspecialchars(): charset `���~cڏ' not supported, assuming utf-8
This does not happe on a page that contains elFinder (that works fine), but on the next request _after_ I visited a page with elFinder. So I'm thinking it must be something that happens on __destruct or similar. I have been looking a bit over the changelog, but I didn't see anything that might have caused this? If I go back to 2.1.30, everything works fine again
@flack ini_set ('default_charset', 'UTF-8'); is set in the constructor of the elFinder class. Is this something influenced?
@nao-pon I tried commenting out all the ini_set calls, but it doesn't make a difference
The error content says that the parameter given to the third argument of htmlspecialchars() is invalid, or if the value of PHP 5.6 or higher, the value of default_charset in ini of php is illegal.
In htmlspecialchars() in elFinder, only one line is used and the third argument is not specified.
Is there a part corresponding to your project?
The thing is, it's some sort of memory corruption AFAICT. For example, it says charset 'p-honorific-suffix', then I reload, and the error becomes charset '�'. The line that triggers the error in my code looks like this:
$string .= ' ' . $key . '="' . htmlspecialchars($val, ENT_COMPAT) . '"';
So I don't set the third parameter either
@nao-pon
Hi,
I hope you don't mind I'm joining the discussion. We're currently trying to include elFinder in our CMS and encountered the same issue. The error did not appear until we installed elFinder 2.1.31, and after that, nearly every php page shows an charset issue.
Please understand that the issue is not the charset error itself, but a kind of strange file or memory manipulation (I don't know. I'm not a programmer) which probably is caused by elFinder.
@nao-pon I have debugged some more, and it is a bit hard to be sure, because sometimes the corruption stays until you restart apache, but I'm now relatively sure that the problem is caused by
ini_set('internal_encoding', 'UTF-8');
At least, if I comment out this line on the latest release and restart Apache, I can't seem to reproduce any longer
This might be related: https://bugs.php.net/bug.php?id=71876
@flack
What about
// set default_charset
if (version_compare(PHP_VERSION, '5.6', '>=')) {
ini_set('conv.internal_encoding', '');
ini_set('mbstring.internal_encoding', '');
ini_set('default_charset', 'UTF-8');
}
?
ini_set('mbstring.internal_encoding', ''); throws a deprecated error on PHP 7.1, but I don't see the corruption problem with these three
this https://github.com/sebastianbergmann/phpcpd/commit/bce5d0345f10d29801b0f4acc65491896a25c80e should fix the deprecated error
I committed 98cb809341134742a502c93ef52f31c714f7f3df to fix this problem. Please try to current nightly build, then please re-open if you find any problems.
@nao-pon I tested shortly and so far, it looks good. Thanks for fixing!
Can confirm, the bug is gone. Thank you.