Comparador de textos

Qué hace esta herramienta

Un diff responde con precisión a una sola pregunta: ¿qué tendría que cambiar para convertir un texto en otro? Pega el original en el panel «Original» y la versión nueva en el panel «Modificado», y la herramienta muestra cada línea eliminada, cada línea añadida y — dentro de una línea modificada — las palabras exactas que difieren, resaltadas. Es la misma pregunta que git responde en cada commit, calculada con la misma familia de algoritmos, por completo en tu navegador.

Esa última parte importa más en una herramienta de diff que en la mayoría: lo que la gente compara suele ser privado — dos versiones de una configuración de producción, una consulta antes y después de una optimización, el cuerpo de respuesta que ayer funcionaba frente al que hoy falla. Aquí nunca salen de tu dispositivo.

Lado a lado o unificada

Las dos vistas muestran la misma comparación con distinta disposición. Lado a lado coloca el original y el modificado uno frente al otro — la columna del original bajo el panel «Original» — con las líneas coincidentes alineadas: la forma natural de leer la revisión de un documento. Unificada los entrelaza en una sola columna, con las eliminaciones precedidas de un menos y las adiciones de un más — el formato de git log y de las revisiones de código, más compacto y mejor cuando los cambios están dispersos. Ambas vistas marcan los números de línea originales en los márgenes, así que un hallazgo aquí se corresponde directamente con tu archivo.

Cómo se calcula el diff

La herramienta implementa el algoritmo de diferencias de Myers, publicado en 1986 y todavía el predeterminado de git hoy. Encuentra un guion de edición mínimo: el número mínimo de eliminaciones e inserciones de líneas que transforma un texto en el otro. Esa minimalidad es lo que hace legible un diff — una comparación ingenua que se resincroniza mal tras un cambio reporta bloques enteros como reemplazados, mientras que Myers señala exactamente las dos líneas que de verdad cambiaron.

Primero se comparan las líneas, y luego cada par de líneas cambiadas se compara de nuevo a nivel de palabra para producir los resaltados. Una limitación honesta: cuando dos textos no tienen casi nada en común, la búsqueda del guion mínimo costaría más memoria de la que una pestaña del navegador debería gastar, así que más allá de una distancia de edición de dos mil la herramienta pasa a mostrar todo como reemplazado — y lo dice con un aviso en lugar de callarlo.

Las opciones de espacios y mayúsculas

Muchas diferencias son reales pero irrelevantes. Un archivo reindentado de tabuladores a espacios, un espacio final añadido por un editor, una palabra clave con otras mayúsculas — todos son cambios genuinos, y todos son ruido cuando lo que quieres saber es si cambió la lógica. Las dos casillas cubren los casos comunes: una deja de lado los espacios en los bordes de cada línea, la otra deja de lado las mayúsculas. Solo afectan a qué cuenta como cambio — la vista siempre muestra cada línea exactamente como la pegaste.

• Ignorar espacios en los bordes — los espacios y tabuladores al principio y al final de cada línea se descartan antes de comparar, así que un cambio solo de sangría deja de aparecer como línea modificada. Los espacios dentro de la línea siguen contando.
• Ignorar mayúsculas — líneas y palabras que solo difieren en mayúsculas y minúsculas se comparan como iguales. Útil para palabras clave de SQL, nombres de cabeceras HTTP y otros contextos insensibles a mayúsculas.

El parche que puedes copiar

El botón de copiar produce la comparación en formato de diff unificado — la lengua franca de los cambios de código. Cada bloque de cambio (hunk) empieza con una cabecera @@ que indica los números de línea que cubre, las líneas eliminadas empiezan con un menos, las añadidas con un más, y unas pocas líneas de contexto sin cambios rodean cada bloque para poder localizar el cambio aunque el archivo se haya desplazado un poco.

--- a
+++ b
@@ -1,3 +1,3 @@
 server:
-  port: 8080
+  port: 9090
   timeout: 30

Ese texto puede pegarse en un ticket o en una revisión de código, enviarse a un colega o aplicarse mecánicamente: guardado en un archivo, git apply o el comando patch de Unix reproducirán el cambio sobre el original. Un detalle que conviene conocer: un archivo que no termina en salto de línea recibe en su parche el marcador \ No newline at end of file — la herramienta reproduce ese comportamiento, porque un salto de línea final ausente es una diferencia real y fingir lo contrario genera parches que no aplican.