Re: Multibyte strings
| From: | Mel Dafert | Date: | Fri, 11 Feb 2022 20:22:31 +0000 |
| Subject: | Re: Multibyte strings | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-117019@lists.php.net to get a copy of this message | ||
On 11 February 2022 07:26:45 CET, "Michał" <aaatoja@o2.pl> wrote:
>Hi everyone.
>It's a known fact that nowadays most websites use at least UTF-8
>encoding. Unfortunately PHP itself has stopped a bit in the previous
>century. Is there any reason why the mbstring extension cannot be
>introduced to core in the next major version (maybe preceded with a
>deprecation message like it was with the mysql extension in v5)? All
>functions from the standard library would become aliases for multibyte
>equivalents.
As others have said, any change to behaviour in something as subtle as
string encoding makes little sense (see PHP 6 or the mess that was the migration
from Python 2 to 3, which did exactly that).
However, I do see an argument to be made to make the mbstring extension
always available, similar to what was done with the json extension [1].
Currently, one cannot assume to have access to things like mb_strcut, which
makes writing code that does not break when it's fed UTF-8 relatively complicated.
Frameworks like Drupal also require mbstring for anything other than English
content [2].
The manual [3] also says that it does not require any external libraries, so there
does not seem to be any technical obstacle either.
Would that be an option? Or am I missing some obvious reason that mbstring
should not be always available, like licensing issues?
Regards,
Mel
[1] https://wiki.php.net/rfc/always_enable_json
[2] https://www.drupal.org/docs/system-requirements/php-requirements#s-mbstring-
[3] https://www.php.net/manual/en/mbstring.requirements.php