奇妙な問題。潜在的な解決策がありますが、改善を求めています。これはすべて MS SQL/C# プロジェクトに関連しているため、必要に応じてそのコンテキストで考えてください。
ユーザーが銀行口座番号を入力するためのフォームを作成します。しかし、私たちが協力している顧客銀行によって、異なる (そして奇妙な) 要件があります。これには 13 桁の数字がありますが、2,3 桁は不明であり、ユーザーが入力する必要があります。末尾の 10 桁はゼロで埋められ、末尾の 2 または 3 文字がユーザーに表示されます。基本的に、ナッツ。クライアント固有。他のいくつかのクライアントには、検証のためのさまざまな要件があり、これでノックアウトしようとしているものがあるため、ランダムなクライアント要求を処理するのに十分な拡張性があるものを探しています。
したがって、例として、誰かがアカウント番号の一部を持っている可能性があります1__0000123456
。不足している 2 桁を入力する必要がある場所。しかし、456 を表示1__000???456
することができます__s
。
もちろん、この構成情報はすべてデータベースに保存されます。すべての人が数字の桁が欠けているわけではありません。
私がこれまでに思いついた最善の解決策は、おそらく_
. 次に、リージョンを検証してグループ化する正規表現を一緒に保存します。しかし、「hidden」のような特別ながらくたで領域をマークします。グループ名にエンコードできると思いますが、これはばかげていますが、私が持っている最高のアイデアです。
したがって、データベースには、次のようなレコードが含まれている可能性があります。
Number Validation
1__0000123456 ^1\d\d0*(?<h:Account Id>123)456$
したがって、数値 (部分) と検証式があります。しかし、その検証式には、名前付きのキャプチャ グループにいくつかの魔法の要素があります。「:h」は、その範囲を非表示にする必要があることを示します。そのため、ランダムな範囲を非表示にしたり、次のクレイジーなクライアントが望むものを非表示にしたりできます。
"1_0000???456"
上記は、ユーザーが 2 番目と 3 番目の数字のみを入力できる、を含むマスクされたテキスト ボックスとして表示されます。横にあるテキストは、ユーザーが「アカウント ID」として入力する必要があるもの、つまり名前付きキャプチャ グループ名の残りの部分を説明することができます。
ええ。それはアイデアです。しかし、それは私たち全員が大切にしているすべてのものの乱用のように感じます.
[編集]
もちろん、値が有効になる前に値を一致させることはできないため、これは実際には問題をうまく解決しません。したがって、ユーザーが有効なシーケンスを入力するまで、非表示または表示する範囲を知ることができません。正規表現の AST などを掘り下げることができれば...それはナイトーです。