我正在使用 BlueDragon 的 cfform 验证:
<cfinput validateat="onServer" validate="regex" pattern="^[a-zA-Z0-9 ]+$" name="COMPANYDBA" />
但是这种模式并没有产生正确的结果。美元符号出了点问题:
^[a-zA-Z0-9 ]+$
预期结果:没有特殊字符
实际结果:没有特殊字符,除了它允许 $ 符号
为什么这会允许在字符串中使用美元符号?
我正在使用 BlueDragon 的 cfform 验证:
<cfinput validateat="onServer" validate="regex" pattern="^[a-zA-Z0-9 ]+$" name="COMPANYDBA" />
但是这种模式并没有产生正确的结果。美元符号出了点问题:
^[a-zA-Z0-9 ]+$
预期结果:没有特殊字符
实际结果:没有特殊字符,除了它允许 $ 符号
为什么这会允许在字符串中使用美元符号?
尝试分别使用\A
and\Z
而不是^
and $
。
一个老问题,但它被列为未回答,所以这里有一个(过长的)答案来阻止这种情况(无论如何,只要有人支持它)。
在 BD7 和 OpenBD 之间,cfform 的来源不太可能发生显着变化——因为现在几乎没有人推荐使用 cfform——所以这里是生成 HTML 的 OBD 代码:
这段代码告诉我们的是,通过提供的属性,一个以后缀命名的隐藏表单字段与_CFFORMREGEX
要测试的模式一起输出。
(这当然不是真正的服务器端验证,尽管有什么validateat="onserver"
建议,因此是不使用 cfform 的另一个原因)。
提交后,通过 cfFormData.java 文件获取并使用该表单字段:
如果您遵循它,最终会运行com.nary.util.string.regexMatches
使用 Apache ORO 来检查它是否匹配的模式:
使用 SINGLELINE_MASK 意味着将执行它们通常^
的$
内容开始/结束匹配(不是行的开始/结束),并且.
包括换行符。
综上所述,我们可以明确指出,如果提供的模式是不被接受的,^[a-zA-Z0-9 ]+$
那么$
原始问题肯定比所揭示的要多。
当然,与其担心所有这些,最合适的解决方案是: 停止使用 cfform。
进行正确的表单验证有很多更好的选择,请参阅 Charlie Arehart 的列表:cf411.com/form