为什么应该使用strtolower()而不是mb_strtolower()？

Question

我理解strtolower()和mb_strtolower()函数之间的用法/行为差异。并且这个问题在之前就已经被问过了 （参考链接）

但是我不明白-strtolower当前的目的是什么？

它是否可用是因为向后兼容性？还是有一些使用情况下，strtolower是更可取的？似乎mb_strtolower()更安全、更灵活，所以我很想在任何地方都使用它...

- Džuris

---

向后兼容确实很重要。应该优先选择使用 mb_strtolower，因为它可以处理像“ç”或“Ä”这样的字符。 - rak007

有时候 PHP 没有编译 Mbstring 函数。 - cmorrissey

可能值得一提的是，strtolower 更快，对于大多数人来说不会成为决定因素，但对于某些人可能会有所帮助。 - Mark Twigg

Answer 1

不是真正的向后兼容性，而是能够在没有额外加载多字节字符串扩展的情况下使用代码的能力。因此，这是代码可移植性的问题。

strtolower()始终可用。mb_strtolower()仅在加载了额外的mbstring模块时才可用。函数重载功能允许使用“通用”调用strtolower()，如果配置了，则实际上会执行mb_strtolower()。因此，根本没有必要显式编写mb_strtolower()...

这使得代码更具可移植性，因为它可以在有或者没有mbstring扩展的系统上运行。

- arkascha

Answer 2

strtolower()是一种本地函数，与只有在安装了mbstring模块时才可用的mb_strtolower()相比，前者始终存在。

但是关于为什么应该使用其中之一，这很简单。您可以同时使用它们，并且只有在需要使用mb_strtolower()并且可用时才使用它。

---

如果您编写脚本，则不应在脚本、文件名、数据库结构等中使用任何特殊字符，因为它应该是独立于语言的，以提高可移植性，并通过这样做消除操作系统之间的不一致性。例如，在其他环境中，脚本可能会表现出不同的行为，例如Linux对fs/db操作区分大小写，而Windows则不是。

脚本不应该必须处理自己的特殊字符，因为这是不必要的，它会：

• 降低性能，strtolower()比mb_strtolower()快得多
• 如果服务器上没有mbstring，则失去可移植性。

例如，如果您使用其他系统，如PSR-4自动加载器。

$var = new \ns\ÇavA();

尝试加载“Çava.php”而不是“çava.php”，因为它使用本地的strtolower()函数创建了不一致性，导致无法降低大小写。相反，只需保持ASCII。

---

mb_strtolower()应仅用于用户输入/输出，而strtolower()应用于系统定向大小写格式。

话虽如此，strtolower()对于大多数人的需求足够了，即使是用户输入/输出，但问题是在何处以及如何应用该数据。请记住，如果仅供用户输出，始终可以使用CSS的text-transform方法。

- Xorifelse

---

Linux区分大小写，而Windows不区分大小写——好吧，我希望你指的只是文件系统名称，因为总体来说这并不正确。那么，“特殊字符”究竟是什么？如果您建议不使用它们，它们是什么？它们有什么“特殊”的地方吗？最后一句话，嗯，我们称其为“值得怀疑”，好吗？ - arkascha

@arkascha，你对此提出疑问是正确的，我已经进行了调整以使其更加具体。 - Xorifelse

“升级字符”？那其他的1640万个非ASCII字符呢？不过好吧，我们就放下这个问题吧;-) - arkascha

Answer 3

简短回答

• 不能确定mbstring扩展在您的环境中是否可用
• strtolower()执行速度明显更快。

稍微详细点

mbstring扩展是一种非默认的PHP扩展。这意味着它不是默认启用的，尽管根据我的经验，我从来没有遇到过没有启用它的托管提供商。

你的问题让我想知道它们在性能上是否有区别，所以我写了一个快速基准测试函数，你可以在这里找到。

从我对一些随机字符串运行的少量测试中，strtolower()似乎至少快50倍。

如果您知道您正在处理与strtolower()兼容的字符串，并且您有大量这样的字符串，那么检查strtolower()可能会更值得。

- anpel