PHP版本5.2.27中get_html_translation_表的回退

我最近将项目的默认编码改为UTF-8，以保证国际化。现在我正在解决一些小问题，但是我遇到了一个让我有点痛苦的问题

原始编码是ISO-8859-1，原始开发人员在不同的位置使用了

get\u html\u translation\u table（）

函数

在PHP版本5.2.17（应用程序正在其上运行）中，只有两个参数传递给此函数：$table和$quote\u style。问题是，该函数假定ISO-8859-1为默认值，并忽略诸如

ini\u set（'default\u charset'，'UTF-8）

在never PHP版本中，函数中添加了一些参数，其中一个参数是

$encoding

。此外，UTF-8取代了ISO-8859-1作为函数内部的默认值

我想在项目中替换尽可能少的代码，以便从ISO-8859-1迁移到UTF-8，但由于错误的结果，我必须修复此问题

---

如何才能在我的项目中以相同的行为获得新的“正确”功能的

get\u html\u translation\u table（）

作为后备版本。

当我在代码库中跌跌撞撞时，我越来越多地发现了get\u html\u translation\u table（）的用法。我现在明白了这一切的初衷。我想我完全是在浪费时间去寻找一个解决方案，这个解决方案可以很好地“开箱即用”utf-8字符

---

我只需要跳过原始代码，只使用普通的htmlentities（）即可-\u-

您总是可以在本地开发框中获得翻译列表（数量不多），并在自定义函数中对其进行硬编码。然而，这是否解决了你的需求取决于你的需求

htmlentities（）

显然不会使用您的列表，但函数本身对UTF-8也没有什么用处。您需要这些HTML实体做什么？您可能已经意识到了这一点，但PHP5.2已经过时了。它在三年前被宣布生命终结，从那时起没有新的安全补丁。它存在已知的安全问题，不会对其进行修复。如果您仍然在生产服务器上运行PHP5.2，那么您的系统管理员（或负责人）就是疏忽大意了。你急需升级；请注意，5.3现在也处于生命周期的末尾。你离开的时间越长，当你最终开始使用它时，升级就越困难。认真地说：尽快升级。我知道5.2已经过时了，我知道我应该尽快升级，但恐怕这不取决于我。由于没有上下文、函数名、注释或示例数据，我发现几乎不可能知道该函数应该做什么。这看起来像是对

htmlentities（）

的复杂重写，在生成UTF-8编码的HTML时基本上是无用的，但很难说。谢谢你，迟做总比不做强：）

/* calls get_html_translation_table with 'ISO-8859-1' as encoding
 * since the third argument is only supported after PHP 5.3.4
 */
function my_get_html_translation_table($str) {
    if (version_compare(PHP_VERSION, '5.3.4') >= 0) {
        return get_html_translation_table(HTML_ENTITIES, ENT_COMPAT, 'ISO-8859-1');
    } else {
        return get_html_translation_table(HTML_ENTITIES, ENT_COMPAT);
    }
}