【问题标题】:Include my own mb_string functions or use PHP's defaults?包括我自己的 mb_string 函数还是使用 PHP 的默认值?
【发布时间】:2011-11-26 06:48:35
【问题描述】:

对于公共应用程序 - 您认为假设 mb_string 扩展在所有服务器(或几乎所有服务器,如 95%)上启用是个好主意吗?

是否有主机禁用此扩展程序?

【问题讨论】:

  • 它通常可用,但并非总是如此。您应该与您的软件一起记录它有哪些要求和/或在安装之前显示它们。自己动手听起来有点像重新发明轮子。
  • @hakre:很好的答案。为什么会在这里? :-)

标签: php unicode mbstring


【解决方案1】:

我认为大多数默认情况下都启用了它,但我知道有一些托管服务提供商没有启用它,然后他们也拒绝启用它(从来没有从他们那里得到充分的理由)。

如果您希望所有用户都能够在他们的服务器上安装应用程序而无需进行任何更改,那么您可能希望推出自己的一组功能。

但是,将mb_string 设置为您的应用程序的先决条件(并可能在安装脚本中测试它是否存在)可能是一个更好的解决方案,那么您就可以节省自己的额外工作,同时仍然提供令人满意的用户体验。

如果您将 Drupal 作为公共应用程序的示例,它们实际上会滚动自己的函数(例如 drupal_substr()drupal_strlen()),它们会在其中测试 mb_string 扩展的存在并做出决定如何在此基础上运行函数。

【讨论】:

  • 我不明白为什么在这个时代,在 PHP 安装中默认没有启用 mb_string。 拒绝启用它是托管服务提供商的不负责任(恕我直言)。
  • @Herbert 我完全同意,就我而言,mb_string 是必不可少的......为什么你不想使用更快的字符串函数??
  • 为了检查扩展是否启用,你认为使用defined('MB_OVERLOAD_STRING')而不是function_exists()更好吗?我认为检查是否定义了常量会更快
  • 根据docs page, function_exists() '检查已定义函数的列表',所以我假设它们已经加载到内存中的某个地方。可用常量的列表也将在内存中的某个地方,所以我不确定会有那么大的差异。不过我并不积极,我也倾向于defined
  • @Alex:速度差异(如果有的话)会非常微小,这并不重要。这种微优化不会给您带来任何明显的收益。所以,这真的是风格问题。 (即你更喜欢哪个?!)
猜你喜欢
  • 2013-03-13
  • 1970-01-01
  • 1970-01-01
  • 2012-09-24
  • 1970-01-01
  • 2019-08-04
  • 2015-06-19
  • 1970-01-01
  • 2015-09-25
相关资源
最近更新 更多