Convertir CSV a TSV

Buena parte de los archivos que llegan con extensión `.csv` están separados por punto y coma. Excel los escribe así en cualquier configuración regional donde la coma sea el separador decimal, que es toda España y casi toda Hispanoamérica, porque un archivo que usara la coma para las dos cosas sería ilegible. También aparecen exportaciones separadas por barra vertical, sobre todo de sistemas bancarios y de telecomunicaciones antiguos.

El analizador de esta página deduce cuál es el carácter mirando el archivo y no su nombre, así que una exportación con punto y coma se convierte sin que haya que decirle nada. Donde eso falla es en un archivo de una sola columna: sin ningún separador presente, todos los candidatos están igual de ausentes y la detección no tiene con qué trabajar. Para eso está el selector de separador, y es la única situación en la que hace falta.

La coma es un mal delimitador por un motivo muy concreto: aparece constantemente en los datos reales. Las direcciones llevan comas. Las descripciones de producto llevan comas. Las razones sociales que acaban en «, S.L.» llevan comas. Cada uno de esos campos tiene que ir entre comillas, y cada programa que lea el archivo tiene que implementar bien la convención —comillas dobladas dentro de un campo entrecomillado, saltos de línea dentro de uno— antes de poder encontrar de nuevo los límites de columna.

Los tabuladores están casi ausentes del tipo de dato que la gente mete en tablas, así que el delimitador y el contenido dejan de competir. Después de esta conversión, el campo «Barcelona, España» aparece en el archivo exactamente así, sin una sola comilla en la línea, y cualquier cosa que parta por tabuladores lo recupera. Ese es el argumento entero, y es un argumento de fiabilidad, no de tamaño ni de velocidad.

El control ofrece detección automática, coma, punto y coma, tabulador y barra vertical, y arranca en automático. Automático acierta casi siempre, porque un archivo con varias columnas le da al detector pruebas de sobra y las lee bien.

Ponlo a mano en dos casos. El primero es el archivo de una sola columna, donde no hay nada que detectar. El segundo es un archivo con un campo lleno del carácter equivocado —una columna de observaciones plagada de puntos y coma dentro de una exportación separada por comas—, que puede llevar al detector a elegir el carácter que más aparece en lugar del que significa algo. Si la vista previa del resultado tiene una columna donde esperabas seis, o seis donde esperabas una, ese es el ajuste que hay que cambiar primero.

Los tabuladores sí aparecen dentro de campos de un CSV, casi siempre porque alguien pegó texto desde una página web o desde otra hoja de cálculo dentro de una celda. En el archivo de origen eso es inofensivo: el delimitador es la coma y el tabulador es un carácter corriente. En la salida no lo es, y el escritor lo resuelve poniendo ese campo entre comillas dobles.

El resultado es correcto y cualquier analizador completo lo maneja. El problema es que el TSV lo elige precisamente quien no va a usar un analizador completo: `cut -f` cuenta tabuladores y no ha oído hablar nunca de una comilla, así que desde esa fila en adelante ve una columna de más y todo lo que viene después queda desplazado. Si un proceso te está dando resultados desalineados en un puñado de filas de entre miles, la causa es casi siempre esta. Limpia los tabuladores del origen antes de convertir, en lugar de parchear más abajo.

Una exportación separada por punto y coma escribe normalmente 1234,56 donde un archivo en configuración inglesa escribe 1234.56. La conversión no traduce eso, y hace bien: no tiene forma de saber si 1.234 significa algo más que uno o mil doscientos treinta y cuatro, y adivinar corrompería todos los precios del archivo.

Lo que ocurre es que el valor se queda exactamente como estaba escrito y, como al analizador no le parece un número, se queda como texto. Así que una columna de precios en formato español atraviesa el TSV intacta, y a lo que lea el archivo después hay que decirle cuál es la convención decimal: en R es `dec = ","` al leer y en pandas es `decimal=","`. Ponerlo ahí es más seguro que hacer una sustitución masiva sobre el archivo, que además reescribiría los separadores de millar y cualquier coma que quedara en las columnas de texto.

El archivo no se recorre carácter a carácter cambiando un separador por otro: se analiza en filas y se vuelve a escribir, y por el camino todo lo que parece un número se lee como número. Los ceros a la izquierda no sobreviven a eso.

En un archivo español el ejemplo salta a la vista en la columna de código postal: 08001 se convierte en 8001 y 01001 en 1001, así que Barcelona y Vitoria pierden su primera cifra mientras que Madrid y Sevilla no. Lo mismo le pasa a una referencia de artículo rellena con ceros, a un número de cuenta o a un RUT guardado como texto. La prueba para saber si una columna está en riesgo es preguntarse si sumar dos de sus valores significaría algo; si no significa nada, es un identificador y no un número. Mira esa columna en la salida antes de cargar el resultado en ningún sitio.

La misma lectura convierte `1e5` en 100000 y las palabras `true` y `false` en valores booleanos, que se vuelven a escribir en minúsculas. Un campo vacío pasa a nulo y se escribe de nuevo como campo vacío, que es el único caso en el que no cambia nada visible.

Si el archivo lleva estructuras anidadas —porque venía de un JSON antes de llegar aquí, por ejemplo— se aplanan en una columna por hoja, con la ruta separada por puntos como nombre de columna y los índices de los arreglos como tramos de esa ruta. Es el mismo aplanado que se usa para CSV, SQL, INI, XLSX y Parquet, y es lo contrario de lo que ocurre al escribir JSON, YAML, TOML, XML o NDJSON, que conservan el árbol.

En el TSV los campos van entre comillas solo cuando no queda más remedio: cuando contienen un tabulador, una comilla doble o un salto de línea. Todo lo demás se escribe desnudo. Un CSV que llegó con comillas alrededor de cada campo —hay exportadores que lo hacen sin condiciones— sale con casi ninguna, lo que en un archivo ancho supone una reducción de tamaño apreciable y una ganancia grande de legibilidad al abrirlo.

Una comilla doble dentro de un campo que sí necesita comillas se dobla, la misma convención que usa CSV. Vale la pena saberlo si el archivo va a un sitio que parte de forma ingenua, porque una columna de texto libre con comillas es la otra cosa que produce un campo entrecomillado en un formato donde nadie lo espera.

Las filas se separan con un único salto de línea y no con la pareja de retorno de carro y salto que usa Windows. Es lo que esperan una tubería de shell, un diff de Git, R y pandas, y también lo que aceptan ya la mayoría de herramientas de Windows.

El texto sale en UTF-8 y no se le antepone ninguna marca de orden de bytes, porque nada en esta ruta escribe una. Eso tiene una consecuencia práctica: hacer doble clic en el archivo para abrirlo en Excel en Windows mostrará las tildes y las eñes como caracteres extraños, porque Excel recurre a la codificación del sistema cuando no hay marca que le indique otra cosa. Abrirlo desde Datos, Obtener datos, Desde texto y elegir UTF-8 lo evita. Si el destino es Excel y no un script, convertir a XLSX quita la pregunta de en medio.

Los dos formatos son texto plano y los dos lectores son JavaScript, así que la conversión ocurre entera en esta página. Ninguna petición se lleva el archivo, no hay cola y no hay niveles de pago, lo que importa porque un CSV es muy a menudo un listado de clientes, una exportación de pedidos o un volcado de sistema cuya subida costaría explicar.

El límite es la memoria y no una regla nuestra: el archivo se lee en filas y la tabla entera existe a la vez antes de escribir nada. El techo formal del plan gratuito son 100 MB por archivo; decenas de megabytes son rutina y a partir de cientos una pestaña de navegador empieza a sufrir. Pasado eso, la herramienta correcta es un analizador en flujo dentro de un script, y decirlo es mejor que fallar a mitad de una exportación muy grande.

Si el destino es una pantalla de importación que dice CSV, déjalo en CSV. Un número sorprendente de ellas se toma la palabra al pie de la letra y rechaza un archivo separado por tabuladores por muy sensata que sea la elección, y discutir con un formulario de subida no es una pelea que merezca la pena.

La salida separada por tabuladores se gana su sitio cuando algo va a partir el archivo por un carácter en lugar de analizarlo: una tubería de shell, un script de R, un pegado en un programa con importación por tabuladores, una mirada rápida con `cut`. Si en cambio lo que hace falta es que los valores conserven su tipo durante el viaje, ningún formato delimitado ayuda —un archivo de texto no distingue el número 7 de la cadena «7»— y el destino honesto es JSON, NDJSON o Parquet.

Se pueden soltar hasta cien archivos a la vez; cada uno se convierte por su cuenta y vuelven juntos en un archivo comprimido. Si sueltas más de cien, los que no caben se descartan sin avisar, así que con una carpeta grande conviene ir por tandas y comprobar la cuenta de salida.

Cada archivo se analiza por separado, incluida la detección de separador, lo que resulta útil cuando la carpeta mezcla exportaciones de sistemas distintos. Lo que no hace es unirlos: cuarenta CSV entran y salen cuarenta TSV, no una tabla concatenada.