这可能没有任何实际用途，但我想知道是否可以针对 xsd 验证属性。我使用 xsd.exe 从架构中生成了一个 cs 文件，但没有任何验证逻辑被继承，例如......
<xsd:element type="Text_Key" name="LPI_Key"/>
</xsd:simpleType>
<xsd:simpleType name="Text_Key">
<xsd:restriction base="xsd:string">
<xsd:length value="14" fixed="true"/>
<xsd:pattern value="[0-9][0-9][0-9][0-9][LXC][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]"/>
</xsd:restriction>
Generates
private string lPI_KeyField;
也许我错过了一些东西，但我认为这是可能的。我知道我可以验证我是否可以将属性转换为 xml，但这似乎有点倒退，正如我所说，它可能没有任何实际用途，但如果验证逻辑已经存在，为什么不使用它似乎是有道理的. 对属性进行 id 验证的原因是，我可以在用户输入错误的值时通知用户，而不是等到输入所有值并在转换为 xml 并验证之前点击提交。希望这是有道理的，如果我错过了任何明显的教程或任何我想说的我已经用谷歌搜索但我得到的只是'针对 xsd 验证 xml'，有时只是知道关键字会在谷歌搜索中产生所有差异。
对罗米尔的回应：
感谢您的回复。尽管我同意 RegEx 将执行所需的验证，但如果 xsd.exe 会为您生成该验证，那就太好了。但正如在我原来的帖子中看到的那样，没有进行验证，你可以说我只是懒惰，但我认为这是试图减少事故和混乱。在整个应用程序、数据存储等中使用一组验证规则，意味着没有验证错误会禁止用户（在上面的例子中，xml 模式是我无法控制的预定义模式，我确定这是一个许多人也会涉及的情况）。如果我要编写自己的正则表达式验证（并且我用作参考点的架构非常大）以及 xsd 验证规则在哪里更改，然后我将不得不更新我的正则表达式中的所有更改（请记住，原始的正则表达式可能会阻止用户输入有效数据，直到执行更新）。现在，如果我能够直接针对 xsd 进行验证，那么只需将旧的换出并将新的放入（出于这个问题的目的，我们可以假设只有验证逻辑发生了变化；-)）和毕竟属性的值仍然与 xml 字符串中的值相同。