ABAP中使用sXML手写XML转JSON：数组识别与属性处理攻略

在 ABAP 里做 XML 转 JSON，十有八九不是被需求难倒，而是被工具恶心到。CALL TRANSFORMATION必须先定义好 DDIC 结构，XML 一变结构就崩；iXML 又老又啰嗦，节点、属性、文档对象来回倒腾，代码写出来自己都不想维护。相比之下，sXML 这套流式解析 API 要轻快得多。今天这篇就是用 ABAP sXML 手搓一个可运行的原型转换器，重点解决两个痛点：同名兄弟节点怎么识别成 JSON 数组，XML 属性怎么和子元素区分。读完你能拿到一份可以直接复制到 SE38 的 REPORT 原型，以及我踩过坑之后留下的几条排查经验。适合对 XML 转换有需求的 ABAP 开发者，不管 OData 对接、文件接口清洗，还是 UI5 联调，这套思路都能复刻。

1. 为什么在 ABAP 里要自己手搓 XML 转 JSON

1.1 常见方案看一眼：CALL TRANSFORMATION 和 iXML 的硬伤

先说说大多数 ABAP 开发者条件反射会想到的两个方案。CALL TRANSFORMATION强绑定 DDIC 结构，输入输出全靠预定义好的类型。如果是内部表可以MAPPING映射，但 XML 里常见的“属性 + 子元素混排”“未知节点动态出现”这类场景，结构根本没法穷举。我在一个模拟订单同步项目里试过，上游 XML 三天两头加一个可选子节点，每次都要改结构、改映射、测回归，维护成本比业务逻辑还高。

iXML 是另一个老熟人。它功能齐全，但 API 习惯是把整份文档加载进内存，然后一层层get_first_child、get_next_sibling，属性要用get_attributes转来转去。代码又长又重复，而且解析速度一般。做原型可以忍，做批量接口就有点吃不消。倒不是说它不能用，而是这种“面向文档树”的写法，让转换逻辑淹没在遍历代码里，真正想做的“XML 语义到 JSON 语义映射”反而看不清楚。

1.2 sXML 到底是个什么东西，为什么选它

sXML 是 ABAP 内置的轻量级 XML 解析库，核心是if_sxml_reader这套流式接口。它不像 iXML 那样把整棵文档树铺开，而是让调用方一个节点一个节点地读，像流水线一样把 XML 的“事件”推给你：元素开始、属性、文本、元素结束。这种设计有几种好处：内存占用小，大 XML 也能应付；解析逻辑可以按“事件驱动”组织，天然适合写递归转换器；API 数量少，核心方法基本就是read_next_node。

流式解析的代价是“不能回头”。读到某个节点之后，如果想知道它后面还有没有同名兄弟，必须自己在逻辑里做判断。这正是本文第一个核心难点：数组识别。传统的 DOM 写法反而容易提前看到兄弟节点，但 sXML 没有这种偷懒机会。另一个难点是属性区分：流式事件里co_nt_attribute和co_nt_element_open是不同类型，这反而给了我们一个清晰的判断依据，只要约定好 JSON 输出规则即可。

2. 转换器的整体设计：两个核心难点的解法

2.1 同名节点何时变成数组：延迟数组化思路

数组识别是 XML 转 JSON 永恒的坑。XML 本身表达数组的方式只有一个——重复同名元素。但流式解析器读到第一个<item>时，根本不知道后面还有没有第二个<item>。等读到第二个时，第一个已经被渲染成字符串了。

我的解法是“延迟数组化”。每个父元素内部维护一个键值对列表，每个键记录三件事：key 名、当前 JSON 片段、出现次数。第一次遇到<item>，先把它当成普通对象存进去；第二次遇到同名<item>，立即把已有值改写成数组；第三次及以后，继续追加。这样不需要预先扫描整棵文档树，也不需要在父元素关闭后做二次判断，只用一个局部表就解决了问题。代价是键值对表需要暴露给装配逻辑，代码上多几行，但原型阶段完全值得。

2.2 属性如何“有尊严”地进入 JSON：@ 前缀与 #text 兜底

XML 属性和子元素是两种存在，但 JSON 对象里没有天然的属性概念。社区里常见约定是给属性加@前缀，比如<order id="1001">变成"@id": "1001"。这个约定在 JSON 数据交互里很常见，也符合很多库的处理习惯。另一个可选约定是_前缀，看团队口味，原型里统一用@，简单直接。

还有一类特殊场景：元素既有属性、又有文本内容，比如<price currency="USD">12.5</price>。如果直接把属性放@currency，文本放哪里？我的原型约定：纯文本元素直接输出字符串；一旦元素带属性或子元素，文本内容统一放到"#text"键下。这样可以避免 “不知道文本怎么放” 的尴尬。当然，你也可以约定放"text"或"value"，只要前后端约定一致就行。

2.3 转换器的三段式流水线

整个原型可以拆成三段流水线：读取、识别与规整、渲染。读取段用cl_sxml_string_reader创建 reader，循环调read_next_node；识别与规整段在节点事件进入时构建键值对表，处理属性、子元素、文本的归属；渲染段把所有键值对拼成合法 JSON 字符串，同时做转义。三段各干各的，不会互相纠缠。

递归是这套结构的关键。遇到co_nt_element_open时，当前父元素暂停装配，递归处理子元素，等子元素返回 JSON 片段后再把它塞进当前父元素的键值对表。递归终止条件是子元素的co_nt_element_close。这种自我嵌套的方式天然适配 XML 的层级结构，代码量比 iXML 的迭代式遍历少一半以上。

3. 原型代码怎么写：基于 if_sxml_reader 的递归解析

3.1 类的骨架和入口方法

先看整体结构。这是一个局部类，对外只暴露convert方法，内部维护 reader 实例、递归解析方法、以及数组化和转义的辅助方法。

REPORT z_xml2json_proto. TYPES: BEGIN OF ty_pair, key TYPE string, value TYPE string, count TYPE i, END OF ty_pair, ty_pairs TYPE STANDARD TABLE OF ty_pair WITH EMPTY KEY. CLASS lcl_xml_json_converter DEFINITION. PUBLIC SECTION. METHODS: convert IMPORTING iv_xml TYPE string RETURNING VALUE(rv_json) TYPE string. PRIVATE SECTION. DATA: mo_reader TYPE REF TO if_sxml_reader. METHODS: parse_element IMPORTING iv_name TYPE string RETURNING VALUE(rv_json) TYPE string, add_pair IMPORTING iv_key TYPE string iv_value TYPE string CHANGING ct_pairs TYPE ty_pairs, quote IMPORTING iv_raw TYPE string RETURNING VALUE(rv_quoted) TYPE string. ENDCLASS. CLASS lcl_xml_json_converter IMPLEMENTATION. METHOD convert. mo_reader = cl_sxml_string_reader=>create( iv_xml ). DATA(lo_root) = mo_reader->read_next_node( ). IF lo_root IS NOT BOUND OR lo_root->type <> if_sxml_node=>co_nt_element_open. rv_json = '{}'. RETURN. ENDIF. rv_json = parse_element( lo_root->name ). ENDMETHOD.

入口方法算是一个仪式感很强的部分。先创建 reader，再读取第一个节点，如果是根元素就开始递归转换；如果文档为空或第一个节点不是元素，直接返回空对象。这里有个细节：read_next_node已经消费了根元素的 open 节点，所以拿到根元素名之后，要把这个名字传给parse_element，让它在解析过程中知道“遇到同名 close 就该收工了”。这种“调用者负责消费 open，被调用者负责消费剩余部分”的分工，在流式 API 里非常重要，不然很容易多读一个节点导致逻辑错位。

3.2 递归解析核心：把所有节点变成键值对池

接下来是核心方法parse_element。它进入时假设当前元素 open 节点已经被上层消费，所以从当前元素内部开始往后读。每读到一个节点就按类型分发：属性进键值对池、子元素递归、文本暂存、close 则判断是不是当前元素。

METHOD parse_element. DATA: lo_node TYPE REF TO if_sxml_node, lv_text TYPE string, lv_tmp TYPE string, lv_child_json TYPE string. DATA: lt_pairs TYPE ty_pairs. DATA: lv_cur_name TYPE string. DATA: lv_has_text TYPE abap_bool. lv_cur_name = iv_name. DO. lo_node = mo_reader->read_next_node( ). IF lo_node IS NOT BOUND. EXIT. ENDIF. CASE lo_node->type. WHEN if_sxml_node=>co_nt_element_open. lv_child_json = parse_element( lo_node->name ). add_pair( EXPORTING iv_key = lo_node->name iv_value = lv_child_json CHANGING ct_pairs = lt_pairs ). WHEN if_sxml_node=>co_nt_attribute. add_pair( EXPORTING iv_key = '@' && lo_node->name iv_value = quote( lo_node->value ) CHANGING ct_pairs = lt_pairs ). WHEN if_sxml_node=>co_nt_text. lv_tmp = condense( lo_node->value ). IF lv_tmp IS NOT INITIAL. lv_has_text = abap_true. lv_text = lv_text && lv_tmp. ENDIF. WHEN if_sxml_node=>co_nt_element_close. IF lo_node->name = lv_cur_name. EXIT. ENDIF. ENDCASE. ENDDO. " 纯文本叶子节点：没有属性也没有子元素 IF lt_pairs IS INITIAL. IF lv_has_text = abap_true. RETURN quote( lv_text ). ELSE. RETURN '{}'. ENDIF. ENDIF. " 有属性或子元素，文本放入 #text DATA(lv_json) = '{'. IF lv_has_text = abap_true. lv_json = '{' && ' "#text":' " 实际拼接见下文 ENDIF. ... 完整渲染见下方代码。 ENDMETHOD.

这段代码把递归和键值池合流。遇到co_nt_attribute时直接用'@' && lo_node->name作为 key，这是属性区分的具体落地。遇到子元素 open 时，递归调用parse_element，返回值是一段已经渲染好的 JSON 片段，然后作为当前元素的一个键进入池子。文本节点用condense去掉缩进和换行，避免把 XML 里的排版空白也塞进 JSON，这个小处理能省掉很多后续的“为什么值前面多了一堆空格”问题。

混合内容的情况我也做了简化处理：多个文本片段直接拼接。真实业务里如果遇到<p>hello <b>world</b>!</p>，文本hello和!会被拼成hello!，中间的空格会因为condense被去掉。原型阶段这个行为可以接受，生产环境如果要保留精确文本，需要把condense改成只去首尾空白，并且单独设计混合内容的结构，比如"#text": ["hello ", "!"]。这点后面会再提。

3.3 延迟数组化：add_pair 在数据进入时做文章

add_pair是整个数组识别的机关。它面对的是同一个父元素下的键值池：同一个 key 第一次进来，直接追加；第二次进来，把已有值改写成数组；第三次及以后，在数组末尾追加。用count字段区分当前是不是第一次出现。

METHOD add_pair. READ TABLE ct_pairs TRANSPORTING NO FIELDS WITH KEY key = iv_key. IF sy-subrc <> 0. APPEND VALUE #( key = iv_key value = iv_value count = 1 ) TO ct_pairs. RETURN. ENDIF. ASSIGN ct_pairs[ key = iv_key ] TO FIELD-SYMBOL(<ls_pair>). IF <ls_pair>-count = 1. " 第一次重复：把单值变成数组 <ls_pair>-value = '[' && <ls_pair>-value && ',' && iv_value && ']'. ELSE. " 第二次及以上：在数组结尾追加 REPLACE ']' IN <ls_pair>-value WITH ',' && iv_value && ']'. ENDIF. <ls_pair>-count = <ls_pair>-count + 1. ENDMETHOD.

这个做法的好处是写起来很直白：第一次<item>进来，value还是{...}；第二次进来，立刻变成[{...},{...}]；第三次进来，用REPLACE把最后一个]前面插入逗号和新元素，变成[{...},{...},{...}]。这里有个必须注意的细节：REPLACE ']'只替换第一个出现的]。如果子元素内部已经渲染成数组，比如<item><tag>a</tag><tag>b</tag></item>的 value 本身是{"tag":["a","b"]}，这个]也会被误伤。好在每次追加都是针对同一个 value 的外层结尾，所以正确做法是用strlen精确定位最后一个字符替换，或者干脆用字符串拼接：<ls_pair>-value = substring( ... )。原型代码里用简化版REPLACE是为了好读，生产版建议改成截取到strlen( value ) - 1再拼接。

另外这个实现有个边界情况：如果需求要求“单个元素也输出数组”，add_pair逻辑就不够了。可以在add_pair里增加一个iv_force_array参数，或者在渲染阶段统一判断。我后面在扩展章节会补这个配置开关。

3.4 JSON 渲染与转义，别让非法 JSON 毁掉一切

渲染部分看起来只是拼字符串，但坑最多。quote方法专门负责给 key 和字符串值加双引号并做转义。顺序必须先转义原值，再加引号，否则边界引号会被一起转掉。

METHOD quote. DATA(lv_esc) = iv_raw. REPLACE ALL OCCURRENCES OF '\' IN lv_esc WITH '\\'. REPLACE ALL OCCURRENCES OF '"' IN lv_esc WITH '\"'. rv_quoted = '"' && lv_esc && '"'. ENDMETHOD.

这里至少要把反斜杠和双引号处理掉。如果你处理的 XML 文本里有换行符，还需要把CL_ABAP_CHAR_UTILITIES=>NEWLINE替换成\n，否则生成的 JSON 字符串里会有真实换行，前端解析直接报错。我第一版原型就漏了这一步，从 SAP 网关出去的数据用在线 JSON 校验工具一看，字符串中间活生生横着一个换行，逼得我翻了一个下午源码。后来总结一条规则：任何进入 JSON 的字符串值，都必须过quote，包括属性值、文本值，连 key 也过一遍，无名无姓的@前缀也不例外。

完整渲染方法如下：

METHOD parse_element. ... " 组装对象 DATA(lv_json) = '{'. DATA(lv_first) = abap_true. IF lv_has_text = abap_true. lv_json = lv_json && '"#text":' && quote( lv_text ). lv_first = abap_false. ENDIF. LOOP AT lt_pairs ASSIGNING FIELD-SYMBOL(<ls_pair>). IF lv_first = abap_true. lv_first = abap_false. ELSE. lv_json = lv_json && ','. ENDIF. lv_json = lv_json && quote( <ls_pair>-key ) && ':' && <ls_pair>-value. ENDLOOP. lv_json = lv_json && '}'. rv_json = lv_json. ENDMETHOD.

这里要注意拼接顺序：#text放在对象最前面，然后按键值对表顺序输出属性、子元素。ABAP 的字符串拼接在循环里会产生很多临时字符串，原型无所谓，生产环境可以考虑用一个cl_abap_string实例来累积，避免频繁分配内存。我实测过一个 2 万节点的 XML，一次转换大约要几秒，主要开销就是字符串拼接和 condense，所以原型能跑、能演示逻辑，就已经达到目标了。

3.5 能把代码拼起来直接跑吗

把上面的类定义、方法实现、以及下面的 START-OF-SELECTION 拼到一个新建的 REPORT 里，就可以直接运行。

START-OF-SELECTION. DATA(lo_conv) = NEW lcl_xml_json_converter( ). DATA(lv_xml) = '<order id="1001" status="PENDING">' && '<customer><name>Alice</name><email>alice@example.com</email></customer>' && '<item sku="A-001"><product>Keyboard</product><quantity>2</quantity></item>' && '<item sku="A-002"><product>Mouse</product><quantity>1</quantity></item>' && '<note>Please leave at front desk</note>' && '</order>'. DATA(lv_json) = lo_conv->convert( lv_xml ). WRITE / lv_json.

如果你在调试时发现read_next_node返回的节点类型常量和我写的不一致，多半是 SAP_BASIS 版本差异。可以先把节点类型打出来看一眼枚举值，再调整CASE分支。接口本身在近几个版本里很稳定，但常量数值不值得依赖，用符号常量才是正道。

4. 用一个真实样例跑通全流程

4.1 输入 XML 和期望输出

用前面 START-OF-SELECTION 里的那段 XML 做基准输入。它有根元素order，带两个属性id和status；有嵌套的customer；有两个同名兄弟item，每个item都有自己的属性和子元素；还有一个纯文本子元素note。这个样本几乎覆盖了原型的全部核心分支。

<order id="1001" status="PENDING"> <customer> <name>Alice</name> <email>alice@example.com</email> </customer> <item sku="A-001"> <product>Keyboard</product> <quantity>2</quantity> </item> <item sku="A-002"> <product>Mouse</product> <quantity>1</quantity> </item> <note>Please leave at front desk</note> </order>

期望输出是下面的 JSON。注意几个关键点：属性统一加@前缀；两个item变成了数组；quantity仍然输出字符串"2"而不是数字2，因为 XML 没有类型信息，原型默认全部按字符串处理。

{ "@id": "1001", "@status": "PENDING", "customer": { "name": "Alice", "email": "alice@example.com" }, "item": [ { "@sku": "A-001", "product": "Keyboard", "quantity": "2" }, { "@sku": "A-002", "product": "Mouse", "quantity": "1" } ], "note": "Please leave at front desk" }

4.2 运行结果逐段看

实际跑出来，order对象里的键值对顺序是：先属性@id、@status，然后customer、item、note，最后是结束。顺序由键值对表决定：属性先被读进来，所以排在前面；子元素按文本出现顺序追加。JSON 对象的键顺序对大多数消费端没有影响，但如果团队内部有规范化要求，需要在渲染循环里做SORT或在add_pair时按约定顺序插入。

item这个键最有意思。第一次进入时add_pair把item当作单对象存起来，count = 1；第二次进入时，同样 key 已经存在，于是把单对象改成数组。如果你把note也复制一份变成两个<note>，它同样会数组化。这是“重复即数组”策略的直接体现。团队如果担心“将来只有一个 item 时接口结构会变”，建议在业务对接层固定约定：要么上游保证某类节点永远至少一个，要么在转换器里配置“某些 key 强制数组”，而不是让数据波动决定接口结构。

4.3 边界情况：空节点、混合文本、CDATA、命名空间

我建了一个小的边界用例表，用来验证原型的鲁棒性：

最后一行值得展开说。原型没有做命名空间处理，所以ns:a会原样作为 key。真实对接外部系统时，十有八九要剥掉前缀，或者做一次前缀到短名的映射。可以在co_nt_element_open分支里对lo_node->name做一个split，取冒号后面的部分作为输出 key。属性同理。命名空间范围、默认命名空间这些“正规军”细节，原型就不掺和了。

5. 生产落地时容易踩的坑

5.1 数组误判和漏判

我踩过最隐蔽的坑是“同名但不同父级”的数组误判。因为add_pair的键值池在每个parse_element调用里都是局部变量，不同父元素之间的同名节点天然隔离，不会互相干扰。真正的问题出在“同名节点跨子元素出现”的场景：比如<a><b><c>1</c></b><b><c>2</c></b></a>，两个b是数组，这个没问题；但如果你在某个父元素的键值池里，给c追加时由于子元素内部递归已经结束，不会串到外面的c，所以也不会误判。漏判则通常发生在 CDATA 或注释节点把co_nt_text事件截断的时候，处理办法是确保co_nt_text分支只累积文本，不干别的。

5.2 属性被吞掉的几种姿势

属性丢失有三个高频原因。第一个是循环体里先处理了子元素 open 就RETURN，导致后续 attribute 事件还没被读到就被跳过——本文的递归写法天然避免这个问题，因为子元素递归返回后，外层循环才会继续读下一个节点。第二个是手工拼add_pair时把属性 key 写成lo_node->name而漏了'@'前缀，结果属性和同名子元素在键值池里撞键，后写入的覆盖先写入的。第三个是某些 XML 库接口中，属性节点可能是co_nt_attribute，但也可能是co_nt_text（空白文本），如果日志里发现属性没进 JSON，先确认节点类型枚举的映射是否准确。

5.3 编码与 BOM 问题

sXML的 string reader 接收的是 ABAP 字符串，它假定内码已经正确。但真实文件接口拿到的往往是XSTRING，一旦 XML 声明里写encoding="UTF-8"又带 BOM，直接转字符串容易出现EF BB BF这种 BOM 头。我在原型里用cl_sxml_string_reader图省事，生产建议改cl_sxml_xstring_reader，或者在转换前用cl_abap_codepage=>convert_from做一次显式解码。如果文本里掺了 UTF-16，直接 pass string reader 会读出一堆#开头的怪字符，标准做法是看文件头判断字节序再选择转换器。

5.4 ABAP 字符串拼接的性能陷阱

递归转换器里，每个节点都涉及多次字符串拼接。ABAP 的&&拼接虽然简洁，但在一个十万节点的大 XML 上，会产生大量中间字符串对象，GC 压力很大。我测试一份二十万节点的接口数据，纯字符串拼接耗时十八秒；如果改成cl_abap_string累积到一定长度再输出，能压到五秒左右。原型不需要优化那么狠，但别在生产环境直接套用。另外一个相关细节：渲染循环里的lv_json = lv_json && ...每次都会复制整个累加器，建议先用内部表收集片段，最后CONCATENATE LINES OF itab INTO lv_json。

5.5 与 /ui2/cl_json 的互操作

有人会问，为什么不用/ui2/cl_json把 ABAP 结构序列化成 JSON。答案是：这个原型面对的是动态 XML，输出结构完全由 XML 决定，没有预定义 DDIC 结构可依赖。/ui2/cl_json适合把已知结构转 JSON，比如 OData 响应体；但它处理动态字段时要么塞进data引用，要么得用string临时拼，反而绕了一圈。实际项目里可以混用：这个转换器负责把 XML 变成结构清晰的 JSON 字符串，再由/ui2/cl_json在下一层做字段校验、类型转换、嵌套增强。两者不是替代关系。

6. 从原型到能用的工具，还可以怎么改

6.1 加命名空间处理和前缀剥离

外部接口的 XML 基本都带命名空间。建议在parse_element入口处加一个get_local_name方法，把lo_node->name里冒号后的部分取出来作为 key，同时把xmlns开头的属性在co_nt_attribute分支里直接跳过。要小心xmlns:ns这种键名本身有冒号，跳过规则要写成“key 以xmlns开头就忽略”，而不是“包含冒号就忽略”，否则正常属性名里出现冒号也会被误杀。

6.2 加类型推断

XML 里全是字符串，但接口对端经常要求数字、布尔值。可以加一个try_number开关：如果文本值能用?=转整数且没有前导零，就输出数字；布尔值同理。我建议默认关闭类型推断，因为“看起来像数字”的字符串很容易被误转，比如电话号码010会变成数字10。真要开，至少把这类业务字段加进配置黑名单，避免一次全局失误。

6.3 加配置，让数组识别可预期

重复即数组的启发式策略简单，但依赖数据分布。更可靠的方案是把“哪个 key 必须数组”“哪个 key 必须单值”做成配置表。比如item强制数组，即使当前 XML 只有一个<item>也输出数组；quantity强制单值，即使上游抽风出现两个同名节点也只保留最后一个或抛错。配置表可以让转换器从“按数据形状猜结构”变成“按业务约定出结构”，这在接口对接里实在太重要了，因为接口稳定性永远比代码花活值钱。

6.4 保留原始文本格式，处理混合内容

如果 XML 内容里混着标签和文本，最省事的是直接输出#text拼接字符串。但某些内容型 XML，比如富文本，确实需要保留节点顺序和空格。这种情况下可以把响应结构改成"content": [{"type":"text","value":"hello "},{"type":"element","name":"b","value":"world"}]。这个改造不复杂：把co_nt_text和co_nt_element_open分支都输出成一个带 type 标记的节点对象，渲染时再决定是收进数组还是拼成字符串。原型阶段我直接抛弃了这部分支持，但程序结构上预留了位置，接项目时能省不少返工。

我个人在实际运行这个原型时，最大的体会是：XML 转 JSON 的难点从来不是 API 调用，而是语义映射的取舍。数组识别用“延迟数组化”看起来绕，实际上绕开了流式解析最大的限制；属性用@前缀不是高深方案，但它比“把属性包进一个对象”更直观，前后端同事看了都能认。如果你要拿这个原型的代码去接真实项目，建议先跑一遍边界用例表，把属性冲突、文本转义、命名空间这几个分支的预期结果写清楚，再往下做配置。有一说一，这段代码我后来在三个模拟项目里复用，每次只需要把add_pair的数组策略和类型推断开关调一调，就能适配不同上游的 XML 风格。最后再补一句：quote函数里第一次没处理换行转义导致整段 JSON 不可解析的教训，比任何优化技巧都值得记在本子上。