奇怪的问题。我有一个潜在的解决方案，但我正在寻求改进。所有这些都与MS SQL / C＃项目有关，因此如果需要，请考虑该上下文中的内容。
为用户输入表单以输入银行帐号。但我们合作的不同客户银行有不同（和奇怪）的要求。这个数字的长度为13位，但2,3位数是未知的，需要由用户输入。尾随的10位数字为零填充，并且应向用户显示末尾的2或3个字符。基本上，坚果。客户特定。其他一些客户对验证有各种各样的要求，而我正试图用这个来解决这个问题，因此可以扩展到足以处理随机客户端请求的东西是我正在寻找的。
因此，举个例子，某人可能拥有部分帐号1__0000123456。他们需要输入缺少的两位数。但是我们可以显示456.因此，想要将其显示在显示1__000???456的屏蔽文本框中，只允许他们编辑__s。
当然，所有这些配置信息都存储在数据库中。并非所有人都可能缺少数字。
到目前为止，我提出的最佳解决方案是将部分号码与一些魔法角色存储在一起以指定缺失，可能是_。然后在它旁边存储一个正则表达式，它验证并分组区域。但也标志着地区有一些特殊的废话，如“隐藏”。我认为我可以在组名中编码，这是愚蠢的，但我最好的想法。
因此，在数据库中，我可能会有如下记录：
Number Validation
1__0000123456 ^1\d\d0*(?<h:Account Id>123)456$
因此，我们有一个数字（部分）和一个验证表达式。但是，验证表达式在命名捕获组中有一些神奇的东西。 “：h”表示应该隐藏该范围。所以，我可以隐藏随机范围，或者下一个疯狂的客户想要的东西。
以上内容将显示为包含"1_0000???456"的屏蔽文本框，其中仅允许用户输入第二个和第三个数字。侧面的文字可以描述用户需要输入的内容为“帐户ID”，即命名的捕获组名称的其余部分。
的Eh。这是个主意。不过，这感觉就像滥用我们所有人所珍视的一切。
[编辑]
所以，这并没有真正解决问题，因为我当然不能在它有效之前匹配该值：因此在用户输入有效序列之前无法知道隐藏或显示的范围。如果有可能深入研究正则表达式的AST或其他东西......那就是neato。
答案 0 :(得分：0)
根据我的理解，您要求银行帐户的方式特定于银行。为什么不首先要求银行？然后你可以加载验证方法。
如果您不能要求用户选择银行（可能要求不允许您），我认为您唯一的选择是在用户进入银行帐户时动态检查正确的验证器。