Search…

X3 Photo Gallery Support Forums

Search…
 
Coolhand
Experienced
Topic Author
Posts: 42
Joined: 15 Apr 2018, 05:31

mb_convert_encoding(): Unable to create character encoding converter

10 Feb 2019, 01:14

Good morning,

Today I have received an warning message on:

https://hobby-fotografie.mobi/Portfolio ... _und_Meer/

Warning: mb_convert_encoding(): Unable to create character encoding converter in /www/htdocs/w0108e5e/hobby-fotografie/app/asset-types/asset.inc.php on line 22

Any idea?

Greetings Mike
 
User avatar
mjau-mjau
X3 Wizard
Posts: 13993
Joined: 30 Sep 2006, 03:37

Re: mb_convert_encoding(): Unable to create character encoding converter

10 Feb 2019, 08:56

I came across this bug myself today ... On a local website still running X3.25.1, but with PHP updated to version 7.3.2. I also see you downgraded the PHP on your website from PHP 7.3.2 to 7.2.13, and the error is gone?

This bug is related to PHP 7.3! Possibly only 7.3.2. The updated file /app/asset-types/asset-inc.php will fix the error, but I still need to figure out what is going on. I will do some more research and post back here.
 
Coolhand
Experienced
Topic Author
Posts: 42
Joined: 15 Apr 2018, 05:31

Re: mb_convert_encoding(): Unable to create character encoding converter

11 Feb 2019, 09:28

I can confirm that it is a php problem...
I switched  back to 7.2 and everything is fine again...

Strange...
 
User avatar
mjau-mjau
X3 Wizard
Posts: 13993
Joined: 30 Sep 2006, 03:37

Re: mb_convert_encoding(): Unable to create character encoding converter

14 Feb 2019, 09:42

X3.27.3 was released yesterday and this bug has now been resolved. I recommend first upgrading to X3.27.3, and then you can upgrade to PHP 7.3 again. In addition to the bug fix, we have also fixed other related IPTC issues.
https://www.photo.gallery/blog/photo-gallery-X3-27/

PHP 7.3 "bug"
I am not quite sure if it qualifies as a PHP "bug", but since PHP 7.3, the code used to read image IPTC values as UTF-8 (unicode) suddenly fails:
Code
mb_convert_encoding($string, 'UTF-8', 'pass');
This is now been resolved in X3.27.3 by first attempting to detect UTF-8 encoding, and then only encode as UTF-8 if the string is not already UTF-8: @mb_detect_encoding($string, 'UTF-8', true) ? $string : @utf8_encode($string);

PS! This bug is unrelated to the critical PHP 7.3 bug recently reported.

Writing IPTC as UTF-8
Before X3.27.3, individual characters were first decoded from UTF-8 before writing the data to image IPTC. This was causing inconsistent character encoding when reading IPTC data back into X3. Now, IPTC data is always stored as UTF-8, without decoding or encoding, which is how it should have been in the first place. For backwards compatibility however, and to support IPTC data from 3rd party applications, we still need to detect encoding and encode to UTF-8 if required.

Custom IPTC fields check for validity
Custom X3 IPTC fields hidden, reference_date, link_target and sort_index are now checked for X3 validity, in the obscure chance that they are populated with "junk" from another application. Before including values from these custom IPTC fields, we now check that they contain valid X3 values. For example, in this post the user had an image which was populating X3 hidden field with a large quantity of unknown text ... X3 only stores "1" when an image is hidden, so we can easily know if the stored value is valid.

IPTC.Keywords removed
X3.27.3 no longer attempts to load IPTC keywords field, since keywords are not (yet) used in X3.