在POST请求中编码最小字符：是否安全？

我遇到了一种在POST参数的值中只编码以下4个字符的方法：

#

&
+
。如果有的话，会导致什么问题

就我个人而言，我不喜欢这种恶作剧。我之所以问这个问题，是因为我和它的发明者有争论

更新。为了澄清，这个问题是关于在帖子正文中编码参数，而不是关于在服务器端转义帖子参数，例如。G在将它们输入shell、数据库、HTML页面或任何内容之前。
通常（总是？）进行转义元字符以防止注入攻击。不同的系统具有不同的元字符，因此每个系统都需要自己的防止注射的方法。不同的系统有不同的转义字符的方法。有些系统不需要转义字符，因为它们有不同的控制和数据通道（例如，准备好的语句）。此外，将数据引入系统时，通常最好执行过滤

最大的问题是，仅转义这四个字符并不能提供完全的保护。在过滤了您提到的四个字符之后，SQL、HTML和shell注入攻击仍然是可能的。
考虑以下问题：
$SQL='DELETE*from
articles
WHERE
id
='.$\u POST['id'.]

然后您以以下形式输入：
1'或'10

然后变成这样：
$sql='DELETE*自
文章
其中
id
='1'或'10'
来自（如果您使用
应用程序/x-www-form-urlencoded
编码传输数据）：

不安全：

由于多种原因，字符可能不安全。空格字符是不安全的，因为当URL被转录、排版或接受字处理程序处理时，重要空格可能消失，而不重要空格可能被引入。字符“”不安全，因为它们在自由文本中用作URL周围的分隔符；引号（“”）在某些系统中用于分隔URL。字符“#”不安全，应始终进行编码，因为它在万维网和其他系统中用于从可能跟随它的片段/锚标识符分隔URL。字符“%“是不安全的，因为它用于编码其他字符。其他字符是不安全的，因为网关和其他传输代理有时会修改这些字符。这些字符是“{”、“}”、“|”、“\”、“^”、“~”、“[”、“]”和“`”

所有不安全字符必须始终在URL中编码。例如，即使在通常不处理片段或锚标识符的系统中，字符“#”也必须在URL中编码，这样，如果URL被复制到另一个使用它们的系统中，就不必更改URL编码

IMHO URL编码无法针对SQL、HTML或shell注入攻击提供任何保护。如果我错了，请举例说明你的断言。在URL或POST正文中转义元字符只有一个目的，即。E以发出正确的CGI请求。哪个断言？我并不是说某种方法会起作用，只是说你描述的方法不会起作用。据我所知，我们是一致的。如果URL编码原则上不能防止注入，那么你的断言，不正确的URL编码不能防止注入，是不相关的。不同的注入只是一个不同的话题；事实上，我没有提到任何类型的编码或转义。我断言的是转义字符
#
，
、
&
和
+
（通过任何方式）都不足以阻止SQL、HTML或shell注入，这似乎与您所说的相同。再一次，我看不出我们在哪里有分歧。我们没有分歧。你说的是合理的。我只是不明白，你的回答和我的问题有什么关系。你是说你是在客户端（浏览器？）上转义吗？如果是这样，您能使用encodeURIComponent（您可以添加'%20'->'+'）吗？当然，我知道。这就是为什么我们要争论的原因。这是你的PHP代码的问题，而不是URL编码的问题。“它会导致什么问题，如果有的话？”这是一个问题的例子，当没有正确逃脱时，这个人要求争论我想这属于那个类别，不是吗？就是这样！他没有编码%！吃吧！永远不要重新发明自行车（如果你不是专家）：）