HTML 数据经过十六进制处理后超出字段长度答案

【问题标题】：HTML Data exceeds field length after being hex-sanitizedHTML 数据经过十六进制处理后超出字段长度
【发布时间】：2010-09-15 06:57:31
【问题描述】：

问题是您无法告诉用户字段中允许有多少个字符，因为转义值比未转义值包含更多字符。

我看到了一些解决方案，但没有一个看起来很好：

每个字段一个白名单（工作量太大，并不能完全解决问题）
每个字段一个黑名单（同上）
使用即使所有字符都被转义也可以保存数据的字段长度（不好）
取消限制数据库字段的大小（更糟）
保存十六进制未转义的数据并将责任完全传递给输出过滤（不是很好）
让用户猜测最大尺寸（最差）

还有其他选择吗？这种情况有“最佳实践”吗？

示例代码：

$string = 'javascript:alert("hello!");';
echo strlen($string);
// outputs 27
$escaped_string = filter_var('javascript:alert("hello!");', FILTER_SANITIZE_ENCODED);
echo strlen($escaped_string);
// outputs 41

如果数据库字段的长度是 40，则转义数据将不适合。

【问题讨论】：

在什么编程环境下？ Win32、HTML、...？
对不起，它是 HTML。添加了一些标签以进行澄清。
抱歉，我不太明白您的问题...您是否尝试过取消转义值？它们应该恢复到正常长度。可以发一些代码吗？

标签： php html validation

【解决方案1】：

不要围绕数据库构建应用程序 - 为应用程序构建数据库！

首先设计您希望界面如何为用户工作，计算出可接受的最长字段长度，然后使用它。

一般来说，在存储到数据库之前不要转义 - 将原始数据存储在数据库中并格式化以供显示。如果要输出多次，则存储处理后的版本。

请记住磁盘空间相对便宜 - 不要浪费精力尝试使您的数据库紧凑。

【讨论】：

我只是想非常同意将原始输入存储在数据库中的观点。如果您预先对数据进行 HTML 转义，然后发现转义例程存在问题，那么您就不走运了。

【解决方案2】：

在这里对上下文做出一些疯狂的假设：

如果字段可以容纳 32 个字符，即 32 个非转义字符
让用户输入 32 个字符
escape/unescape 不是用户的问题
为什么会出现这个问题？
- 如果这是表单数据输入，则无关紧要，并且
- 如果您出于某种原因转义数据并将其传回，则在存储前取消转义

如果没有进一步的上下文，您似乎正在解决一个实际上并不存在或不需要存在的问题

【讨论】：

【解决方案3】：

这是一个有趣的问题。

我认为如果您因为消毒而将任何责任分配给他们，那么解决方案将是一个问题。如果他们负责猜测最大长度，那么他们很可能会放弃并选择其他东西（并且不明白为什么他们的输入无效）。

这是我的想法：将数据库字段设置为输入大小的 150%。这个额外的大小用作十六进制清理空间的“填充”，向用户和验证器显示的最大大小是实际所需的大小。因此，如果您在清理之前检查输入长度并且它低于 66% 的长度限制，那么您清理的数据应该就可以了。如果它们超过缓冲区的额外 34% 字段空间，那么输入可能不应该被接受。

唯一的问题是您的数据库表会更大。如果您想避免这种情况，那么您总是可以只转义 SQL 敏感字符并处理输出中的所有其他内容。

编辑：鉴于你的例子，我认为你逃避太多了。要么对输出使用HTMLSpecialChars() 进行较小范围的清理，要么使您的数据库字段达到其当前大小的200%。如果你问我，那就太臃肿了。

【讨论】：

【解决方案4】：

为什么允许用户输入转义字符？
如果您确实需要允许显式转义字符，则在检查转义字符之前插入转义字符

你应该永远不要在任何字符串上做任何重要的工作，如果它仍然以某种方式被编码。先解码，然后做你的工作。

我发现有些人倾向于过早使用转义函数，如 addSlashes()（或 PHP 中的任何内容），或者太晚解码内容（如删除 HTML 实体）。解码首先，做你的事情，然后应用你需要存储/输出/等的任何编码。

【讨论】：