Question

问题是你无法真正告诉用户字段中允许有多少字符，因为转义值显然比未转义字符具有更多字符。

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

每个字段的一个白名单（工作太多，并没有完全解决问题）
每个字段的一个黑名单（与上面相同）
使用可以保存数据的字段长度，即使所有字符都已转义（错误）
取消隐藏数据库字段（更糟糕）
保存数据hex-unescaped并将责任完全转移到输出过滤（不是很好）
让用户猜出（最差）的最大尺寸

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

示例代码：

$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，则转义的数据将不适合。

Answer 1

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

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

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

请记住，磁盘空间相对便宜 - 不要浪费太多努力使数据库紧凑。

Answer 2

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

如果该字段可以容纳32个字符，即32个未转义字符
让用户输入32个字符
escape / unescape不是用户的问题
为什么这是一个问题？
- 如果这是表单数据输入，则无关紧要，
- 如果您出于某种原因逃避数据并将其传回去，那么在存储之前将其转移到

没有进一步的背景，看起来你正在解决一个不存在的问题，或者不需要存在的问题

Answer 3

这是一个有趣的问题。

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

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

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

编辑：鉴于您的例子，我认为您的逃避太多了。在输出中使用较小范围的清理和HTMLSpecialChars()，或者使数据库字段高达其当前大小的200％。如果你问我，那就太臃肿了。

Answer 4

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

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

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

经过十六进制清理后，HTML数据超出了字段长度

4 个答案: