Ruby Nokogiri SAX 解析器在“>”处截断字符串 （又名“>”）

Question

背景：我正在使用 Ruby 的Nokogiri gem 来解析 XML 文件。我遇到的问题是，当字符串包含 时，SAX 解析器返回不完整的结果>，这是 的 HTML 编码>。例如：

<element>PART1PART2</element> #=> returns "PART1PART2"
<element>PART3&gt;PART4</element> #=> returns "PART3"

我的解析器看起来像这样：

require 'nokogiri'
class MySample < Nokogiri::XML::SAX::Document
  def characters(string)
    puts string
  end
end
# Create a new parser
parser = Nokogiri::XML::SAX::Parser.new(MySample.new)
# Feed the parser some XML
parser.parse_file(ARGV[0])

研究：如果字符串包含>，则 Nokogiri 认为那是字符串的结尾。字符串中包含>会被视为 XML 格式不良。然而，我的 XML 格式正确，但 Nokogiri 认为这>标志着字符串的结尾。这意味着 Nokogiri在解析字符串之前会解释 HTML（转换>为）。>

问题：为什么 Nokogiri 解释 的 HTML >，以及如何确保它解析完整的字符串？

---

一年更新 (FWIW)

自从我第一次发布这个问题以来已经一年多了，目前我还没有找到对我原来的问题的明确答案。因此，我想我应该为将来看到这篇文章的人提供一些更新。请记住，我严格说的是 SAX 解析，而不是 DOM 解析。

主要观点：

• 最初的问题是关于 Nokogiri v1.6.1 的。最新版本（在撰写本文时）是 v1.6.6，但该问题仍未解决。

• 然而，这个问题有一个解决方法（参见下面的matt评论），但如果不是所有字符串都以相同的方式格式化（例如，一个字符串包含>一次，另一个字符串包含>两次，等等），那么实现起来会很棘手。

• 我简单测试了另一个名为Ox的 Ruby 解析器，发现它没有与 Nokogiri 相同的问题。事实上，它可以正确处理包含>. 此外，它还可以处理包含>. 作为奖励，它的执行速度似乎比 Nokogiri 更快（但它也不是没有缺点）。

底线：

如果您在 Nokogiri 上遇到类似问题，那么我建议您查看 Ox 作为可能的替代方案。我不会争论一颗宝石比另一颗更好（这不是目的）。然而，我可以保证 Ox 处理包含>和/或的字符串的能力>。

Answer 1

您没有说明为什么要尝试使用 SAX 解析器。使用 DOM 解析器解析文档时，Nokogiri 可以正确处理文档：

require 'nokogiri'

doc = Nokogiri::XML(<<EOT)
<root>
  <element>PART1PART2</element>
  <element>PART3&gt;PART4</element>
</root>
EOT

puts doc.to_xml
# >> <?xml version="1.0"?>
# >> <root>
# >>   <element>PART1PART2</element>
# >>   <element>PART3&gt;PART4</element>
# >> </root>

您可能需要在开发人员的邮件列表上进行核实。