2

我尝试使用 ActiveResource 解析更像 HTML 文档的 Web 服务，但一直收到 404 错误。

我是否需要为此任务使用 XML 解析器而不是 ActiveResource？

我的猜测是 ActiveResource 仅在您使用来自另一个 Rails 应用程序的数据并且 XML 数据很容易转换为 Rails 模型时才有用。例如，如果 Web 服务是范围更广的 XML，如 HTML 文档或 RSS 提要，您希望使用像 hpricot 或 nokogiri 这样的解析器。它是否正确？

您如何知道何时使用 XML 解析器以及何时使用 ActiveResource？

4

2 回答 2

7

更新： ActiveResource 也不是 XML 解析器。它是一个 REST 消费者，允许您与远程资源进行交互，类似于 ActiveRecord 模型。它确实使用了底层的 XML 解析器（我假设通过 ActiveSupport 的 XmlMini 我在下面显示）。

ActiveResource 对 XML 内容的结构有一些严格的要求，并且在与另一个 Rails 应用程序的 REST API 交互时效果最好。它不打算对 HTML 页面进行通用屏幕抓取。为此，请直接使用 Nokogiri。

ActiveSupport 不是 XML 解析器，它是有用的 Ruby 方法和类的杂项集合。但是，它确实为许多不同的 XML 解析器提供了一个包装器，为您提供了一致的界面。

您可以查看正在使用的 XML 解析器并切换到不同的 XML 解析器。试试这个script/console。

ActiveSupport::XmlMini.backend # => ActiveSupport::XmlMini_REXML
ActiveSupport::XmlMini.backend = 'Nokogiri'
ActiveSupport::XmlMini.backend # => ActiveSupport::XmlMini_Nokogiri
# it will now use Nokogiri

但是，这仍将使用 Nokogiri 中的 XML 解析器，它假定严格、有效的标记。大多数 HTML 页面不符合这个严格的要求，因此最好直接使用 Nokogiri 的 HTML 解析器，而不是通过 ActiveSupport。

doc = Nokogiri::HTML(...)
于 2009-08-10T15:13:13.730 回答
4

我写 XmlMini 是因为我想回答同样的问题。XmlMini 并没有真正做太多，这让它保持专注。但是，如果您有任何 YAML 或 JSON 无法处理的问题，XmlMini 也不会完成这项工作。

例如，如果您需要验证正在处理的 XML 的结构，那么 XmlMini 就不是工具。手动验证很糟糕。

同样，如果您正在处理从其他地方重用标准元素和属性语义的数据，例如包括 UBL、OpenDoc 或 Atom 的片段，您确实应该获得一些更好的命名空间工具。

ryanb 提到了 Nokogiri，我想不出比这些更美妙的事情了。它拥有 libxml 的所有功能，比 Ruby 中的几乎任何库都更优雅。我不仅仅指 XML 解析，它与 _why 的最佳项目一起出现。

但有些事情甚至 Nokogiri 也不是为之而设计的。如果你真的，绝对，肯定需要以极快的速度杀死房间里的每一个尖括号，你就必须淘汰 SAX。但是，如果您非常需要速度，请不要使用 Ruby。使用纯 C 在 expat 或 libxml 中执行此操作。或者根本不执行此操作。

于 2009-11-16T11:01:56.860 回答