Eliminar Duplicados

La pasada de deduplicación recorre las líneas de entrada una vez e inserta cada una en un Set de JavaScript indexado por la forma de comparación. ECMA-262 especifica que el orden de iteración del Set es igual al orden de inserción, así que la primera vez que aparece una clave se mantiene la línea original y los duplicados posteriores se descartan. Esto preserva patrones donde el orden codifica significado (logs con timestamp, listas ordenadas, CSVs ordenados) donde la primera fila es la canónica. Si se necesita 'gana la última aparición', el inverso se consigue invirtiendo entrada → deduplicar → invertir salida, pero la mayoría de casos de uso — exportaciones de email, limpieza de CSV, compresión de logs — prefieren 'gana la primera'.

La clave de comparación se genera con String.prototype.toLowerCase, que realiza plegado de mayúsculas Unicode simple — solo mapeos de un carácter. Esto coincide con lo que la mayoría de usuarios esperan ('Apple' = 'apple' = 'APPLE') pero no maneja algunos casos de plegado completo definidos por UCD CaseFolding.txt: la ß alemana se pliega a 'ss' solo bajo plegado completo, y el par I/i sin punto del turco es otro caso clásico dependiente de locale. Para listas cotidianas — emails, CSVs, líneas de log — el plegado simple es correcto; para texto jurídico alemán o turco, redirigir la comparación a Intl.Collator(locale, { sensitivity: 'accent' }) maneja esos casos.

El algoritmo es una pasada única O(n) sobre las líneas de entrada. ECMA-262 especifica Set.prototype.has y Set.prototype.add como sublineales; los motores principales (V8, SpiderMonkey, JavaScriptCore) implementan Set sobre tablas hash, donde el O(1) amortizado se sigue del análisis estándar de tablas hash (Knuth, TAOCP Vol 3 §6.4 Hashing). El trabajo total para n líneas de entrada es O(n) inserciones y O(n) búsquedas. La tubería escala linealmente: una lista de 10.000 líneas se deduplica en milisegundos y una lista de 100.000 líneas completa en bastante menos de un segundo en hardware típico. La memoria crece con el número de líneas únicas, no con la longitud de entrada — entradas con muchos duplicados (un log ruidoso con errores repetidos) se comprimen a un conjunto único pequeño.

Es una decisión de diseño deliberada: cuando 'recortar espacios' está activado, ' apple', 'apple ' y 'apple' no solo se tratan como iguales durante la comparación, sino que todos exportan como un 'apple' limpio en el resultado. Recortar solo para comparación — manteniendo el espaciado original — también es defendible (algunos usos requieren preservar bytes exactos), pero para casos de uso típicos (exportaciones de email, limpieza de CSV, saneado de listas) el usuario quiere ambas cosas: colapsar equivalentes Y limpiar los supervivientes. Si se requiere recorte solo para comparación, pre-procesar con text-replace antes de deduplicar con recorte desactivado consigue eso.

La región de salida y la línea de estadísticas (recuento original, recuento único, recuento eliminado) están dentro de una región aria-live="polite", el patrón del Criterio de Éxito 4.1.3 de WCAG (Mensajes de Estado, introducido en WCAG 2.1, recomendación del W3C del 5 de junio de 2018; trasladado sin cambios a WCAG 2.2, recomendación del 5 de octubre de 2023). Las regiones live polite encolan anuncios tras cualquier habla en progreso, apropiado para actualizaciones incrementales mientras el usuario escribe o pega. Los lectores de pantalla (NVDA, JAWS, VoiceOver) consumen la región live automáticamente; el usuario no necesita hacer nada más.