Java XMLEventReader 怎样逐事件读取XML

用 XMLEventReader 逐事件读取 XML，核心是循环调用 hasNext() 与 nextEvent()，再按开始元素、字符内容和结束元素分支处理。它是应用主动拉取事件的接口，不需要先把整个文档建成 DOM，也不能假定一行对应一个标签、一个文本值对应一个事件。

官方API地址：https://docs.oracle.com/en/java/javase/25/docs/api/java.xml/javax/xml/stream/XMLEventReader.html

本文以 Java SE 25 文档说明接口，给出一个原创的元素直接文本读取类；示例未作为本机运行结果展示。

逐事件读取，为什么不能按行找标签

假设导入程序要读取一份包含多个项目的 XML：格式化时一个元素可能跨多行，压缩后多个元素又可能处于同一行。按换行符切割并不能得到 XML 的逻辑结构。事件读取把这个问题交给解析器，业务关注结构而不是排版。

初始事件通常是 StartDocument，文档中还可能出现注释等其他事件。因此循环不能无条件对每个事件调用 asStartElement()。先判断 isStartElement()、isCharacters() 或 isEndElement()，再使用相应的访问方法。

开始元素的 getName() 返回 QName。业务匹配元素时，应考虑命名空间 URI 与本地名，不能只比较可能被重新命名的前缀。属性通过开始元素的属性访问接口读取，不应等着通用循环为每个属性单独返回一个普通内容事件。

一个元素的文本为什么会分成多段

字符事件包含文本、CDATA以及空白，不能假定下一次 nextEvent() 就给出当前元素的全部字符串。若业务需要完整文本，要连续累加属于它的各个 Characters 片段，到对应的结束边界再交付。每次遇到文本就覆盖旧值，会丢掉前面的内容。

还要先决定“完整”指什么。例如示意结构 先看后，label 的直接文本是“先后”，em 的文本是“看”。若要得到包含后代文本的“先看后”，就需要另一个聚合规则。下面示例选择前者，避免悄悄把不同元素内容混在一起。

每个未结束的元素保留一个 Frame，内含 QName 与 StringBuilder；字符片段只追加给栈顶 Frame。子元素结束后弹出它的上下文，父元素仍保留自己的直接文本。不要只用一个全局 currentName 和一个全局缓冲应付嵌套结构。

怎样写出资源可关闭的读取示例

下面的类读取文件并在每个元素结束时调用 sink。它不保存所有结果，也不自动去掉空白。回调收到的是 QName 和该元素的直接文本；元素结束时交付意味着子元素会先于包含它的父元素交付。

import java.io.InputStream;
import java.nio.file.Files;
import java.nio.file.Path;
import java.util.ArrayDeque;
import java.util.Deque;
import java.util.function.BiConsumer;
import javax.xml.namespace.QName;
import javax.xml.stream.*;
import javax.xml.stream.events.XMLEvent;

public final class EventXml {
    private record Frame(QName name, StringBuilder text) {}

    // 接口本身不是AutoCloseable，用轻量包装器统一资源关闭。
    private record Events(XMLEventReader reader) implements AutoCloseable {
        @Override
        public void close() throws XMLStreamException {
            reader.close();
        }
    }

    public static void read(Path path, BiConsumer sink)
            throws Exception {
        XMLInputFactory factory = XMLInputFactory.newFactory();
        // 本例不需要DTD或外部实体，不为它们建立资源依赖。
        factory.setProperty(XMLInputFactory.SUPPORT_DTD, false);
        factory.setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, false);
        factory.setXMLResolver((publicId, systemId, base, namespace) -> {
            throw new XMLStreamException("不允许解析外部资源");
        });

        // 两项预算仅为示例业务策略，长度按UTF-16代码单元计算。
        final int maxDepth = 64;
        final int maxText = 100_000;
        Deque stack = new ArrayDeque();
        try (InputStream input = Files.newInputStream(path);
             Events events = new Events(factory.createXMLEventReader(input))) {
            XMLEventReader reader = events.reader();
            while (reader.hasNext()) {
                XMLEvent event = reader.nextEvent();
                if (event.getEventType() == XMLStreamConstants.DTD
                        || event.isEntityReference()) {
                    throw new XMLStreamException("本例不接受DTD或实体引用事件");
                }
                if (event.isStartElement()) {
                    if (stack.size() >= maxDepth) {
                        throw new XMLStreamException("元素嵌套过深");
                    }
                    stack.push(new Frame(
                            event.asStartElement().getName(), new StringBuilder()));
                } else if (event.isCharacters() && !stack.isEmpty()) {
                    StringBuilder text = stack.peek().text();
                    String part = event.asCharacters().getData();
                    if (part.length() > maxText - text.length()) {
                        throw new XMLStreamException("元素直接文本过长");
                    }
                    // 追加所有片段，包括业务可能需要的空白。
                    text.append(part);
                } else if (event.isEndElement()) {
                    Frame done = stack.pop();
                    // 只交付本元素直接文本，不自动拼接子元素文本。
                    sink.accept(done.name(), done.text().toString());
                }
            }
        }
    }
}

在 Java SE 25 的接口定义中，XMLEventReader 有 close()，但没有实现 AutoCloseable，不能仅凭有 close 方法就直接放进 try-with-resources。这里用 Events 包装后，先关闭事件读取器，再关闭外层 InputStream；资源关闭异常由语言的资源管理机制处理。reader.close() 本身不负责关闭底层输入源。

最大深度64和单元素文本100000只是示例预算，不是 Java 或 XML 的标准限制。StringBuilder 长度按 UTF-16 代码单元计算，不是 UTF-8 字节数，也不是用户看到的字符个数。总文件大小、解析器内部缓冲、处理时间和回调保留的数据仍需应用另行约束，不能把两个上限当作全部资源保护。

本例不使用 DTD 或外部实体，因此在工厂上明确关闭相关支持，并设置拒绝外部解析的 resolver；若解析器不接受配置，不应捕获配置错误后继续按默认设置运行。这里没有加入任何外部资源读取示例。生产环境应结合实际解析器提供者及 JAXP 文档制定完整输入策略。

getElementText和nextTag能替代循环吗

只有需求符合它们的前提时才适合。getElementText() 面向纯文本元素：调用时当前事件必须是开始元素，返回后已经到达对应结束元素。如果内容出现嵌套元素，会产生异常。它不只是“查看一下文本”，而是会推进读取位置。

nextTag() 用于跳过不重要的空白并寻找开始或结束标签；不适合有实际文本内容的混合结构。peek() 则只观察下一个事件，不消费它。把这些方法混进通用循环时，应明确哪个方法已经消耗了哪些边界，避免重复等待已经经过的结束标签。

如果为某种固定文档选用了 getElementText()，就不要照搬上面的通用栈处理原样使用：两者对事件消费的职责不同。先选择一种清楚的读取模型，再针对特定元素增加逻辑。

解析失败后，哪些数据可以继续使用

示例在遇到文件读取、XML解析或回调异常时向调用方报告失败，不把异常当成正常到达文档结尾。XMLStreamException 中的位置等信息可以用于诊断，但日志不必输出完整文档正文。对导入任务还要区分“已交付的部分记录”与“整个任务成功”。

因为回调在读取过程中已经执行，后面解析失败不会自动撤销此前写入数据库的记录。如果业务要求整份文档要么全部成功、要么全部失败，需要另外使用事务或暂存机制；不能因为事件读取器是流式接口就推断它具有事务能力。

能把所有空白Characters都丢掉吗？不能一概而论。格式化空白和业务文本中的空格需要按文档规则区分。上例保留片段；是否 trim 应放在明确的字段映射阶段。

已经逐事件读取，内存就一定很小吗？不一定。例子的文本缓存受应用预算约束，但如果 sink 把每个字符串都加入集合，总内存仍会随输出增长。逐事件只是读取方式，不是整个程序的内存保证。

没有使用DTD，是否意味着完成了业务结构校验？不是。识别XML语法、限制外部资源、核对必填字段和执行业务约束是不同任务。需要的元素、属性和数据类型应在自己的业务处理层明确规定。

参考资料：XMLEventReader；XMLInputFactory；Characters；StartElement；JAXP安全指南。