我目前在我的一个项目中使用以下行：
htmlspecialchars($value,ENT_QUOTES,'UTF-8');
因此它编码＆amp;，'，“，＆lt;，＆gt ;. 我的问题是（至于我正在考虑的一些内部编码原因），没有编码和安排所涉及的任何安全风险。 ？ 因此，如果使用以下行会产生安全风险/泄漏：
$value=str_replace('&','&',$value);
对于＆lt;，＆gt;，'，“我很清楚为什么它们应该被编码，因为它们可以用于html注入。但是＆amp;我没有看到原因（我也没有到目前为止找到任何特殊原因。）
修改
由于数次访问被提及了几次。我在那里使用带参数的学说，...所以数据库应该（相对）从SQL注入中节省。
上述转换仅用于防止html注入，但目前由于大多数数据落在extJS创建的字段中，...“＆amp;”如果显示文本字段&而不是&，那么转换就会受到影响。
可悲的是，由于架构错误，我只能在一个且只有一个位置执行整个htmlspecialchars和str_replace部分（如果我这样做的话）。在那里我无法区分。因此，我对&的问题也是如此。
答案 0 :(得分：4)
每当您接受用户输入，然后继续将其作为表达式进行评估，将其输出回网页或将其直接注入SQL语句时，就存在安全风险。 htmlspecialchars编码可用于恶意目的的一些（不是全部）字符 - 例如SQL注入攻击中使用的单引号和双引号。 htmlspecialchars不应该用于输入安全性。您应该使用复杂的专用方法来删除，编码或转义可能不安全的字符。 htmlspecialchars没有考虑的各种特殊字符和filter evasion techniques（例如，IE6和US-ASCII）。就个人而言，我更喜欢删除任何特殊字符，如果它们不适合输入（JavaScript删除非字母数字输入：input = input.replace(/\W/g, '');）。
使用JavaScript清理/转义客户端的用户输入始终很重要，避免将用户输入作为表达式进行评估，并使用预准备语句（例如，PDO）进行SQL操作。
如果我们能看到更多您的应用，我们就能更好地判断您是否存在安全问题。
答案 1 :(得分：2)
不编码
&是否涉及任何安全风险？
任何仍在运行基于Netscape 4的浏览器的人都存在安全风险，其中属性中的&{...}是运行JS的后门方法。希望你今天没有任何Netscape用户，但谁知道未来的浏览器如何解析格式错误的HTML ...
存在功能风险，因为转义&对于HTML标记来说绝对是正确的，而不是转义它可能会破坏您的输出。例如。 markup = cut©&paste，输出= cut©&paste。
目前大多数数据落在由extJS创建的字段中，......“＆amp;”转换就像在textfield＆amp;中那样。显示而不是＆amp;。
这是一个不同的错误 - 您应该找到并修复它，而不是试图解决问题。您如何创建字段，并将数据导入到创建它们的代码中？
如果要将值注入JavaScript变量，那么你需要JS转义它们，而不是HTML转义它们;这两种情况需要不同的处理方式。一个潜在的解决方法是隐藏文档HTML内容中的数据（通常在data-属性中）并从JS中读取它。
答案 2 :(得分：1)
htmlspecialchars与安全性无关，但HTML规范表明这些字符是特殊的。为了安全起见，还有其他类型的转义 - 具体来说，重要的一个是在事物插入数据库之前发生的转义，但这不是htmlspecialchars所用的转义。
只要您想输出HTML文本，就可以使用htmlspecialchars，例如
<div id="here" class='here'> or here </div>
原因是如果第一个here包含文字引号，则HTML中会出现语法错误;与第二个here和双引号相同，或第三个here和小于号。我认为，大于符号不是那么危险，而是取代了平衡（如果我错了，有人会纠正我）。更换了＆符号，以便如果有人想要显示"，则不会转义它会显示"。正确htmlspecialchars后，您将获得HTML中的&quot;，这将呈现为所需的"。
正如Blender所说，文字看起来像你想要的那样。与安全无关。
编辑：或者更确切地说，它可以用于HTML安全性（仅发生在我身上）。假设某人用here替换了第一个"><script src="http://malicio.us/code"/><p id=" ...如果它被正确转义，则没有任何反应，它只是属性中的奇怪文本。但如果不是......至少，与SQL安全无关。