Herramientas de desarrollo · Comparación de texto
Por qué Windows y Unix no están de acuerdo en los finales de línea: la historia de CR, LF y CRLF
· Antecedentes
diferencia de texto finales de línea historial de software
Traza los finales de línea desde máquinas de escribir y teletipos hasta los sistemas operativos modernos y explica por qué todavía coexisten dos convenciones en cada proyecto multiplataforma.
Un personaje invisible, décadas de fricción: comienza con la persistente molestia multiplataforma
Los finales de línea son invisibles en los editores comunes, pero pueden ser importantes para archivos y protocolos. En ToolAcre, sin embargo, CR, LF y CRLF se normalizan antes de la comparación de líneas. Un par que difiere sólo en esos separadores produce la misma matriz lineal y un resultado idéntico.
Ese comportamiento resuelve la cuestión práctica de esta ruta y al mismo tiempo limita lo que puede diagnosticar. La comparación no puede demostrar qué bytes de nueva línea contenían los archivos originales después de que el texto llega a sus editores. Se requiere una herramienta con reconocimiento de bytes para la preservación o las comprobaciones de protocolo.
Retorno de carro y avance de línea en una máquina de escribir: explica las dos acciones físicas que los personajes describieron originalmente
Los términos retorno de carro y avance de línea tienen significados físicos e históricos, pero el repositorio no contiene ninguna fuente de máquina de escribir. Repetir una historia de origen mecánico de memoria violaría el contrato de evidencia incluso si el relato le sonara familiar.
Por lo tanto, este artículo trata a CR como la unidad de código ` ` y a LF como ` `solo donde la implementación los usa. La explicación histórica debe agregarse más tarde a partir de estándares o archivos primarios en lugar de tomarse prestado de un esquema que explícitamente no sea una fuente.
Los significados de las máquinas de escribir son afirmaciones históricas que requieren fuentes externas.
Asimismo, los archivos fuente no documentan convenciones de teletipo ni decisiones tempranas del sistema operativo. Solo revelan una opción de compatibilidad en JavaScript actual: reemplazar cada CRLF o CR solitario con LF antes de dividir.
Esa transformación acepta texto pegado producido según varias convenciones sin llenar la salida con cambios de solo final. Es una decisión de implementación visible en una expresión regular y fijada por pruebas para las tres formas.
El linaje del teletipo y del sistema operativo está fuera de la evidencia del repositorio
Es común asociar Unix con LF, Windows con CRLF y sistemas más antiguos con un único CR, pero el repositorio actual no puede servir como prueba histórica de esas adopciones. El reclamo seguro es operativo: las tres entradas se convierten en LF dentro de `splitLines`.
Un terminal LF no crea una fila final vacía, mientras que quedan líneas en blanco en el medio. Esta distinción significa que el contenido lógico se conserva aunque se borren las diferencias de los separadores físicos. La comparación está orientada a líneas, no a bytes.
El código demuestra que tres convenciones se normalizan; no prueba por qué los sistemas los adoptaron
Algunos protocolos de red y mensajes especifican terminadores de línea exactos, pero sus requisitos deben provenir de sus especificaciones. La normalización de ToolAcre lo hace inadecuado para demostrar la conformidad con dicho formato de cable porque la evidencia del separador original se elimina intencionalmente.
Utilice un visor hexadecimal o un validador de protocolo antes de analizar cuando las secuencias CRLF exactas sean importantes. Un resultado de diferenciación de texto limpio puede confirmar líneas lógicas coincidentes y simultáneamente ocultar un defecto a nivel de transporte. Ambas observaciones pueden ser ciertas porque las herramientas responden a preguntas diferentes.
Los requisitos del protocolo necesitan sus propias especificaciones y se omiten aquí.
Comparar `alfa beta`, `alfa beta` and `alfa beta` en parejas. Cada uno produce dos líneas, alfa y beta, y no hay adiciones ni eliminaciones. Ignorar los espacios en blanco no provoca esta igualdad; la normalización ya ocurrió durante la división.
Agregue espacios finales a una fila beta y el modo normal ahora informará una diferencia. Habilite Ignorar espacios en blanco y puede desaparecer. La secuencia separa el manejo de nuevas líneas del manejo de espacios en blanco de claves de línea y evita acreditar la opción incorrecta.
Ejemplo resuelto: las tres formas finales se comparan como iguales antes de las opciones de espacios en blanco
Esta ruta no configura editores, reescribe archivos, establece atributos de Git ni convierte finales en masa. Tampoco expone el separador original en las filas de resultados. Las cadenas pegadas ingresan a un proceso de comparación, no a una utilidad de migración de nueva línea.
La causalidad histórica y los estándares de protocolo se omiten en espera de fuentes. Esa restricción deja un artículo más pequeño pero exacto: qué hacen las tres convenciones en esta implementación, qué líneas en blanco quedan y por qué la igualdad aquí no establece la identidad de los bytes.
Conclusión: conozca qué convención lleva su texto: resume el historial y cómo la comparación de texto de ToolAcre ayuda a confirmar si una diferencia son solo los finales de línea
Sepa qué evidencia sobrevivió a la herramienta. Después de la normalización, ToolAcre puede comparar el contenido de la línea lógica entre separadores comunes. No puede decirle qué convención utilizó cada fuente o si un consumidor intermedio requiere una secuencia de bytes exacta.
Utilice la diferencia del navegador para la revisión humana y una verificación a nivel de bytes para la aplicación del protocolo o del repositorio. Una herramienta es confiable cuando sus transformaciones son explícitas; los revisores siguen siendo responsables de seleccionar uno que conserve la propiedad que necesitan verificar.