Convertir TSV a JSON

Las herramientas eligen el tabulador cuando sus datos están llenos de comas y no quieren entrecomillar. Los clientes de base de datos imprimen los resultados así. Los ficheros de anotación de secuencias y las tablas de expresión génica lo usan por convención. Las consolas de analítica y las plataformas de publicidad lo exportan así porque los nombres de campaña y los títulos de página están llenos de signos de puntuación.

Esa elección compra fiabilidad frente a la coma y renuncia a casi todo lo demás. El fichero no tiene tipos, no tiene anidamiento, no puede marcar una columna como identificador y no tiene ninguna defensa contra un tabulador dentro de un valor. Es un buen formato de transporte y un mal formato para calcular, que es exactamente por lo que lo primero que hace todo el mundo con uno es convertirlo.

La fila de cabecera aporta las claves y cada fila siguiente se convierte en un objeto. El resultado es un array JSON, que es la forma que dan por supuesta un script, un cuaderno de análisis y prácticamente cualquier biblioteca cuando dicen «los datos».

No se envuelve en nada ni se indexa por ninguna columna de identificador, porque para hacerlo habría que saber cuál de las columnas es el identificador y esa no es una decisión que pueda tomar un conversor. Un array es lo que menos supone, y convertirlo en un diccionario por el campo que quieras es una línea en el lenguaje que ya estés escribiendo.

Un fichero separado por tabuladores no tiene forma acordada de escapar un tabulador dentro de un campo, y un salto de línea dentro de uno es todavía peor: la fila termina justo donde el valor debía continuar. Las dos cosas pasan en la práctica, casi siempre en una columna de observaciones o de descripción donde alguien pegó algo.

En JSON son caracteres corrientes. El tabulador se escribe como una secuencia de escape dentro de la cadena y el salto de línea igual, y ninguno de los dos puede afectar a la estructura del documento, porque la estructura la expresan las llaves y los corchetes y no los caracteres del dato. Es la razón más sólida para convertir un fichero desordenado antes de seguir procesándolo como texto, y conviene hacerlo antes y no después de que una tubería haya producido una respuesta verosímil y equivocada.

Una cabecera que ponga «Importe total» pasa a ser la clave «Importe total», con el espacio incluido, y una que lleve tildes o paréntesis los conserva. Nada se renombra, ni se pasa a minúsculas, ni se transforma, porque un conversor que reescribiera en silencio los nombres de columna haría imposible cuadrar la salida con el origen.

Eso tiene consecuencias donde vayas a usarlo: en la mayoría de los lenguajes tendrás que acceder al campo con corchetes y comillas en vez de con un punto. Si el JSON va a acabar en código que alguien mantendrá, renombrar las claves una vez —en la fila de cabecera, antes de convertir— compensa. Y vigila dos columnas con el mismo encabezado: el analizador no deja que una pise a la otra, así que a la repetida le añade un sufijo numérico —una segunda «Importe» se convierte en la clave «Importe_1»— y las dos sobreviven como campos distintos. No se pierde ningún dato, pero la clave que ves en el JSON ya no es el nombre que había en la hoja, así que arregla la cabecera antes de convertir si el destino es código que da por hecho un nombre concreto.

JSON distingue el 7 del «7» y una tabla delimitada no, así que el analizador deduce. Lo que parece número se convierte en número, las palabras true y false en booleanos, y lo demás se queda como cadena. Para cantidades, recuentos y puntuaciones es justo lo que quieres y te ahorra una pasada de conversión al otro lado.

Para identificadores es destrucción. Un código postal escrito 08001 llega al JSON como el número 8001, y una referencia con ceros delante pierde el relleno sin que nada avise. La regla práctica es preguntarse si sumar dos valores de esa columna significaría algo: si no significa nada, la columna era un identificador y quería seguir siendo texto. Revisa esas columnas en la salida antes de construir nada encima.

Este es el caso que aparece constantemente en datos publicados en español y casi nunca en la documentación en inglés. La inferencia reconoce números escritos con punto decimal; un valor escrito 12,5 no encaja en ese molde y se queda tal cual, como cadena.

El resultado es un JSON perfectamente válido en el que una columna que tú considerabas numérica llega entre comillas, y cualquier suma posterior falla o concatena. Compruébalo siempre en las primeras filas de la salida. Si la columna viene con coma decimal, hay que decidir conscientemente si se reemplaza en el origen o se convierte en el destino, pero no conviene descubrirlo por un total absurdo tres pasos más adelante.

Un espacio entre dos tabuladores se escribe como null. Merece la pena decirlo claramente, porque cualquier cosa que consuma el JSON tratará null y cadena vacía de forma distinta: un esquema que declare una cadena rechazará el nulo, y una comprobación de tipos los separará aunque una comprobación de verdad o falsedad no lo haga.

El origen no puede decirte cuál de los dos se quería decir. Un fichero delimitado tiene una sola manera de escribir «aquí no hay nada» y la usa tanto para un valor en blanco como para un campo que no aplica. Si esa distinción importa, tenía que existir en el fichero antes de la conversión, como una marca convenida o como una segunda columna.

Las claves salen de la cabecera y todas las filas posteriores se cotejan con ella, así que una tabla en la que aparece una columna nueva a partir de la fila diez mil no gana una clave por ello. Los valores sobrantes caen juntos en un campo aparte, como lista, solo en los registros que los traen. Las filas a las que les falta un campo simplemente no llevan esa clave.

Esto es más frecuente de lo que debería en exportaciones montadas a partir de varias ejecuciones, y es el fallo que peor lleva un lector posicional: un troceador ingenuo desplaza todos los valores posteriores a la columna que falta y produce filas que parecen correctas y no lo son. Teniendo los datos como objetos, la irregularidad se ve: basta pedir las claves de unos cuantos registros para comprobar que la forma no es uniforme.

La conversión suele ser el primer paso para leer un fichero que nadie documentó, y en JSON eso se hace deprisa. Contar la longitud del array da el número de filas sin que la cabecera confunda. Pedir las claves del primer elemento enumera las columnas tal y como las vio el analizador. Y sacar los valores distintos de una columna es la forma de encontrar la marca especial que está estropeando en silencio un campo numérico.

Esa última consulta merece la pena en cualquier columna que esperabas numérica y ha llegado como texto. La causa suele ser un puñado de filas con «ND», un guion o una llamada a pie de página, y saber qué marca usó la fuente vale más que cualquier suposición sobre el esquema. También es bastante más rápido que abrir un fichero grande en una hoja de cálculo, que además aplicaría sus propias conversiones al entrar.

Cuenta con que el fichero crezca. Cada registro repite todas las claves, todas las cadenas van entrecomilladas y a los valores se les añade la puntuación del objeto. En una tabla ancha con encabezados largos y valores cortos, el JSON puede ser varias veces el original.

Es un precio justo para un fichero contra el que vas a calcular y malo para uno que solo necesitas guardar. La salida además va con sangría de dos espacios, lo que la hace legible en un editor y suma bytes. Si el destino es almacenamiento o una carga por flujo en lugar de un script, NDJSON o Parquet son mejores objetivos y salen de la misma tabla.

El análisis y la escritura son JavaScript corriente cargado por esta página, así que no se sube nada, no hay cola y no hay cuenta. Importa por el tipo de fichero que suele ser este: una tabla de referencia todavía embargada, un extracto de clientes, un conjunto de resultados sin publicar.

El array se construye entero antes de escribirse, de modo que el techo es la memoria. Decenas de megabytes son rutina y a partir de cierto punto la pestaña se resiente; a ese tamaño, además, un único array JSON es incómodo de manejar, porque casi todos los analizadores insisten en sostenerlo completo. NDJSON es la forma que escala más allá de ese punto y sale del mismo origen.