Convertidor de CSV a JSON

El análisis CSV sigue la gramática del RFC 4180 del IETF: cada registro termina con CRLF (algunos dialectos aceptan LF o CR), cada registro contiene campos separados por un delimitador (coma en el RFC, pero TSV, punto y coma y barra vertical son variantes extendidas), y cualquier campo que contenga el delimitador, un CR, un LF o una comilla doble DEBE estar entre comillas dobles, con las comillas internas escapadas mediante duplicación (Hello "world" se convierte en "Hello ""world"""). El analizador de esta página es una máquina de estados con cuatro estados: field_start, in_unquoted, in_quoted, after_quote, y procesa la entrada en una sola pasada O(n) sobre el flujo de caracteres, de modo que un CSV de 10 MB con 100.000 filas se completa en mucho menos de un segundo en un portátil típico sin asignar nunca un array intermedio de tokens por fila. La codificación requiere manejo explícito: un BOM UTF-8 (EF BB BF) al inicio del archivo se elimina antes del análisis, de lo contrario el primer nombre de encabezado comenzaría silenciosamente con el punto de código invisible U+FEFF y las comprobaciones de igualdad de JSON.parse aguas abajo fallarían. Las exportaciones de Excel en Windows aún emiten CRLF y frecuentemente UTF-8 con BOM, mientras que Numbers de macOS y la mayoría de herramientas Unix usan por defecto LF sin BOM. Las hojas de cálculo europeas comúnmente exportan archivos delimitados por punto y coma porque la coma es un separador decimal en muchos locales (49,90 EUR en lugar de 49.90), por lo que el selector de delimitador tiene la coma como valor predeterminado pero expone tabulación, punto y coma y barra vertical como opciones de primera clase. El interruptor de primera fila como encabezado cambia la forma de salida de un array de objetos (claves de encabezado -> valores string) a un array de arrays, coincidiendo con los dos patrones de ingestión más comunes para el código aguas abajo. Los valores de campo se emiten como cadenas, no como tipos inferidos: CSV no tiene esquema, por lo que 01234 (un ID con ceros a la izquierda), 1e10 (una cadena con apariencia de número de teléfono que JSON.parse convertiría a número) y 2024-13-45 (una fecha mal formada) permanecen tal cual. Esto es intencional: una API tipada aguas abajo puede aplicar zod, Joi o una capa de coerción manual con reglas explícitas, pero no puede recuperar un cero inicial que el convertidor ya haya eliminado. La salida se genera mediante JSON.stringify(rows, null, 2) y se renderiza a través de un resaltador de sintaxis; el CSV fuente se lee con FileReader.readAsText() en un Blob, sin subirse nunca a un backend, por lo que las exportaciones de RR. HH., libros de contabilidad y listas de clientes pueden reestructurarse sin salir de la sesión del navegador.

• Gramática RFC 4180: los campos con delimitador/CR/LF/comilla deben ir entrecomillados; las comillas internas se duplican como "".
• Máquina de estados en una sola pasada O(n) con estados: field_start, in_unquoted, in_quoted, after_quote.
• El BOM UTF-8 (EF BB BF / U+FEFF) se elimina al inicio del archivo para mantener limpias las claves de encabezado.
• Las hojas de cálculo europeas suelen usar ; como delimitador porque la coma es el separador decimal en la configuración regional.
• La primera fila como encabezado alterna la salida entre Array<Record<string,string>> y Array<Array<string>>.
• Todos los valores de campo permanecen como cadenas; los IDs con ceros a la izquierda como 01234 sobreviven solo porque no se ejecuta inferencia de tipos.
• FileReader.readAsText() procesa el Blob localmente; nada se sube - seguro para exportaciones de RR. HH./finanzas/staging.