为什么 XMLEventReader 报告包含标记的 CHARACTERS 事件？答案

【问题标题】：Why does XMLEventReader report a CHARACTERS event that contains markup?为什么 XMLEventReader 报告包含标记的 CHARACTERS 事件？
【发布时间】：2011-04-10 10:50:27
【问题描述】：

我有一个 XMLEventReader。它是从使用“UTF8”编码的 XMLInputFactory 构建的。我正在使用它来读取“编码”属性设置为“UTF-8”的 XML 文件。

我已验证 XML 文件在 Firefox 下可以正确查看。当您查看页面编码时，它说它是UTF-8。

我已将 XMLEventReader 设置为像这样合并字符事件：

reader.setProperty(XMLEventReader.IS_COALESCING, Boolean.TRUE);

XML 文档没有 DTD。有效。

XMLEventReader 偶尔会报告收到了一个CHARACTERS 事件，其内容是（减去引号），例如：

r problems were most severe and frequent.) Did you sleep a lot more than usual nearly every night during that period?</text>  Ð

请注意样本末尾附近存在标记标签，以及大写的 thorn。另请注意，该句子已被删除；大概在此之前还有另一个 CHARACTERS 事件，包含句子的前导部分。

为什么 XMLEventReader 搞砸了解析？为什么字符显示不正确？为什么 XMLEventReader 不合并 CHARACTERS 事件，如果这是怎么回事？为什么 StAX 如此丑陋和难以预测？

我在 Mac 上使用我的 Java 运行时 (Java 6) 提供给我的 XMLEventReader。

这里是一些示例 XML，当然我只是从我的编辑器中复制的，所以谁知道结果发生了什么字符转换，但无论如何：

<question id="BMHPD17">
  <permittedResponseCount>1</permittedResponseCount>
  <text>It’s hard for me to stay out of trouble. (Would you say this is true or false for you?)</text>
  <namedAnswerSet idref="TrueFalse"></namedAnswerSet>
</question>

注意第 3 行的“智能撇号”。

我通过对 CHARACTERS 事件做出反应，将其内容保存到堆栈上的字符串，然后对名称为“问题”的 END_ELEMENT 事件做出反应来阅读本文。在收到 END_ELEMENT 事件后，我检索我刚才提到的字符串的值，并构造一个 Java 对象，将我刚才提到的字符串作为输入。

当我 System.out.println() 结果时，我（有时）得到我之前提到的虚假垃圾。

当我将 System.out 包装在具有“UTF8”编码集的 PrintWriter 中时，我不会简单地根据平台的编码输出字符，我会得到相同的结果。

【问题讨论】：

你能发布一些示例 xml 和你用来解析它的代码吗？
编辑了我的条目以显示一些示例 XML 以及我如何写出来。
和你用来解析它的代码？

标签： java xml stax

【解决方案1】：

这是否与包含起始偏移量和长度的基础 SAX 事件相同？如果是这样，您可能会发现这些指定了排除标记的字符串区域。

【讨论】：

对不起，我不明白。我说的是 stax，而不是 SAX。据我所知，Stax XMLEvents 与 SAX 没有任何关系。此外，我得到了部分的 - 和乱码 - 标记，所以它并不是一个简单的案例，它是一个不小心在 CHARACTERS 内容周围包含所有标记的简单案例。流中的某些东西正在触发读者认为一个新元素已经开始或结束，或者什么；我怀疑这里发生了与编码有关的事情，但我在链中找不到链接。
我查看了 StAX API，它与 SAX API 不同。在 SAX API 中，characters() 回调有一个char[] 以及一个offset 和length，所以有时你会在char[] 中得到无关字符，但情况似乎并非如此斯塔克斯。我认为您将需要发布更多的 XML。也许它的格式不正确？
文件真的是 UTF8 吗？我的意思是，仅仅因为它声称是，并不意味着它是。仅仅因为 Firefox 说它是，它可能只是使用声明的编码（因为检测编码实际上是不可能的）。如果您使用一些 8 位 ISO 编码，您的撇号将是一个最高位设置字节，当它尝试将该字节和一些后续字节解码为 UTF-8 序列时，它很可能会丢弃流解码器。

【解决方案2】：

这原来是 Mac OSX 的 JVM 上的一个错误。控制台使用的字符编码不默认为 UTF-8，即使默认字符编码的所有其他用法都是 UTF8。

【讨论】：