XMLは死んでいない（残念ながら）— 成人としてJSONに変換する

You learned REST. You embraced JSON. You thought the XML era was over, like Flash or IE6 — something you’d warn junior devs about like a campfire story. Then your new client handed you API credentials for their banking integration, and there it was: a 400-line SOAP envelope staring back at you.

Welcome back to XML. It never left.

Why XML Is Still Everywhere

For many developers building modern apps, XML feels like a relic. But in the real world — particularly in enterprise software, banking, healthcare, and government systems — XML is absolutely load-bearing infrastructure. Here’s where you’ll run into it:

• SOAP web services – Still the standard for financial institutions, insurance platforms, and large ERP systems. Your fintech integration probably goes through one.
• Banking APIs – ISO 20022, SWIFT messages, and many core banking APIs communicate in XML. There’s no REST option.
• Government data – HMRC, the IRS, and most government portals accept or return XML. This is not changing soon.
• Enterprise middleware – SAP, Oracle, and legacy ESB systems speak XML natively. If you’re integrating with anything enterprise-grade, odds are good you’ll hit XML.
• RSS and Atom feeds – Still XML. Many content pipelines, news aggregators, and monitoring tools depend on them.

The uncomfortable truth: XML isn’t going anywhere because the systems built on it aren’t going anywhere. Replacing a bank’s core infrastructure isn’t a sprint ticket. So you adapt.

XML vs JSON: The Structural Differences That Actually Trip You Up

Before you start converting, it helps to understand why XML-to-JSON isn’t just a format swap. The two formats model data differently, and those differences create real gotchas.

Side-by-Side: The Same Data in Both Formats

Take a simple customer order. Here it is in XML:

<order id="ORD-1042" currency="GBP">
  <customer>
    <name>Alice Martin</name>
    <email>alice@example.com</email>
  </customer>
  <items>
    <item sku="PRD-001">
      <description>Wireless Keyboard</description>
      <quantity>1</quantity>
      <price>49.99</price>
    </item>
    <item sku="PRD-007">
      <description>USB-C Hub</description>
      <quantity>2</quantity>
      <price>29.99</price>
    </item>
  </items>
</order>

And here’s the equivalent in JSON:

{
  "order": {
    "@id": "ORD-1042",
    "@currency": "GBP",
    "customer": {
      "name": "Alice Martin",
      "email": "alice@example.com"
    },
    "items": {
      "item": [
        {
          "@sku": "PRD-001",
          "description": "Wireless Keyboard",
          "quantity": "1",
          "price": "49.99"
        },
        {
          "@sku": "PRD-007",
          "description": "USB-C Hub",
          "quantity": "2",
          "price": "29.99"
        }
      ]
    }
  }
}

Already you can see the structural friction points. Let’s go through them.

Attributes vs Keys

XML elements can carry attributes (id="ORD-1042") alongside child elements and text content. JSON has no concept of attributes — everything is a key-value pair. The most common convention is to prefix attributes with @ when converting, giving you "@id": "ORD-1042". Some parsers use $ or flatten them entirely. The convention matters because your consuming code needs to know which prefix to expect.

Arrays vs Repeated Elements

This one bites developers constantly. In JSON, an array is explicit: [...]. In XML, there’s no such distinction — repeated sibling elements are implicitly a list. A parser that sees one <item> element might return an object. Two <item> elements? It returns an array. Your code breaks when the API returns a single result.

The fix is to force arrays for known list fields, or use a library that preserves type information. When you’re converting one-off data, double-check whether a field that looks like a single object might sometimes be a list in production payloads.

Text Nodes and Mixed Content

XML elements can hold both text content and child elements simultaneously (mixed content). JSON can’t represent this cleanly. Parsers handle it differently — some use a #text key, others use _, others just drop the mixed content. If you’re converting XML with mixed content, verify the output manually.

Namespaces

SOAP responses are full of XML namespaces: <ns2:getOrderResponse xmlns:ns2="http://...">. Depending on your parser, these either get stripped, collapsed into the key name (ns2:getOrderResponse), or mapped to a URI. Most of the time you want them stripped, but if two namespaces share an element name you’ll lose the distinction. Know what you’re working with before assuming the output is clean.

The Fast Path: Convert XML Online Without Writing a Parser

If you’re debugging an API response, exploring an unfamiliar XML schema, or doing a one-off conversion, writing a parser is overkill. Use the XMLからJSONへの変換ツール — paste your XML, get clean JSON back instantly, and inspect the structure before writing any code.

It handles attributes (with @ prefix convention), nested elements, repeated elements as arrays, and preserves text content — which covers the majority of real-world API payloads. Useful for quickly understanding what a SOAP response actually looks like once the envelope is stripped down to data.

Programmatic Conversion: What to Use in Production

For production code integrating with XML APIs, you want a proper library rather than hand-rolling a parser. Here are the go-to options by language:

JavaScript / Node.js

import { XMLParser } from 'fast-xml-parser';

const parser = new XMLParser({
  ignoreAttributes: false,
  attributeNamePrefix: '@',
  isArray: (name) => ['item', 'product', 'order'].includes(name),
});

const result = parser.parse(xmlString);

fast-xml-parser is the best choice for Node.js. Use isArray to force array treatment for known list elements — this prevents the single-item/array inconsistency bug that will eventually hit you in production.

パイソン

import xmltodict

with open('response.xml') as f:
    data = xmltodict.parse(f.read())

import json
print(json.dumps(data, indent=2))

xmltodict is the standard Python choice. It uses the @ convention for attributes and #text for text nodes. Note that it returns an OrderedDict, which serializes fine with json.dumps.

PHP

$xml = simplexml_load_string($xmlString);
$json = json_encode($xml);
$data = json_decode($json, true);

PHP’s simplexml_load_string + json_encode is the quick path, but it handles attributes inconsistently and can lose data in edge cases. For production work on SOAP responses, consider DOMDocument with LIBXML_NOBLANKS or a dedicated library.

Common Gotchas to Watch For

• Numbers come out as strings. XML has no numeric type — everything is text. Your price field will be "49.99", not 49.99. Cast explicitly after conversion.
• Boolean values stay as strings. <active>true</active> になります "active": "true". Check before using in conditionals.
• Empty elements become null or empty objects. <middleName/> might convert to null, ""、 または {} depending on the parser. Test the edge case.
• CDATA sections may or may not be preserved. If the API uses CDATA to escape HTML content, verify your parser handles it and doesn’t silently strip the content.
• Order is not guaranteed. XML element order can be significant in some schemas; JSON object key order is not. If sequence matters to the consuming system, handle it explicitly.

Working With SOAP Specifically

SOAP adds another layer on top of XML: every response is wrapped in an <Envelope> with a <Body>, often decorated with namespace declarations and a <Header> block. Before converting to JSON, you usually want to extract just the body content.

In Python with zeep (the SOAP client), you get Python objects directly and don’t need to parse XML yourself. In Node.js, soap と strong-soap do the same. If you’re hitting a SOAP endpoint raw with fetch または axios, you’ll need to strip the envelope manually before running your XML-to-JSON converter.

For quick inspection of SOAP responses, the XMLからJSONへの変換ツール is useful — paste the full envelope, see the complete structure, and work out which path to the data you actually need.

Accept the Reality and Move On

There’s a particular kind of grief that comes from realizing your greenfield project has to integrate with a SOAP API built in 2003. Let yourself feel it, then move on. XML is a solved problem — the parsers are mature, the conversion tools exist, and the gotchas are well-documented. You’re not the first developer to stare down a 400-line envelope.

Use the right library for your language, handle the type conversion explicitly, force arrays for known list fields, and test with real payloads rather than the idealized examples in the API docs. The docs will show you one item; production will send you fifty.

And for the exploratory work — understanding an unfamiliar XML schema, validating a conversion before you write code — keep the XMLからJSONへの変換ツール bookmarked. It’s faster than spinning up a script every time you need to inspect a payload.

あなたも好きかもしれません