Convertir XML a JSON

El XML guarda información en tres sitios —nombres de elemento, atributos y texto— y el JSON solo tiene claves y valores, así que la correspondencia necesita un convenio. El de aquí es el habitual: cada elemento pasa a ser una clave cuyo valor es un objeto con sus hijos, cada atributo pasa a ser una clave de ese mismo objeto con una arroba delante, y el texto propio del elemento, cuando convive con hijos o atributos, se guarda bajo la clave #text.

Un elemento que solo lleva texto es más simple: se convierte directamente en una cadena, sin objeto que lo envuelva. Esa inconsistencia es inevitable y conviene interiorizarla pronto, porque significa que el valor que hay en una ruta concreta es a veces una cadena y a veces un objeto según si el elemento de origen llevaba un atributo o no.

Esto es lo más caro de consumir un XML convertido. Un documento XML no dice qué elementos se repiten: eso solo lo dice un esquema, y aquí no se lee ninguno. Así que un contenedor con un elemento hijo produce un objeto y el mismo contenedor con dos produce un array de objetos. La forma de tu JSON depende de cuántos datos había en el archivo.

El código escrito contra un canal RSS lleno se rompe el día que el canal tiene una sola entrada, y el código escrito contra una respuesta con un único registro se rompe la primera vez que vuelven dos. No hay ninguna opción aquí que lo arregle, porque arreglarlo exige conocer el esquema. Escribe el consumidor para aceptar las dos formas: normaliza toda colección a array como primerísima operación, antes de que ninguna otra lógica la toque.

Los valores que parecen numéricos se convierten en números JSON, tanto en atributos como en el texto de un elemento. Un elemento que contenía 08001 sale como 8001. Un identificador escrito 007 sale como 7. Un atributo de versión escrito 1.0 sale como 1.

Para una cantidad eso es cómodo y para cualquier cosa que fuera un símbolo opaco es destructivo. Los códigos postales de Barcelona, de Álava y de Alicante empiezan por cero; los números de factura y de pedido con ceros a la izquierda también; los códigos de producto, las referencias catastrales y los modos de fichero, igual. Ninguno da un error. Revisa en la salida cada valor que pensabas comparar como texto antes de escribir el código que lo lee: sale mucho más barato que descubrir por una incidencia que el pedido 007 y el 7 son el mismo pedido.

Un sobre SOAP llega con sus prefijos intactos: un elemento con prefijo se convierte en una clave que contiene literalmente el prefijo, los dos puntos y el nombre local, y las declaraciones de espacio de nombres llegan como atributos que empiezan por arroba. No se resuelve nada y no se elimina nada.

Eso es fiel y es frágil, porque un prefijo es arbitrario. Un servicio que emite un prefijo una semana y otro distinto la siguiente ha producido dos documentos equivalentes y dos estructuras JSON incompatibles. Si controlas el consumidor, empareja por el nombre local que va después de los dos puntos y nunca fijes en el código un prefijo que no hayas definido tú.

Un documento que empieza con la línea de versión y codificación produce una clave de primer nivel llamada «?xml» que lleva sus atributos, colocada al lado de la clave del elemento raíz. No forma parte del contenido del documento y está en tu JSON.

Trátala ignorándola o borrándola, pero no des por hecho que el elemento raíz es la única clave de primer nivel. El código que lee la primera clave del objeto para encontrar la raíz se encontrará con la declaración en cualquier documento que la tenga, que son casi todos. Y ni siquiera dice lo que decía el original: la versión escrita 1.0 se ha convertido en el número 1.

Los comentarios desaparecen sin dejar rastro, lo que en un mensaje de datos suele ser inofensivo y en un archivo de configuración es una pérdida real. El CDATA se desenvuelve: lo que hubiera dentro pasa a ser una cadena corriente, así que un fragmento de HTML envuelto en CDATA —la forma normal de que un canal RSS lleve el cuerpo de una entrada— sale como texto con signos de mayor y menor dentro.

El contenido mezclado es el caso sin buena respuesta. Un elemento con texto, luego un hijo y luego más texto conserva el hijo bajo su clave y concatena los dos tramos de texto en un único #text, sin ninguna marca de dónde estaba el hijo entre ellos. Cualquier documento donde la prosa y el marcado se entrelacen pierde su orden aquí, y el JSON es sencillamente el destino equivocado para él.

Un elemento autocerrado y un elemento con el cuerpo vacío producen los dos una cadena vacía. El XML tampoco distingue entre ellos, así que no se ha perdido nada; lo llamativo es que el JSON tiene disponible el valor nulo y aquí no se usa. Un elemento vacío es una cadena vacía y no un nulo.

La distinción que sí desaparece es la que hay entre un elemento ausente y uno presente y vacío, en cuanto tu código aplica un valor por defecto: los dos acaban siendo falsos. Donde esa diferencia importa —un campo opcional borrado a propósito frente a uno que nunca se rellenó— comprueba si la clave existe en lugar de mirar su valor.

En el mundo hispanohablante buena parte del XML que llega a las manos es facturación: mensajes de facturación electrónica, ficheros de suministro a la administración tributaria, respuestas firmadas de un servicio web. Todos comparten forma —muy anidados, con prefijos por todas partes y con identificadores que son texto aunque parezcan números— y aquí reciben exactamente el tratamiento descrito arriba.

Hay una advertencia concreta para ellos. La firma electrónica de un documento vale sobre los bytes del XML, no sobre este JSON: convertir produce una estructura de datos cómoda de leer y no un documento que siga demostrando nada. Usa el JSON para inspeccionar, para escribir pruebas y para programar contra él, y conserva el XML firmado como el ejemplar que vale.

Puesto todo junto, una respuesta SOAP se lee como claves anidadas: la del sobre, dentro la del cuerpo, después la de la respuesta de la operación y por fin la carga útil. Cada nivel conserva su prefijo y todo está a tres o cuatro objetos de profundidad antes de que aparezca ningún dato tuyo, que es exactamente lo verboso que era el XML y mucho más cómodo de recorrer desde el código.

El caso que hay que probar primero es un error. Un fallo SOAP usa una estructura de elementos distinta de la de una respuesta correcta, así que su JSON no se parece en nada al de un resultado, y un cliente que solo haya visto el camino feliz leerá un valor indefinido en una ruta que ya no existe. Convierte aquí una respuesta de error real y escribe la rama de error contra ella antes de necesitarla.

El JSON se escribe con sangría de dos espacios, así que se lee bien en una revisión y se pega tal cual en una prueba. Ése es precisamente su mejor uso: convertir una respuesta real y guardarla en el repositorio le da al consumidor algo honesto contra lo que probarse, con todas las incomodidades de esta página incluidas.

Es mejor que un fichero de ejemplo escrito a mano por dos motivos. El primero es que un ejemplo inventado nunca tiene el caso raro. El segundo es que este JSON tiene exactamente la forma que va a tener en producción, incluidos el prefijo dentro de la clave, la clave ?xml y el identificador convertido en número, que son tres cosas que nadie escribe a mano en un ejemplo.

El orden de las claves se conserva, y eso es más de lo que la gente supone. Lo que no vuelve son los comentarios, la distinción entre atributo y elemento hijo más allá de una arroba dentro de una cadena, el significado de los espacios de nombres y cualquier posibilidad de validación, porque el JSON no trae esquema en el archivo.

Es el resumen honesto de la dirección: el XML lleva desde 1998 acompañado de esquemas, rutas de consulta, transformaciones y firmas; el JSON no tiene nada de eso dentro del propio documento. Convertir en este sentido lo deja atrás, y no hay camino de vuelta que lo reconstruya, así que el XML original merece seguir en el control de versiones pase lo que pase con el JSON.

Normaliza a array cualquier cosa que pueda repetirse. Compara los identificadores como texto y devuélvelos a texto en la frontera si el analizador los convirtió en números. Y empareja las claves con espacio de nombres por su parte local. Con esas tres, la conversión es predecible y todo lo demás que hace deja de sorprender.

El analizador y el serializador funcionan los dos dentro de esta página, así que un registro de clientes, un fichero fiscal o una respuesta firmada se quedan en tu máquina. El límite gratuito es de 100 MB por archivo y se pueden soltar hasta cien de una vez; como no hay servidor implicado, tampoco hay cupo diario que gastar ni cola en la que esperar.