Convertidor JSON a XML

1. 1

   Pega o suelta tu JSON

   Pega JSON en el cuadro o suelta un archivo .json, .jsonl, .ndjson, .geojson o .txt. JSON Lines se detecta solo — no tienes que cambiar de modo.

2. 2

   Nombra la raíz y los elementos repetidos

   Define el elemento superior (root por defecto). Elige si todos los elementos de un array se llaman item, se nombran según la clave de la que colgaba el array o según su singular — así books pasa a ser book.

3. 3

   Decide cómo se escriben los valores

   Elige en qué se convierte un null: un elemento vacío, xsi:nil o nada. Activa la asignación de atributos si tus claves usan la convención @nombre y #text. Elige la sangría, la declaración y la codificación de salida.

4. 4

   Convierte y luego descarga o copia

   Pulsa Convertir a XML. La vista previa se actualiza al cambiar cualquier ajuste, así ves la forma antes de exportar. Descarga el .xml, cópialo o genera un esquema .xsd a juego.

Este conversor gratuito convierte JSON en XML bien formado, en tu dispositivo. Pega o suelta un archivo, nombra el elemento raíz y los elementos repetidos que produce un array, decide en qué se convierten un null y una clave inservible, y exporta. La vista previa se actualiza al cambiar cualquier ajuste, así ves la forma antes de comprometerte. El JSON inválido muestra el problema, su línea y columna y un fragmento — además de enlaces al Formateador y al Validador JSON.

• Elemento raíz — La etiqueta superior que envuelve el documento: root, data, response, cualquier nombre XML válido. Un nombre no válido se repara y el cambio se te muestra en lugar de aplicarse en silencio.
• Nombres de los elementos de array — Una etiqueta fija para cada array, la clave de la que colgaba, o su singular — así un array books escribe elementos book, que es lo que habría escrito una persona a mano.
• Atributos y texto — Activa la convención @nombre y #text y una clave escrita @id pasa a ser un atributo XML mientras que #text pasa a ser el texto del elemento. Es el complemento exacto de la herramienta XML a JSON.
• Null, vacío y ausente — Un null de JSON puede ser un elemento vacío, un elemento xsi:nil que un esquema entiende, o nada en absoluto. Tres significados realmente distintos; la mayoría de conversores ofrece uno.
• Detalle del error — El JSON inválido muestra el mensaje, la línea y la columna y un fragmento con la posición marcada. También se informa de las claves duplicadas, porque son válidas y ambiguas.

JSON tiene seis clases de valor y XML tiene elementos, atributos y texto. La correspondencia es directa, y las únicas decisiones son las que los ajustes ponen a la vista.

• Los objetos pasan a elementos anidados — Cada clave se convierte en un elemento hijo con su nombre, en el orden en que aparecen en el origen.
• Los arrays pasan a elementos repetidos — Un array no se convierte en un elemento con una lista dentro; se convierte en el mismo elemento escrito una vez por entrada, que es como XML ha expresado siempre un valor repetido.
• Cadenas, números y booleanos pasan a texto — XML no tiene un tipo propio para ninguno, así que cada uno se escribe como contenido de texto. Con las anotaciones de tipo activadas, cada elemento lleva además type="number", type="string" o type="boolean".
• Los números se copian, no se recalculan — Salen los mismos dígitos que escribiste. Un identificador de veinte dígitos sigue exacto, -0 sigue siendo -0 y 1e-7 sigue siendo 1e-7 — nada de eso sobrevive a un paso por un valor de coma flotante.
• La raíz hay que inventarla — JSON puede tener un array o incluso una cadena suelta en el nivel superior; XML debe tener exactamente un elemento raíz. Eso es lo que nombra el ajuste de elemento raíz.

Es lo único que la mayoría de conversores de JSON a XML hace mal, y no se ve en la salida. XML no puede marcar el espacio en blanco como decorativo: cada carácter entre las etiquetas de un elemento forma parte de su valor. Así que un elemento cuyo contenido es texto no se puede sangrar sin cambiar lo que dice.

• El fallo — Escrito de forma ingenua, el array ["a","b"] se formatea como un elemento item con un salto de línea antes de la a y un salto de línea más dos espacios después. Leído por cualquier parser conforme, ese valor no es "a": es un salto de línea, una a, un salto de línea y dos espacios.
• La consecuencia — Activar el formateo cambia los datos, y la salida compacta y la sangrada del mismo conversor discrepan sobre lo que significa el documento. Nada da error y nada parece mal.
• La regla aquí — Solo se añade espacio dentro de un elemento cuando todos sus hijos son otros elementos. Un elemento con cualquier texto se escribe en una línea, con cualquier sangría. El viaje de ida y vuelta por dos parsers XML independientes forma parte del conjunto de pruebas de esta herramienta.

JSON no tiene atributos, así que un conversor necesita una convención para producirlos. Esta herramienta usa la que ya hablan las bibliotecas de XML a JSON: una clave que empieza por @ pasa a ser un atributo del elemento que la contiene, y la clave #text pasa a ser su contenido de texto. Está desactivada por defecto, porque tus datos pueden usar esas claves legítimamente.

• Qué produce — {"@id": "7", "name": "Ada"} pasa a ser un elemento con id="7" y un hijo name, en lugar de dos elementos hijos uno de los cuales se llama _id.
• Ida y vuelta — Es la convención que lee la herramienta XML a JSON de este sitio, así que un documento convertido de ida y de vuelta conserva su forma.
• Cuando un valor no puede ser atributo — Un atributo contiene texto plano. Un objeto o array bajo una clave @ se escribe como un elemento hijo normal — nunca se descarta ni se convierte en un bloque JSON dentro de tu XML — y se muestra cuántos.
• Contenido mixto — Si un elemento acaba con texto y elementos hijos, todo el elemento se escribe en una línea. Es la única forma de conservar el texto tal cual; véase la sección anterior.

Las claves JSON son cadenas arbitrarias. Los nombres de elemento XML no: deben empezar por letra o guion bajo, no pueden contener espacios ni la mayoría de signos de puntuación, y no pueden empezar por las letras xml. Algo tiene que ceder, y aquí cómo cede es un ajuste, no una decisión silenciosa.

• Reparar y mostrar la lista — "first name" pasa a first_name y "2024" pasa a _2024. Un dígito inicial se prefija en lugar de borrarse, para que 2024 y 024 no acaben con el mismo nombre. Cada cambio aparece en el panel junto a la vista previa.
• O conservar el texto original — La otra opción escribe un elemento key con name="first name", de modo que la cadena original sobrevive literalmente en el documento. Más feo, sin pérdida, y es lo que producía esta página antes del rebuild.
• Acentos y escrituras no latinas se conservan — Führung, señor y 名前 son todos nombres de elemento XML perfectamente válidos y se escriben tal cual. Los conversores que eliminan todo lo que no sea A–Z destrozan sin avisar los nombres de campo de la mayoría de exportaciones no inglesas.
• Las colisiones se separan — Si "first name" y "first-name" se reparan ambos a first_name, el segundo pasa a first_name_2 — fundirlos sería una pérdida de datos que parece un éxito. Una clave que ya era válida conserva siempre su propio nombre.
• Los emoji pasan a guion bajo, a propósito — La especificación XML los permite; los parsers reales no se ponen de acuerdo. Uno estricto rechaza de plano un documento con un emoji en un nombre de elemento y otro descarta en silencio el elemento y su contenido. Un guion bajo se lee igual en todas partes.

"Sin valor" tiene varios significados en JSON y varias grafías en XML, y elegir entre ellas es la diferencia entre un documento que un esquema puede validar y uno que no.

• Un elemento vacío — Lo predeterminado. Un null pasa a ser un elemento sin nada dentro, que es la forma que espera la mayoría de consumidores.
• xsi:nil — Escribe el elemento como nil y declara el espacio de nombres de instancia de esquema en la raíz. Es la única grafía que un consumidor puede distinguir de "el exportador olvidó este campo", y es lo que espera un XSD.
• Omitido — El elemento no se escribe en absoluto. Esto se aplica solo a los miembros de objetos: un elemento null dentro de un array sí se escribe, porque la longitud de un array es información y quitar una entrada desplaza en silencio todos los índices posteriores.
• Objetos y arrays vacíos — Ambos pasan a un elemento vacío. Un array vacío no produce una línea en blanco entre dos etiquetas, que es lo que emite un escritor ingenuo.

Todos los conversores rivales escriben item para cada array del documento, y con ello pierden la única información que el array llevaba: qué contenía. Aquí hay tres opciones, y la tercera no la ofrece nadie más.

• Una etiqueta fija — Cada elemento del array recibe la etiqueta que escribas — item por defecto. Predecible, y lo que esperará un consumidor escrito contra otro conversor.
• La clave padre — Los elementos se nombran según la clave de la que colgaba el array, de modo que un array books produce elementos books dentro de un elemento books.
• El singular de la clave padre — books produce book, categories produce category, children produce child. Es lo que habría escrito a mano una persona. Cuando la palabra no se puede acortar se usa la etiqueta fija, en lugar de anidar un nombre dentro de sí mismo.
• Un array en el nivel superior — Un array en la cima del documento no tiene clave que le dé nombre, así que se usa el nombre del elemento raíz como padre.

Los tres ajustes que deciden cómo se ve el archivo, no lo que dice. El de la codificación vale la pena leerlo: es el ajuste que más a menudo se implementa como etiqueta en lugar de como hecho.

• La declaración XML — Activada por defecto. Indica la versión y la codificación, y un consumidor que la lea se la creerá — por eso los bytes tienen que coincidir con ella.
• Sangría — Dos espacios, cuatro espacios, tabuladores o ninguna. Sin sangría el documento entero queda en una línea, que es lo que quieres cuando el consumidor es un programa y no una persona.
• UTF-8 — Lo predeterminado y casi siempre la respuesta correcta. Se escribe sin marca de orden de bytes, porque la declaración ya lo dice y esa marca rompe a los consumidores que esperan que el archivo empiece por un corchete angular.
• UTF-16 — Se escribe como bytes UTF-16 reales con marca de orden de bytes, porque un documento UTF-16 sin ella no es detectable de forma fiable y varios parsers lo rechazan.
• ISO-8859-1 — Realmente codificado como Latin-1. Cada carácter que la codificación no puede contener se escribe antes como referencia numérica de carácter, lo cual es XML válido y no pierde nada — así, un documento que dice ISO-8859-1 lo es de verdad. Un conversor que escribe la etiqueta y emite UTF-8 igualmente produce un archivo equivocado de una forma que ningún validador detecta.

Un valor JSON por línea, sin array que lo envuelva. Es lo que emiten las canalizaciones de registros, las exportaciones masivas de API y los volcados de almacén de datos, y el parser JSON estándar lo rechaza de plano — así que la mayoría de conversores no puede abrir los archivos que la gente más suele tener.

• Detectado, no activado — Suelta un archivo .jsonl o .ndjson y se reconoce. También se reconoce un .json o .txt que resulte contener un valor por línea, porque la extensión es una pista y no una promesa.
• Qué produce — Cada línea pasa a ser un elemento repetido bajo la raíz, exactamente como si las líneas hubieran sido un array. Todos los ajustes de array se aplican igual.
• Las líneas en blanco se ignoran — Un salto de línea final es universal y no es un error. Cualquier otra línea que no sea JSON válido informa de su número de línea, la única coordenada que significa algo en este formato.

JSON no tiene esquema, así que un XSD hay que inducirlo del propio documento. Este se recoge mientras se escribe el XML y no en una segunda pasada sobre el JSON, lo que significa que solo puede describir elementos que realmente se produjeron, con los nombres que realmente recibieron.

• La cardinalidad sale de los datos — Un elemento hijo ausente en cualquier instancia de su padre se marca como opcional. Uno visto más de una vez en una sola instancia se marca como ilimitado.
• Los tipos se estrechan solo con certeza — Un elemento recibe un tipo entero solo si todos los valores vistos eran enteros en el texto de origen — incluidos los demasiado largos para sobrevivir como número de coma flotante. Un solo decimal en cualquier sitio lo ensancha.
• La ambigüedad ensancha en lugar de adivinar — Un elemento visto con texto e hijos se marca como mixto; uno visto como contenedor y como valor simple queda abierto. Un esquema que rechaza el archivo del que se generó es peor que ningún esquema.
• Los espacios de nombres encajan — Solo se declara un espacio de nombres de destino cuando el documento se escribió dentro de uno, porque un esquema que declara un espacio de nombres que la instancia no usa no valida nada.

Muchos sistemas siguen hablando XML y no hablan otra cosa. Convertir permite reutilizar datos que ya tienes en JSON sin reescribir quien los produce, y suele ser el paso más barato de una integración.

• Integración empresarial y SOAP — Los servicios SOAP, las pasarelas EDI y los ERP antiguos aceptan solo XML. Una carga convertida es a menudo todo el trabajo.
• Archivos de configuración y compilación — Ant, Maven, Spring, los diseños de Android y la configuración de .NET son XML. Los datos generados como JSON tienen que llegar con esa forma.
• Validación por esquema — XML tiene XSD, que permite a un sistema receptor rechazar una carga mal formada antes de hacer nada con ella. JSON Schema existe, pero lo aplican muchos menos sistemas.
• Documentos en lugar de datos — XML maneja contenido mixto — texto con marcado dentro —, algo que JSON no puede expresar en absoluto. Por eso los formatos de publicación son XML.
• Privacidad — La conversión ocurre en tu dispositivo. Nada de la carga sale de él, lo que importa cuando la carga son registros de clientes y la alternativa es pegarlos en el servidor de otra persona.

Un archivo JSON de 9 MB se convierte en 17,8 MB de XML en unas seis décimas de segundo, sin que la página se bloquee.

• Elemento raíz — La única etiqueta superior. Debe ser un nombre XML válido; uno que no lo sea se repara y el cambio se muestra.
• Etiqueta de array — El nombre de elemento que se usa para cada entrada de un array cuando el modo de nombres es etiqueta fija.
• Nombres de los elementos de array — Etiqueta fija, clave padre o singular de la clave padre.
• Claves no válidas — Reparar la clave a un nombre XML válido, o conservar el texto original en un atributo name.
• Valores null — Un elemento vacío, xsi:nil u omitido del documento.
• Asignación de atributos — Tratar las claves @ como atributos y #text como texto del elemento.
• Anotaciones de tipo — Añade type="number", type="string" o type="boolean" a cada elemento. Pro.
• Espacio de nombres y prefijo — Una URI de espacio de nombres de destino para el documento, ligada como predeterminada o a un prefijo. Pro.
• Declaración XML — Si se escribe arriba la línea con la versión y la codificación.
• Codificación de salida — UTF-8, UTF-16 o ISO-8859-1 — declarada y realmente codificada.
• Sangría — Dos espacios, cuatro espacios, tabuladores o una línea compacta.
• Nombre de archivo — La raíz del nombre para el .xml y el .xsd descargados.

Todo lo que decide si la conversión es correcta es gratuito. El plan decide cuánto puedes pasar de una vez y si los extras vienen incluidos.

• Gratis — Un archivo cada vez, de hasta 10 MB — unos cuarenta mil registros de una exportación típica. Todos los ajustes de estructura, todos los modos de nombres, todas las políticas de null, la asignación de atributos, las cuatro sangrías y las tres codificaciones.
• Pro — Sin límite de tamaño impuesto: hasta lo que tu dispositivo pueda manejar. Hasta 50 archivos convertidos de una vez y descargados como un solo ZIP, más generación de XSD, espacios de nombres de destino y anotaciones de tipo.
• Qué recibe un archivo rechazado — El tamaño real, el límite y un enlace al minificador JSON, que es de verdad el primer paso correcto para un archivo que se pasa por unos pocos megabytes. Nunca una barra de progreso que luego falla.

• XML a JSON
• Formateador JSON
• JSON a YAML
• Herramientas JSON
• Check it parses at all

  Confirms the document is valid JSON and says where it stops being valid if not

• Flatten it into a table

  When a person with a spreadsheet is the consumer rather than a system with a schema