htmlspecialchars() - 如何以及何时使用和避免多次使用答案

【问题标题】：htmlspecialchars() - How and when to use and avoid multiple usehtmlspecialchars() - 如何以及何时使用和避免多次使用
【发布时间】：2011-02-26 18:59:20
【问题描述】：

我正在为我的老板建立一个 PHP 内部网。一个简单的客户、订单、报价系统。它将被拒绝从 Internet 访问，并且只能由 3 人使用。我对安全性的关注不如对验证的关注。 Javascript 在所有机器上都被禁用。

我的问题是这样的：

员工将有效数据输入到包含以下任何:;[]"' 等的表单中。
Form $_POSTS 将此数据发送到validationAndProcessing.php 页面，并确定员工是否在字段中输入数据。如果他们不这样做，他们会被重定向回数据输入页面，他们错过的字段会以红色突出显示。
htmlspecialchars() 应用于从之前输入的内容重新填充到表单的所有数据。
然后表格重新提交到validationAndProcessing.php页面，如果成功的数据输入数据库并带员工显示数据页面。

我的问题是这样的：

如果员工在第 1 步中反复输入任何数据，则每次将 htmlspecialchars() 应用于数据时，他们都会在第 1 步和第 4 步之间不断移动。

So that:- &
becomes:- &amp;
becomes:- &amp;amp;
becomes:- &amp;amp;amp;

等等。

如何阻止 htmlspecialchars() 多次应用于已清理的数据？

谢谢，亚当

【问题讨论】：

标签： php mysql html validation forms

【解决方案1】：

查看manual page on htmlspecialchars：

string htmlspecialchars (string $string [, int $quote_style = ENT_COMPAT [, string $charset [, bool $double_encode = true ]]])

$double_encode 选项应该是您正在寻找的。p>

但是，在正确设置的数据流中，这不应该根本不可能，除非有来自用户或第三方服务的数据可能已经或不可能包含 HTML 编码的字符。（并不是说我在我的职业生涯中没有建立过一些设置不当的数据流。但这就是为什么我知道为什么它们是干净且定义明确的如此重要。:-)

【讨论】：

$double_encode 是一个黑客；它会阻止任何人使用文字字符串&amp; 或类似的意思来表达这个意思。更好地修复数据流。只在最后的 HTML 模板阶段使用htmlspecialchars()，不要过度输入或数据库内容，你应该没问题。问题中的第 3 步似乎非常可疑。
@bobince 第 3 步，这是符合标准的唯一可能方式 :)
当然你需要htmlspecialchars将文本输出到HTML。然而，第 3 步听起来像是被一揽子应用于 HTML 输出步骤之外的所有内容，这肯定可以解释双重转义。
@bobince 他没有将文本输出到 HTML 中。他填写表单的输入值。至少他应该:)
@naescent 我不确定我是否关注你：htmlspecialchars() ed 文本不会被解释为普通字符（即&amp; 将被转换为可见的&）插入表单信息时的浏览器？我看不出您描述的流程将如何以双重编码的字符数据结束。

【解决方案2】：

您应该只在 HTML 输出中使用 htmlspecialchars，不要在其他任何地方使用。

<input name="var" value="<?php echo htmlspecialchars($var)?>">

如果$var 包含一个＆符号，那么在 HTML 中它将输出编码值：

<input name="var" value="this&amp;that">

但是，用户只会在他们的输入字段中看到this&that，并且在提交时，$_GET['var'] 将是this&that，而不是编码版本。

在 PHP 方面，您可能想做的唯一一件事就是在魔术引号打开时删除斜杠：

if (get_magic_quotes_gpc())
    $var = stripslashes($_POST['var']);
else
    $var = $_POST['var'];

您应该从那里将原始数据存储在数据库中，而不是 HTML 编码的版本。为避免 SQL 注入，如果您使用的是普通的 mysql 函数，请使用mysql_real_escape_string，或者改用PDO。

【讨论】：

在存储用户 cmets 之类的东西之前使用 htmlspecialchars 有什么负面影响？意味着你永远不会忘记输出？
@Silver89 最好将真实的规范数据存储在数据库中。它有助于将数据用于其他事情，例如也许您想稍后处理数据。另外，您的想法并不能真正解决任何问题，因为现在您可能会忘记对输入进行编码，然后在数据库中进行各种编码。
@DisgruntledGoat 这只有在您使用 UTF-8 存储数据时才有可能。如果您坚持使用 ISO-8859-1，那么您需要在 htmlentities 或 htmlspecialchars 上使用 double_encode 参数，这样它就不会转换像 ě 这样的字符。到 ě
@Paul 这就是答案的重点：您应该全面使用 UTF-8，这样就不会发生这种情况。没有它，你永远不应该被“卡住”。如果您的数据库不是 UTF-8，只要您的页面具有与 DB 相同的编码，也有可能。

【解决方案3】：

So that:- &
becomes:- &amp;
becomes:- &amp;amp;
becomes:- &amp;amp;amp;

你完全错了。试试看吧

<form>
<input name="a" value="<?=htmlspecialchars($_GET["a"])?>">
<input type=submit>
</form>

【讨论】：