0

最小、完整和可验证的示例（框架 3.5）：

<%@ Page Language="C#" Culture="en-US" %>

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<body>
    <form id="form1" runat="server">
        <asp:TextBox ID="txt" runat="server" />
        <asp:CompareValidator runat="server" ControlToValidate="txt" Operator="DataTypeCheck" Type="Double" Text="This is not a double." />
        <asp:Button runat="server" Text="Do Postback" />
    </form>
</body>
</html>

1,234.0在文本框中输入并点击 TAB。

预期结果：没有。
实际结果：This is not a double.

为什么我希望比较成功：因为文档说：“如果无法将值转换为指定的数据类型，则验证失败。” ，但Convert.ToDouble("1,234.0", CultureInfo.GetCultureInfo("en-US")) 成功了。

我的问题：

这是一个错误（我应该向 Microsoft Connect 报告）还是我错过了文档的某些部分，其中说 CompareValidator 使用与 .NET 框架的其余部分不同的转换规则？

4

2 回答 2

0

尝试使用 Type="Currency"，而不是使用 Type="Double"。它应该接受带和不带逗号的值，但它不会接受超过 2 个小数位。

于 2016-04-28T08:50:56.487 回答
0

这是一个错误（我应该向 Microsoft Connect 报告）还是我错过了文档的某些部分，其中说 CompareValidator 使用与 .NET 框架的其余部分不同的转换规则？

两者都不。我认为这是一个经过深思熟虑但未充分记录的功能。

为什么我会这样假设？由于 : 的参考来源，BaseCompareValidator.ConvertType="Integer"验证是通过简单的尝试来执行的Int32.Parse，但是双重验证显式地匹配某些正则表达式，其中包括小数分隔符但不包含千位分隔符。验证小数时也做了类似的事情（但包括千位分隔符，或者更准确地说，是“组分隔符”）。因此，这显然不是疏忽（因为他们明确允许货币值使用千位分隔符）。

为什么他们要做所有额外的工作而不是只检查结果double.TryParse？我只能推测，通过以下原因是有道理的：

  • CompareValidator自 .NET 1 以来就一直存在，但是，如果我没记错的话，TryParse只是后来才添加的。也许他们想避免调用Parse和捕获异常的开销。

  • 对于开发人员而言，很明显1e10和NaN是有效的双精度数，但对大多数最终用户而言并非如此。因此，排除它们是有意义的。

这仍然不能解释为什么他们故意避免使用千位分隔符，但是，从可用的有限信息来看，这是我能得到的最好的......

于 2020-06-02T11:06:44.047 回答