Convertidor XML a JSON

1. 1

   Añade tu XML

   Pega el marcado en el editor o suelta un archivo sobre la página. Se aceptan XML, SVG, RSS, Atom, WSDL, XSD, KML, GPX, plist y OPML, y la codificación se detecta desde la marca de orden de bytes o desde la declaración XML.

2. 2

   Elige una forma de salida

   Compacta es la forma habitual que produce la mayoría de herramientas. BadgerFish y GData son las dos convenciones que usan APIs veteranas. Parker da los valores más planos posibles. JsonML conserva el orden del documento y permite volver al XML original.

3. 3

   Ajusta cómo se leen los valores

   Decide si se conservan los atributos y con qué prefijo, si un elemento único pasa a ser un array de un elemento, en qué se convierte un elemento vacío y si se infieren números y booleanos en lugar de dejarlos como texto. La vista previa se actualiza con cada cambio.

4. 4

   Convierte y descarga o copia

   Pulsa Convertir para escribir el archivo. Elige 2 espacios, 4 espacios, tabulaciones o salida minificada, y descarga el .json o cópialo. Con Pro puedes convertir hasta 50 archivos a la vez y llevártelos en un único ZIP.

La mayoría de conversores de XML a JSON toman una decisión silenciosa por ti y no te dan forma de cambiarla: eligen una forma, descartan tus atributos y devuelven un JSON que parece correcto. Este pregunta. Tú eliges la convención de salida, si los atributos sobreviven y con qué prefijo, si un elemento único es un valor o un array de un elemento, qué significa un elemento vacío y qué ocurre con los prefijos de espacio de nombres, y la vista previa junto a los controles muestra la respuesta mientras cambias cada uno.

• No se descarta nada — Atributos, secciones CDATA, texto mixto e instrucciones de procesamiento sobreviven a la conversión. Cada uno tiene su control, así que decides qué conservar en lugar de descubrir después qué se perdió.
• Cinco formas de salida — Compacta, BadgerFish, GData, Parker y JsonML. Cuatro son las convenciones que usan APIs reales; JsonML es la que conserva el orden del documento y permite volver atrás exactamente.
• Errores accionables — Un análisis fallido da la línea, la columna, la línea de origen y un cursor bajo el carácter culpable, con un mensaje que nombra el fallo en lugar de repetir que el archivo no es válido.
• Archivos grandes sin tirones — La lectura y la escritura ocurren fuera de la interfaz, así que la página nunca se congela. Un documento de 25 MB se convierte en alrededor de un segundo con barra de progreso y un Cancelar que funciona.

No hay una única manera correcta de representar XML como JSON, por eso existen varias convenciones y por eso las bibliotecas serias te dejan elegir. XML tiene atributos, hijos ordenados, texto mixto y espacios de nombres; JSON tiene objetos, arrays y cadenas. Cada mapeo sacrifica algo de lo anterior. Elegir el sacrificio adecuado para lo que vas a hacer después es casi todo el trabajo.

• Compacta — la predeterminada — Los elementos pasan a claves, los atributos llevan el prefijo @_ y el texto va bajo #text. Es la forma que producen la mayoría de herramientas y tutoriales, así que le resultará familiar a quien lea el archivo después. Elígela salvo que tengas un motivo para no hacerlo.
• BadgerFish — uniforme — Cada elemento es un objeto, el texto siempre va bajo $, los atributos bajo @nombre y las declaraciones de espacio de nombres bajo @xmlns. Nada es nunca una cadena suelta, así que el código que la consume no tiene que comprobar si un campo llegó como objeto o como valor. Verbosa y predecible a cambio.
• GData — la forma de Google — Los atributos pasan a claves normales junto a los elementos hijos y el texto va bajo $t. Compacta de leer y la elección correcta cuando estás ajustándote a una forma existente de Google Data o Atom.
• Parker — la más plana — Los atributos se descartan, el nombre del elemento raíz desaparece y las hojas se convierten en sus valores. El resultado es lo más parecido a lo que habrías escrito a mano si hubieras empezado en JSON. Úsala para configuración y datos simples donde los atributos no aportan nada que necesites.
• JsonML — sin pérdidas — Cada elemento pasa a ser un array con su nombre de etiqueta, sus atributos y sus hijos en orden de documento. Es la única forma aquí que sobrevive a un viaje de ida y vuelta, y la única que puede representar un elemento, luego otro distinto, y luego el primero otra vez.

Un elemento XML lleva tres cosas distintas a la vez — sus atributos, su texto y sus elementos hijos — y un objeto JSON tiene un único espacio de claves para las tres. Cada convención resuelve esa colisión de forma diferente, y la colisión es real: un elemento con un atributo llamado nombre y un elemento hijo llamado nombre necesita que ambos sobrevivan.

• El prefijo de atributo — @_ por defecto, y configurable. Su única función es evitar que la clave de un atributo choque con un elemento hijo del mismo nombre, así que sirve cualquier prefijo que no aparezca en tus nombres de etiqueta. Déjalo vacío si sabes que no hay colisiones y quieres la salida más plana.
• La clave de texto — #text por defecto. Se usa cuando un elemento tiene texto y además algo más: atributos, elementos hijos o ambos. Un elemento que solo tiene texto se escribe directamente como ese texto, así que los documentos simples siguen siendo simples.
• Contenido mixto — Un párrafo que contiene una parte en negrita tiene texto antes, dentro y después de sus hijos. Ese texto se recoge bajo la clave de texto en lugar de descartarse, lo que significa que un documento que describirías como prosa y no como datos sigue convirtiéndose en algo legible.
• Espacios en blanco — El texto se recorta por defecto, porque la sangría de un XML formateado es presentación y no datos. Colapsar reduce cada secuencia de espacios a uno solo; Mantener conserva el texto exactamente como se escribió, que es lo que quieres para cualquier cosa cuyo formato importe, como código incrustado.

La sorpresa más frecuente al convertir XML a JSON es que la forma de la salida depende del número de registros de la entrada. Un pedido en el archivo te da un objeto; dos te dan un array. El código escrito contra una muestra con dos pedidos se rompe el día que un cliente envía uno, y el fallo parece un problema de datos y no un mapeo ambiguo.

• Cuando se repite (predeterminado) — Una etiqueta que aparece varias veces como hermana pasa a array, conservando orden y cantidad. Una etiqueta que aparece una vez sigue siendo un valor único. Es lo que hace casi cualquier conversor y es la salida más legible.
• Siempre — Cada elemento que podría repetirse pasa a ser un array, incluso con una sola aparición. La salida es algo más verbosa y completamente predecible, que es lo que quieres cuando el JSON va directo a código en lugar de leerlo una persona.
• Orden entre etiquetas distintas — Los arrays conservan el orden de los hermanos con el mismo nombre, pero ninguna forma indexada por clave puede conservar el de los distintos: las claves de un objeto no llevan secuencia. Si el intercalado importa, JsonML es la forma que lo conserva.

Los espacios de nombres son la razón de que el XML empresarial tenga el aspecto que tiene, y son donde un conversor ingenuo produce en silencio algo incorrecto. Un prefijo como soap: no forma parte del nombre del elemento: es un puntero a una URI declarada más arriba, y el mismo prefijo puede significar cosas distintas en partes distintas de un mismo documento.

• Conservar — Los prefijos quedan exactamente como se escribieron, así que soap:Envelope sigue siendo soap:Envelope y el JSON coincide con el documento que estás mirando. Es el valor correcto por defecto para respuestas SOAP y para WSDL, donde los prefijos son a lo que todo el mundo se refiere.
• Eliminar — Los prefijos se quitan para una forma más limpia y corta. Dos elementos de espacios de nombres distintos pueden caer entonces en la misma clave, lo que es pérdida real de información, así que cuando ocurre la herramienta cuenta las colisiones y te lo dice en vez de dejar pasar la fusión en silencio.
• Expandir — Cada prefijo se sustituye por su URI completa entre llaves. Nada queda ambiguo y nada puede colisionar, a costa de claves largas. Es la forma que hay que elegir cuando el JSON se va a validar o comparar en lugar de leer.
• Atributos sin prefijo — Un atributo sin prefijo no está en ningún espacio de nombres: no hereda el espacio predeterminado del elemento. Es una regla que los conversores se saltan habitualmente, y saltársela inventa un espacio de nombres que el documento nunca declaró.

XML no tiene tipos. Cada valor de un documento es texto, y cualquier conversor que te devuelva un número ha decidido por ti que el texto parecía lo bastante numérico. Esa decisión es útil a menudo y destructiva de vez en cuando, por eso aquí es un control y por eso está desactivada hasta que la enciendes.

• Qué se convierte — Enteros y decimales simples, true, false y null. Nada más.
• Qué no se convierte a propósito — Un valor con ceros a la izquierda sigue siendo texto, porque un número de pedido escrito 007 no es 7. Un signo más inicial sigue siendo texto, porque un prefijo telefónico no es un número. Un valor fuera del rango de enteros seguros sigue siendo texto, porque convertirlo cambiaría los dígitos en silencio. Igual que la notación exponencial o hexadecimal, e igual que Infinity y NaN, que una conversión numérica ingenua acepta y que ningún documento XML quiere decir.
• La regla del viaje de ida y vuelta — Un valor solo pasa a número si al escribir ese número de vuelta se obtienen exactamente los caracteres que había en el archivo. Eso es lo que protege a 1.0, que la mayoría de conversores transforman en 1 y devuelven como si no hubiera pasado nada.
• Elementos vacíos — Un elemento vacío puede ser razonablemente una cadena vacía, un null o un objeto vacío, y cuál es el correcto depende de lo que vayas a hacer después. En lugar de elegir por ti es un control, para poder distinguir un campo anulable de uno realmente en blanco.

El XML roto es el caso normal, no la excepción, y suele estarlo por una de unas seis razones. Un conversor que responde con la palabra Inválido no te ha dicho nada que no supieras; lo que necesitas es el carácter que lo provocó.

• La línea, la columna y un cursor — Todo fallo informa de dónde ocurrió, muestra la línea de origen y coloca un cursor bajo el carácter exacto. Los documentos largos de una sola línea se recortan alrededor del fallo para que un archivo minificado no se imprima entero en el cuadro de error.
• Un ampersand sin escapar — El fallo más común del XML escrito a mano. Un & suelto en Q&A o en la cadena de consulta de una URL no es marcado válido y debe escribirse &. El mensaje lo dice, en lugar de informar de un error de entidad incomprensible.
• Etiquetas que no coinciden — Una etiqueta de apertura cerrada con otro nombre, o una etiqueta que queda abierta al final del archivo. Ambos nombran la etiqueta implicada, y el caso sin cerrar apunta a donde se abrió el elemento y no al final del documento.
• Espacios de nombres y duplicados — Un prefijo usado sin declarar, o el mismo atributo escrito dos veces en un elemento. Ambos son errores y no fusiones silenciosas, porque quedarse con uno de dos valores sin decirlo mete en tu salida datos que nadie escribió.
• Entidades y DTD — Un DOCTYPE se analiza y se omite, no se sigue. Las entidades declaradas se reconocen por su nombre pero nunca se expanden, así que una referencia a una se informa con claridad en lugar de sustituirse, que es también lo que hace imposible aquí el clásico ataque de expansión de entidades.

Todo lo de abajo es XML, y cada uno era un archivo que la versión anterior de esta página te dejaba elegir para después no hacer nada con él, porque solo reconocía la extensión .xml mientras que el sistema operativo no informa de ningún tipo para la mayoría de los demás.

• Feeds y sindicación — RSS y Atom, incluidos los conjuntos de item y entry que dan la salida delimitada por líneas más útil. OPML para listas de suscripciones.
• Servicios web — Definiciones de servicio WSDL y esquemas XSD, ambos cargados de espacios de nombres y la razón de que Conservar sea la política predeterminada.
• Gráficos y geografía — Documentos SVG, donde convertir a JSON es como un script de compilación lee un path o un viewBox. KML y GPX para datos de mapas y rutas grabadas.
• Configuración y documentos — Listas de propiedades plist de Apple, archivos .config y .csproj, archivos POM de Maven, hojas de estilo XSLT y XHTML.

El documento se lee y se escribe fuera de la interfaz, así que la página sigue respondiendo mientras se convierte un archivo grande, con progreso real y un botón Cancelar que surte efecto de inmediato.

• Forma de salida — Compacta, BadgerFish, GData, Parker o JsonML. Cambia toda la estructura; la vista previa se actualiza al instante.
• Atributos — Consérvalos o descártalos, y define el prefijo de sus claves. Se ignora en Parker, que descarta atributos por definición.
• Clave de texto — La clave que contiene el texto propio de un elemento cuando además tiene atributos o hijos.
• Arrays — Solo elementos repetidos, o forzar array para cada elemento repetible.
• Espacios de nombres — Conservar el prefijo, eliminarlo o expandirlo a la URI completa.
• Tipos — Dejar cada valor como texto, o inferir números, booleanos y null aplicando la regla del viaje de ida y vuelta.
• Elementos vacíos — Una cadena vacía, un null o un objeto vacío.
• Espacios en blanco — Recortar, colapsar secuencias a un espacio, o conservar el texto tal cual.
• CDATA — Fusionar con el texto del elemento, o mantenerlo bajo su propia clave.
• Comentarios e instrucciones — Se descartan por defecto; conserva cualquiera de los dos cuando los necesites, algo que solo las formas que preservan el orden pueden expresar por completo.
• Sangría — 2 espacios, 4 espacios, tabulaciones o minificado en una sola línea.
• Codificación — Se detecta desde la marca de orden de bytes o desde la declaración XML, y se puede forzar cuando un archivo declara la equivocada.

En XML sigue viviendo muchísimo dato real — extractos bancarios, feeds oficiales, servicios SOAP, archivos de compilación, exportaciones de mapas y todos los feeds RSS jamás publicados — mientras que casi todo lo que se construye hoy para consumir datos espera JSON. Convertir suele ser el camino más corto entre ambos, y solo sigue siendo corto si la conversión no pierde nada por el camino.

• Servicios heredados hacia código moderno — Una respuesta SOAP pasa a ser algo que una llamada fetch puede leer sin una biblioteca XML en el bundle.
• Feeds hacia pipelines — Un feed RSS o Atom pasa a ser un conjunto de registros, y con la salida delimitada por líneas pasa a ser algo que una herramienta de datos puede procesar en flujo.
• Configuración hacia herramientas — Un plist, un POM o un archivo .config pasa a ser legible para un script que no tiene analizador XML.
• Inspección — Un documento muy anidado se lee mejor como JSON en un editor que lo pliega, que a menudo es la verdadera razón para convertir.
• Sigue siendo privado — Los extractos bancarios y las respuestas de servicios son justo los documentos que nadie debería pegar en una web que los sube. Esta no los sube.

• JSON a XML
• Formateador JSON
• Validador JSON
• Visor JSON
• YAML a JSON
• Minificador JSON