Convertir XLSX a TSV

Quien busca este formato casi nunca lo hace por gusto: lo hace porque el CSV le ha dado un disgusto. Las direcciones llevan comas, las descripciones de producto llevan comas y, en español, los decimales llevan coma. En un fichero separado por comas cada uno de esos valores hay que entrecomillarlo, y cada programa que lo lea tiene que implementar bien el entrecomillado para volver a encontrar los límites de columna.

Con tabuladores esa competencia entre separador y contenido desaparece. Una celda que diga «Tornillo, pequeño» se escribe tal cual, sin una sola comilla en la línea. Nada tiene que analizar el fichero; basta con partirlo. Esa es toda la diferencia de fiabilidad entre los dos separadores y la razón de que una orden de una línea baste para tratar un TSV.

Hay un motivo adicional muy concreto en un equipo configurado en español. Como la coma está ocupada por los decimales, el separador de listas del sistema es el punto y coma, así que lo que Excel guarda como «CSV» a menudo no está separado por comas. El resultado es un fichero que otra herramienta abre con todas las columnas metidas en una sola.

Convertir a TSV rodea esa discusión entera. El separador es el tabulador pase lo que pase, sin depender de la configuración regional del equipo donde se generó el fichero ni de la del equipo donde se va a leer. Para intercambiar datos entre un Excel español y una herramienta que no sabe nada de configuraciones regionales, es la salida más previsible.

De vez en cuando hay tabuladores dentro de las celdas, normalmente pegados desde otro sitio. Cuando ocurre, esa celda se escribe entre comillas dobles, porque la alternativa sería una fila que gana una columna en silencio.

Es la salida correcta y un analizador completo la entiende, pero las herramientas de línea de órdenes para las que se elige este formato no: cuentan tabuladores y no saben nada de comillas, así que a partir de esa fila ven un campo de más. Si una tubería está desalineando unas pocas filas, esta es casi siempre la causa. Búscalos y quítalos en la hoja de origen en lugar de parchear después. Lo mismo ocurre con un salto de línea dentro de una celda, muy común en columnas de observaciones o de dirección.

Un libro puede tener treinta pestañas. Un fichero separado por tabuladores contiene una tabla con una fila de cabecera y no tiene sintaxis para nada más, así que se convierte la primera hoja y se dejan las demás. Es el único comportamiento que no puede producir en silencio una mezcla que nadie pidió.

Conviene saber cuál es realmente la primera, porque no siempre es la que aparece al abrir: un libro recuerda qué pestaña estaba activa al guardarse. Si la que quieres no está en primer lugar, muévela y vuelve a convertir. Si necesitas varias, convierte varias veces y guarda ficheros separados, que además es lo que quiere una tubería: unir dos ficheros por una clave es una orden, y separar dos tablas concatenadas no lo es.

Del .xlsx se leen los valores de la primera hoja y nada más. No pasan las fórmulas, de las que llega solo el resultado que quedó guardado; ni los formatos numéricos, ni las celdas combinadas, ni los gráficos ni las imágenes, ni las anchuras y alturas, ni los estilos, ni las validaciones de datos, ni los comentarios, ni las tablas dinámicas.

Dicho de otro modo: el fichero de salida contiene lo que la hoja sabía, no lo que la hoja enseñaba. Para una tubería de texto eso es exactamente lo deseable, y por eso conviene no usar este destino como copia de seguridad de un libro de trabajo.

Una hoja guarda por un lado el dato y por otro el formato con el que lo muestra. El conversor lee lo que hay guardado y no reformatea nada, así que una columna de fechas puede llegar al TSV con un aspecto distinto del que tenía en pantalla.

No es un fallo y no hay que arreglarlo aquí: hay que mirarlo. Abre el fichero generado, busca la columna de fechas y decide qué hacer con ella en el sitio al que va, que es donde hay contexto para interpretarla. Reformatear la hoja antes de convertir suele cambiar un problema de aritmética por uno de análisis de texto, que es peor.

Los nombres de columna salen de la fila de cabecera, y el conjunto de columnas es la unión de todo lo que aparece en la hoja, no solo lo que trae la primera fila. Un bloque de filas que empieza a traer un campo adicional a mitad del fichero también aparece en la cabecera.

Las celdas vacías se escriben como campos vacíos en lugar de omitirse, así que todas las líneas tienen el mismo número de tabuladores y el fichero se mantiene rectangular. Eso es justo lo que necesita una herramienta que trabaja por posición. Y significa también que un campo vacío es ambiguo entre «en blanco» y «no aplica», algo que ningún formato delimitado ha sabido expresar nunca.

Un código guardado como texto en el libro sale intacto: un código postal que empiece por cero, una referencia rellena con ceros o un número de cuenta conservan su forma. Merece la pena decirlo porque lo contrario es tremendamente frecuente cuando un CSV pasa por Excel y vuelve a guardarse.

Lo que no se puede arreglar aquí es el daño anterior. Si el propio libro ya guarda 1001 donde debería poner 01001, el TSV pondrá 1001. Mira la alineación de la columna en la hoja antes de convertir: el texto se pega a la izquierda y los números a la derecha, y una columna con la mitad de los valores a cada lado es el peor escenario posible.

Las líneas se separan con un salto simple, no con el par de retorno y salto, y el texto se escribe en UTF-8. Es lo que esperan una tubería de Unix, un control de versiones y la mayoría de los importadores modernos.

Para un fichero en español la codificación es la parte que más disgustos evita: las tildes, la eñe y los símbolos de moneda salen tal cual y no como parejas de caracteres extraños. Si la herramienta de destino los enseña mal, casi siempre es que está suponiendo una codificación antigua y hay que decirle que el fichero es UTF-8.

PostgreSQL lee esta forma directamente con COPY, y el detalle que hay que conocer es el trato de los huecos: en su formato de texto un campo vacío es una cadena vacía y no un nulo, y solo la marca correspondiente significa nulo. Si la columna de destino es numérica y la hoja tenía huecos, ese es el mensaje de error que te espera.

R lo lee suponiendo ya el tabulador y pandas con el separador indicado a mano. En los tres casos conviene declarar el tipo de las columnas que sean identificadores y no cantidades, porque los tres aplicarán por su cuenta la misma inferencia numérica que convierte un código con ceros delante en un número.

La lectura del libro y la escritura del texto ocurren dentro de tu navegador. No hay subida, ni cola, ni cuenta, ni límite de filas más allá de la memoria de la máquina; el tope por archivo en las conversiones locales es de 100 MB y puedes soltar hasta cien ficheros de una vez.

El techo real es que el libro entero se sostiene en memoria a la vez, así que decenas de megabytes entran con holgura y a partir de cierto punto la pestaña empieza a sufrir. Para un fichero mayor, la herramienta correcta es un lector por flujo dentro de un script, y decirlo es más útil que fallar a mitad de una carga muy larga.

Elige CSV si el sitio de destino nombra el CSV expresamente, porque muchas pantallas de importación lo dicen de forma literal y no admiten otro separador por sensato que sea. Elige NDJSON si los valores tienen que conservar su tipo durante el viaje, o si la hoja tiene campos de texto libre donde pueden aparecer tabuladores y saltos de línea.

Elige SQL si las filas van a una tabla que ya existe, y Parquet si van a un motor analítico que va a consultarlas muchas veces. El TSV es la respuesta correcta para un caso muy concreto: herramientas de texto que parten por un carácter, siempre que ese carácter no aparezca en los datos.