Conversor de XML para JSON

O modelo de dados do XML é estritamente mais rico que o do JSON. XML tem filhos ordenados, atributos, texto intercalado com elementos, namespaces, comentários e CDATA. JSON tem objetos sem ordem, arrays, strings, números, booleanos e null. Qualquer função do primeiro para o segundo precisa descartar algo ou inventar algo.

Michael Kay disse isso sem rodeios no artigo dele no Balisage sobre conversão ciente de esquema: um conversor genérico "está adivinhando qual é a semântica do modelo de objetos por trás do XML léxico, e está adivinhando errado". Estes são os sete pontos em que ele precisa adivinhar:

• Atributos versus elementos filhos. <user id="7"/> e <user><id>7</id></user> são documentos diferentes que a maioria das pessoas quer como o mesmo JSON. Junte-os e <user id="7"><id>8</id></user> produz uma chave duplicada, o que a RFC 8259 chama de imprevisível.
• Uma ocorrência ou várias. Nada em <items><item>a</item></items> diz se item pode se repetir, então o conversor adivinha contando.
• Conteúdo misto. <p>Um texto <b>importante</b>.</p> tem três filhos ordenados, e um objeto JSON não consegue expressar essa ordem.
• Texto só de espaço em branco. A quebra de linha e a indentação entre elementos em XML formatado são nós de texto reais, e mantê-los é fiel mas inutilizável.
• Namespaces. Um prefixo não é o nome, o nome é a URI, e o JSON não tem nenhum conceito de namespace.
• Comentários e instruções de processamento. Nenhum dos dois existe em JSON.
• Elementos vazios. <e/> mapeia de forma plausível para null, "", {} ou uma chave de texto vazia, e <e/> e <e></e> são o mesmo documento.

O padrão é a convenção de prefixo de atributo que Stefan Goessner descreveu em 2006, da qual fast-xml-parser, xml2js e o SDK da AWS usam variantes. Atributos recebem o prefixo @_ para não colidirem com um elemento filho de mesmo nome. Texto que divide um elemento com atributos ou filhos vai para #text. Um elemento que aparece uma vez é um valor; aparecendo duas vezes vira array. Um elemento só de texto colapsa para uma string simples, então <name>Alice</name> é "Alice".

O elemento raiz permanece como chave mais externa, comentários são descartados, espaço em branco é aparado e referências de entidade são resolvidas, então um atributo escrito "A &amp; B" chega como "A & B". Os controles acima do editor definem o prefixo de atributo, a chave de texto, uma lista de nomes de elemento "sempre um array", e três caixas: remover prefixos de namespace, descartar atributos e converter tipos. As três vêm desligadas.

<order id="00042">
  <total currency="GBP">19.90</total>
  <line sku="0071">Widget</line>
  <line sku="0072">Gasket</line>
  <note/>
</order>

{
  "order": {
    "@_id": "00042",
    "total": { "@_currency": "GBP", "#text": "19.90" },
    "line": [
      { "@_sku": "0071", "#text": "Widget" },
      { "@_sku": "0072", "#text": "Gasket" }
    ],
    "note": ""
  }
}

XML sem esquema é texto do começo ao fim. Transformar "123" em número é conveniente até exatamente o ponto em que destrói um identificador, e identificadores são a maior parte do que trafega em integrações XML.

Quando você liga a conversão, ela é deliberadamente estreita. Um valor só vira número se casar com uma gramática estrita de número JSON e depois sobreviver a uma ida e volta: o resultado analisado é serializado de novo e comparado com o original, caractere por caractere. É essa checagem que evita as falhas que outros conversores entregam. Mesmo com a conversão ligada, estes continuam strings:

• Zeros à esquerda. "00042" e "01730" falham logo na gramática, porque um número JSON não pode começar com zero seguido de mais dígitos. CEPs, códigos bancários e SKUs sobrevivem.
• Zeros à direita depois da vírgula decimal. "19.90" vira 19.9, que serializa de volta como "19.9", então a string é mantida. "1.10" não vira 1.1.
• Inteiros que um double não comporta. "9007199254740993" vira um valor terminado em 992, a ida e volta falha, e a string é mantida. É isso que corrompe identificadores de pedido de dezenove dígitos em outros lugares.
• Expoentes não canônicos. "1e5" vira 100000, que não é "1e5", então continua texto.
• Qualquer coisa que não seja exatamente true, false ou null. "TRUE", "yes" e "Y" continuam strings.

Três coisas não sobrevivem. A ordem do documento entre irmãos de nomes diferentes some, então se <line> e <discount> se alternam, o JSON não diz nada sobre como. Conteúdo misto é achatado: os fragmentos de texto são concatenados e os elementos entre eles vão para chaves próprias, então <root>35<nested>34</nested>46</root> dá um valor de texto "3546". Comentários são descartados.

Namespaces são mantidos literalmente em vez de resolvidos, então soap:Body vira a chave "soap:Body". Remover prefixos dá "Body", mas aí dois elementos de namespaces diferentes com o mesmo nome local colidem numa chave só, e o JSON não oferece uma terceira opção.

Se esta convenção não é o que o seu consumidor espera, as alternativas têm nome. O BadgerFish põe texto em $, atributos em @nome e carrega todo namespace em escopo: melhor ida e volta, quase ilegível. O Parker descarta atributos e absorve a raiz, a saída mais enxuta e mais de mão única de todas. O JsonML escreve cada elemento como [nome, atributos, filhos], a única convenção comum que preserva intactos o conteúdo misto e a ordem dos filhos.

A mesma conversão nas linguagens que realmente consomem XML. Cada exemplo desativa a resolução de entidades, porque o padrão de várias dessas pilhas busca uma URL indicada num DOCTYPE, que é a vulnerabilidade XXE. Cada um também nomeia a decisão de mapeamento que aquela biblioteca toma por você.