Convertir NDJSON a YAML

El registro estructurado mete documentos enteros dentro de un solo campo. Una traza de error, una consulta SQL ya compuesta, el cuerpo de una petición, la diferencia de una aserción: cada una es texto con saltos de línea dentro, y JSON tiene exactamente una forma de guardar un salto de línea, que es escribir dos caracteres. Una traza de cuarenta llamadas llega, por tanto, como una sola línea de varios miles de caracteres.

YAML tiene otra opción y esta conversión la usa. Cualquier cadena que contenga un salto de línea se escribe como bloque: la clave, la barra vertical y luego las líneas de verdad, sangradas debajo. La traza se lee como una traza. El valor no cambia en absoluto —entran y salen los mismos caracteres—, pero el archivo deja de estorbar, y para una exportación que vas a leer en vez de cargar, ese es el argumento entero.

Quien conoce YAML esperaría razonablemente que un origen delimitado por líneas produjera un flujo de varios documentos, con tres guiones entre uno y otro. No es lo que sale. El archivo entero se convierte en un solo documento que contiene una secuencia, con cada registro introducido por un guion y sus campos sangrados debajo.

Esa elección tiene una consecuencia útil. Este sitio se niega a leer un flujo YAML de varios documentos —esa conversión se detiene en lugar de elegir uno—, así que la forma de documento único es la que va y vuelve. Y también significa que la salida es un único valor, que es lo que espera un cargador de YAML dentro de un script: te devuelve una lista y no un generador que hay que acordarse de recorrer.

Aquí está la trampa que un lector en español se encuentra y un lector en inglés casi nunca. El archivo se escribe según YAML 1.2, donde los únicos booleanos son true y false; bajo esa regla, NO y SI son cadenas corrientes y se escriben sin comillas, que es lo correcto. Cárgalo con PyYAML, con Psych de Ruby o con alguno de los cargadores antiguos de Go, que implementan YAML 1.1, y NO se convierte en falso mientras SI sigue siendo texto.

La asimetría es lo peligroso. Una columna de respuestas SI/NO no se rompe entera —se rompe la mitad—, así que el archivo cargado sigue pareciendo plausible y ya no se puede contar. Lo mismo le pasa a una N suelta, a un ON y a un OFF. Si el YAML va a un analizador de 1.1, entrecomilla esa columna antes de cargarla o quédate con el JSON, que no tiene esta ambigüedad en ninguna parte.

Un escalar sin comillas lo resuelve el analizador, así que un escritor tiene que entrecomillar todo aquello cuya forma desnuda volvería como otro tipo. Este entrecomilla los casos que importan en datos exportados: una cadena de solo cifras, un valor que empieza por almohadilla o asterisco, uno que contiene dos puntos seguidos de espacio y cualquiera con espacios al principio o al final. Una referencia guardada como «00412» sale entrecomillada y conserva sus ceros a la izquierda.

Eso es el escritor siendo cuidadoso, no el formato siendo seguro, y la diferencia importa en cuanto alguien edita el archivo. Quita las comillas de «00412» y la próxima vez que se cargue será el número 412. Si el YAML se va a editar a mano y luego lo va a leer un programa, esas comillas son estructura y no adorno.

Los demás destinos habituales de una exportación por líneas aplanan. CSV, TSV, XLSX, SQL y Parquet convierten un objeto anidado en columnas con nombres separados por puntos y reconcilian los registros contra un único juego de columnas. Aquí no ocurre nada de eso.

Un registro con un bloque de contexto de cuatro niveles llega con sus cuatro niveles, sangrado. Las listas se convierten en listas con guion. Los registros que llevan campos distintos siguen llevando campos distintos: no hay unión de claves, ni celdas vacías, ni tabla dispersa. Para leer una exportación cuya parte interesante es una rama, eso es exactamente lo que quieres, y es la razón de que este destino esté catalogado sin pérdida mientras los tabulares no lo están.

Una cadena sin saltos de línea pero muy larga —un agente de usuario, una URL con una cadena de consulta interminable, un mensaje de error de una sola línea— se dobla alrededor de la columna ochenta sobre líneas de continuación sangradas bajo la clave. YAML trata los saltos de un escalar plano doblado como espacios, así que el valor no cambia al volver a leerlo.

Sí significa que una URL puede aparecer partida en dos líneas dentro del archivo, cosa que desconcierta la primera vez y no es un daño. Si necesitas copiar un valor así, cógelo de la estructura cargada y no del texto, o convierte a JSON, donde cada valor se queda en la línea en la que empezó.

Ninguno. Un archivo YAML mantenido por una persona se gana el formato precisamente por las líneas con almohadilla que explican por qué un valor es el que es, y una exportación convertida no tiene ninguna, porque el origen no tenía dónde guardarlas. Lo que sale es YAML bien formado y sin una sola anotación.

Para un archivo que vas a leer una vez y borrar, eso está bien. Para uno que vas a subir a un repositorio, no: quien lo abra dentro de seis meses encontrará registros sin procedencia, sin nota de qué sistema los produjo, cuándo se extrajeron ni qué filtro se aplicó. Tres líneas de comentario en la cabecera no cuestan nada y son toda la diferencia entre un archivo de datos y un misterio.

Las líneas vacías se saltan, incluido el salto final que casi todo escritor deja al terminar, así que el número de entradas de la lista es el número de líneas no vacías del origen. Una línea que no sea JSON válido detiene la conversión con su número en el mensaje, en lugar de descartarse.

En una exportación de fallos ese comportamiento se gana el sueldo. La última línea de un registro escrito por un proceso que se cayó está muy a menudo a medio escribir, y un conversor que la saltara en silencio te entregaría un archivo que se lee como completo y al que le falta justo el registro que buscabas. Con el número de línea puedes decidir si merece la pena rescatar la cola antes de sacar conclusiones del resto.

El tope gratuito es de 100 MB y el archivo se analiza entero en memoria antes de escribir nada, así que el límite práctico es la pestaña y no un cupo. Decenas de megabytes se convierten sin protestar.

El límite sensato es más bajo que el técnico, porque el sentido de este destino es leer, y nadie lee treinta mil registros. Filtra primero: una línea de jq que se quede con los registros de nivel error tarda un segundo y te deja los cuarenta que de verdad querías, que es un YAML que se puede recorrer y razonar. Convertir la exportación completa produce un archivo legible en teoría y no leído en la práctica.

La conversión ocurre en esta pestaña, con JavaScript corriente. No se sube nada, no hay motor que descargar ni cuenta que crear, y la forma de confirmarlo es la pestaña de red durante una conversión, no este párrafo.

Aquí pesa más que en otros pares. Los archivos que la gente convierte por esta ruta son volcados de errores e informes de incidencias, y esos llevan lo que estaba en vuelo cuando algo se rompió: rutas de petición, identificadores de sesión, direcciones de correo de usuarios reales y de vez en cuando un token en una cadena de consulta que nunca debió registrarse. Es la categoría exacta que nadie debería pegar en un servicio web, y aquí no hay nada que pegar.