JSON屋工具合集

bean解析json转xml：从对象字段到XML节点的映射思路

更新于

手里有一个Java Bean，接口返回的却是JSON，下游系统只认XML——这类转换在对接老系统、生成报文时经常遇到。bean解析json转xml的核心，是把Bean的字段结构当作参照，先解析JSON得到对象树，再按字段类型和命名规则逐层生成XML节点。真正让人头疼的不是转换动作本身，而是字段名大小写、空值、数组与嵌套对象这些细节该按什么规则落到标签上。

在线工具JSON转XML

先想清楚：你是要Bean结构，还是要JSON里的实际数据

很多人把这件事理解成“把Bean序列化成XML”，但输入其实是JSON文本。Bean在这里扮演的是模板角色：它告诉你哪些字段可能存在、每个字段是什么类型、嵌套关系如何。解析时先按JSON的实际内容构建对象树，再用Bean的字段定义去校验和取值。

如果JSON里出现了Bean没有的字段，是丢弃还是保留？这取决于下游对报文的宽容度。丢弃更安全，结构稳定；保留则要借助额外的容器字段承接。反过来，Bean里有而JSON里没有的字段，通常输出空节点或直接省略，两种做法在对接方那里表现不同，最好提前确认。

字段名到标签名的映射，别指望自动对齐

Bean字段习惯用小驼峰，XML标签却常见下划线或短横线风格，直接照搬字段名往往对不上。比较稳妥的做法是维护一张映射表，或者利用注解声明每个字段对应的标签名。数组字段尤其要留意：JSON里的数组转成XML后，通常表现为同名标签重复出现，也可能需要一个包裹节点，这属于结构约定而非技术限制。

嵌套对象则对应一层子节点，层级深度跟着Bean的嵌套走。遇到Map这类动态结构，标签名来自键名，需要额外做合法性检查，避免出现XML不允许的字符。关于解析与生成的完整链路，可以参考c实现json转xml文件：从解析到生成的完整教程中的思路，虽然语言不同，字段遍历与节点拼装的逻辑是相通的。

类型判断和空值处理决定输出是否可用

JSON里的数字没有整数和小数之分，Bean字段却可能声明为int或BigDecimal。解析时按Bean类型做转换，比直接照搬JSON字面量更可靠，也能避免精度丢失。布尔值同理，XML里通常写成true/false文本，但有些对接方要求特定写法，需要按约定输出。

空值是最容易出问题的地方。null字段是输出空标签、输出带属性的空节点，还是整个省略？不同系统解析结果差别很大。日期字段还要统一格式，JSON里的时间字符串和XML期望的格式未必一致，转换环节就得完成格式化，而不是留给下游猜。

动手时的顺序：解析、映射、生成、校验

实际编码时，可以先解析JSON得到通用对象树，再按Bean定义逐字段读取，边读边生成节点。生成阶段建议先拼出一棵内存中的节点树，最后统一输出文本，这样便于在输出前做一次结构检查，比如确认必填节点存在、标签名合法、层级没有意外加深。

如果只是临时验证一段JSON转成XML后的样子，用JSON转XML在线看一下结果，比反复改代码更快。确认结构无误后，再把映射规则固化成代码里的配置或注解，后续同类报文就能沿用同一套规则。

总结

bean解析json转xml的关键不在转换动作，而在字段映射规则：Bean提供类型与结构参照，JSON提供实际数据，两者之间的命名、数组、空值和格式差异都要显式约定。先解析再按字段生成节点，最后做一次结构校验，能让输出更可控。

相关文章

常见问题

Q1Bean里没有的JSON字段，转换时应该保留吗？

看下游是否需要。保留会让XML结构随输入变化，稳定性下降；丢弃则结构固定，但可能丢失信息。若必须保留，建议放在专门的扩展节点下，与固定字段区分开。

Q2JSON数组转XML后为什么标签重复出现？

XML没有原生数组类型，常见做法是用同名标签重复表示多个元素。也有系统要求外层加一个包裹节点，再在内部重复子标签，具体按对接方约定选择。

Q3空值字段输出空标签还是直接省略？

两种都常见，取决于对方解析器的行为。省略更简洁，空标签能保留字段存在性。建议在转换前明确约定，并在生成阶段统一处理，不要混用。

Q4日期和数字格式需要在转换时处理吗？

需要。JSON里的字面量格式未必符合XML对接要求，按Bean字段类型解析后重新格式化，比原样搬运更稳妥，也能避免精度和时区问题。