在 C# 中使用 XSLT 或 Linq to XML 进行 HTML 解析有什么优势？这是假设 html 已被清理，因此它是有效的 xhtml。这些值最终将进入 ac# 对象进行验证和处理。
请让我知道这些是否有效以及是否还有其他需要考虑的事项。
XSLT 优点：
XSLT 缺点：
Linq to XML 优点：
Linq to XML 缺点：
编辑：我应该澄清一下，我希望这些能够长期运行，并且网站可能会不时更新它们的布局。这是我认为我会使用不需要编译的东西的更大原因之一。
在不进一步了解您的用例的情况下，很难为您提供一般性建议。
无论如何，您在比较苹果和橙子。LINQ to XML（和一般的 LINQ）是一种查询语言，而 XSLT 是一种用于转换 XML 树结构的编程语言。这些是不同的概念。每当您想从数据源中提取特定的特定信息以执行您需要对其执行的任何操作（例如在 C# 对象中设置字段）时，您都可以使用查询语言。相反，转换对于将数据的一种 XML 表示形式转换为另一种 XML 表示形式很有用。
因此，如果您的目标是从 XML 创建 C# 对象，您可能不想使用 XSLT，而是使用 .NET Framework 提供的任何其他技术来处理 XML 数据：旧的XmlDocument、XmlReader、XPathDocument或. 每个都有其特殊的优点和缺点，具体取决于输入大小、输入复杂性、所需输出等。XmlSerializerXDocument
由于您只处理 HTML，您可能还想查看 CodePlex 上的HTML Agility Pack。
由于您将使用 C#，因此在某些时候您的数据将通过 Linq（或 .NET 的其他一些 XML 代码），您不妨将其全部保留在那里。
除非您有一些令人信服的理由来使用 XSLT，例如您已经拥有丰富的经验或部署强烈支持推出文本文件，否则请将其全部保存在一个位置。
根据我的经验，当您主要处理重新排列和选择现有的 xml 元素时，XSLT 更加简洁易读。XPath 简短易懂，xml 语法避免了在代码中乱扔XElement和XAttribute语句。XSLT 作为一种 xml-tree转换语言工作得很好。
但是，它的字符串处理很差，循环不直观，并且没有有意义的子例程概念 - 你不能转换另一个转换的输出。
所以，如果你想真正地摆弄元素和属性内容，那么它很快就会失败。顺便说一句，使用两者都没有问题 - XSLT 规范化结构（例如，确保所有table元素都有tbody元素）和 linq-to-xml 来解释它。优先条件匹配的可能性意味着 XSLT 在处理许多相似但不同的匹配时更容易使用。Xslt 擅长于文档简化，但它只是缺少太多的基本功能，无法单独使用。
在全心全意地加入 Linq-to-Xml 潮流之后，我会说它与乍一看可能看起来的 XSLT 重叠较少。（而且我非常希望看到针对 .NET 的 XSLT 2.0/XQuery 1.0 实现）。
在性能方面，这两种技术都很快。事实上，由于很难表达缓慢的操作，您不太可能在 XSLT 中意外触发一个缓慢的情况（除非您开始使用递归......）。相比之下，LINQ to Xml 的强大功能也会使其变慢：只需在某个内部循环中使用任何重量级的 .NET 对象，就会出现性能问题。
无论您做什么，都不要试图通过使用 XSLT 来执行除最简单逻辑之外的任何操作来滥用 XSLT：它比等效的 C# 更冗长且可读性更差。如果您需要一堆逻辑（即使是简单的事情，比如date > DateTime.Now ? "will be" : "has"在 XSLT 中变得臃肿的 hack）并且您不想同时使用 XSLT 和 Linq to Xml，请使用 Linq。
HTML 敏捷包 ?
让我尝试。
如果您只是尝试解析 HTML，则不应使用任何一种。HTML != XML 并且不能被同等对待。例如转义序列 ' ' 在 HTML 中完全有效，但不是有效 XML 文档中的有效实体（没有严重的 DTD 等问题）。这会咬你的，相信我！
我还建议使用HTML Agility pack - 出色的库。