@stefan: The changing of the prefix from CHAR to VARCHAR mitigates some cryllic alphabet issues. Also when the number of characters exceeds 4 or so, the mb_strlen mitigates it.
How will it affect those without mb_strlen (any situations) and whether it can be incorporated wherever strlen is used in both FA 2.3 and 2.4? Any changes here will have to be carried through to everywhere it is used.
Please note that mb_strlen is used in both A 2.3 and 2.4 in the following files:
reporting/includes/class.graphic.inc
reporting/includes/Workbook.php
The usage in the last file above is:
$strlen = function_exists('mb_strlen') ? mb_strlen($str, 'UTF-16LE') : (strlen($str) / 2);
whilst in the former it is:
$width = mb_strlen($string, "UTF-8");
@itronics: Using VARCHAR results in slightly bigger memory usage, and slower processing (though probably both issues are hardly noticed).Using VARCHAR results in slightly bigger memory usage, and slower processing (though probably both issues are hardly noticed).
@itronics: Regarding mb_strlen function, it should be used indeed, but it is available only when mbstring php extension is enabled, so to avoid problems the conditional call should be used as it is done in Workbook.php.
References:
* What Every Programmer Absolutely, Positively Needs to Know About Encodings and Character Sets to Work With Text
* php.ini mbstring overload