几年前，我建立了一个很好的自定义 PHP CMS 网站，但我忽略了一个重要问题:unicode 支持。这主要是因为当时的用户都是说英语的，并且在可预见的 future 仍然如此。另一个因素是 PHP 对 unicode 的支持本来就很差。
好吧，现在清算的日子已经到来了。我希望支持 unicode，特别是 UTF8，但我有一个主要障碍:PHP 的字符串函数。如果我错了，请纠正我，但即使现在，在 PHP 5.5 的世界中，PHP 的常规字符串函数(即 strlen、substr、str_replace、strpos 等)也不完全支持 unicode。另一方面，PHP 的 mb_string 函数确实支持 unicode，但我读到它们可能相当耗费资源(这是有道理的，因为我们将处理多字节字符而不是单字节字符)。
所以，在我看来，有以下三种解决方案:
1) 在所有情况下都使用多字节字符串函数。
A.尝试用多字节对应函数覆盖标准字符串函数。说到这里，如果我这样做的话，最好的方法是什么？
B.煞费苦心地检查我的所有代码，并将标准字符串函数替换为对应的多字节函数。
2)煞费苦心地检查我的所有代码，并将可与用户输入、数据库数据等一起使用的标准字符串函数替换为其对应的多字节函数。这需要我仔细查看代码中每个字符串函数的每次用法，以确定它是否有处理多字节字符的哪怕一丁点的机会。
这样做的好处是我可以获得最佳的运行时间，同时完全支持 unicode。这里的缺点是，实现起来非常耗时(而且非常无聊，我可能会补充说)，并且我总是有可能错过使用多字节字符串函数的机会。
3) 彻底检修我的软件并从头开始。但这是我试图避免的事情。
如果还有其他可用选项，请告诉我。
最佳答案
我会选择 1.B 的变体:
1.B.2) 使用自动“搜索和替换”功能(一个精心设计的 sed 命令就可以做到这一点)。
1 赞成 2 的原因: premature optimization is the root of all evil 。我不知道你在哪里读到 mb_ 函数是“资源密集型”的，但说白了，这完全是无稽之谈。当然，它们会花费更多的 CPU 周期，但您实际上不必担心这个问题。出于某种原因，PHP 开发人员喜欢讨论此类微观优化，例如“单引号比双引号更快”，而他们应该关注真正产生影响的事情(主要是 I/O 和数据库)。确实，这不值得付出任何努力。
自动化的原因:这是可能的，它更高效，您需要更多参数吗？
关于php - 更新 PHP CMS 网站以完全支持 unicode/utf8，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/15564002/