因此，我发布了几个与使现有的用 PHP 编写的软件更新以支持 unicode / utf8 相关的问题。解决方案之一是使用 PHP 的 mb_string 函数覆盖 PHP 的默认字符串函数。但是，我看到很多人在谈论负面后果，但没有人真正详细说明它们。谁能解释一下这些负面后果是什么？
为什么用 mb_string 函数覆盖 PHP 的默认字符串函数是“不好的”？毕竟，这比手动将所有这些函数替换为相应的 mb_ 函数要简单得多。那么我错过了什么？这些负面后果是什么？
【问题讨论】：
标签： php unicode utf-8 overriding mbstring
重写它们是不好的，因为如果其他开发人员来处理这段代码，那么它可能会做一些他没有预料到的事情。按照预期使用默认功能总是好的。
【讨论】：
我认为 mb_* 系列函数更重，因为它们也执行 unicode 测试，即使是简单的 ascii 字符串也是如此。因此，在大范围内，它们会减慢您的应用程序速度。 （可能意义不大，但不知何故肯定。）
【讨论】：
我会尽量详细说明。
使用mb_* 重载标准字符串函数将对读取和处理二进制文件或一般的二进制数据产生可怕的后果。如果你重载标准函数，那么突然strlen($binData) 一定会在某些时候返回错误的长度。
为什么？
假设二进制数据包含一个字节，其值在0xC0-0xDF、0xE0-0xEF 或0xF0-0xF7 范围内。这些是 Unicode 起始字节，现在重载的 strlen 会将以下字符计为 1 个字节，而不是它们应该分别为 2、3 和 4 的字节。
主要问题是mbstring.func_overload 是全球性的。它不仅会影响您自己的脚本，还会影响所有脚本以及它们可能使用的任何框架或库。
当被问到，我是否应该启用mbstring.func_overload。答案永远是，而且应该永远是一个响亮的“否”。
如果你使用它，你会被彻底搞砸，而且你会花费无数时间来寻找错误。很可能无法修复的错误。
好吧，你可以调用mb_strlen($string, 'latin1') 让它运行，但它仍然包含开销。 strlen 使用 php 字符串类似于 Java 字符串的事实；他们知道自己的长度。 mb_strlen 解析字符串以计算字节数。
【讨论】：