Outils de développement · Comparaison de texte
Pourquoi Windows et Unix ne sont pas d'accord sur les fins de ligne : l'histoire de CR, LF et CRLF
· Contexte
texte-diff fins de ligne historique du logiciel
Retrace les fins de ligne depuis les machines à écrire et les télétypes jusqu'aux systèmes d'exploitation modernes et explique pourquoi deux conventions coexistent toujours dans chaque projet multiplateforme.
Un personnage invisible, des décennies de frictions - s'ouvre sur l'agacement multiplateforme persistant
Les fins de ligne sont invisibles dans les éditeurs ordinaires mais peuvent avoir une incidence sur les fichiers et les protocoles. Dans ToolAcre, cependant, CR, LF et CRLF sont normalisés avant la comparaison des lignes. Une paire ne différant que par ces séparateurs produit le même réseau de lignes et un résultat identique.
Ce comportement résout la question pratique de cet itinéraire tout en limitant ce qu'il peut diagnostiquer. La comparaison ne peut pas prouver quels octets de nouvelle ligne les fichiers originaux contenaient une fois que le texte atteint ses éditeurs. Un outil prenant en compte les octets est requis pour la préservation ou les vérifications de protocole.
Retour chariot et saut de ligne sur une machine à écrire : explique les deux actions physiques décrites à l'origine par les personnages.
Les termes retour chariot et saut de ligne ont des significations physiques et historiques, mais le référentiel ne contient aucune source de machine à écrire. Répéter de mémoire une histoire d’origine mécanique violerait le contrat de preuve même si le récit semblait familier.
Cet article traite donc CR comme l'unité de code ` ` et LF comme ` ` uniquement là où l'implémentation les utilise. L'explication historique devrait être ajoutée ultérieurement à partir de normes primaires ou d'archives plutôt que empruntée à un plan qui n'est explicitement pas une source.
Les significations écrites à la machine à écrire sont des affirmations historiques nécessitant des sources externes.
De même, les fichiers sources ne documentent pas les conventions de télétype ni les premières décisions du système d'exploitation. Ils ne révèlent qu'un choix de compatibilité dans le JavaScript actuel : remplacez chaque CRLF ou CR isolé par LF avant de le diviser.
Cette transformation accepte le texte collé produit selon plusieurs conventions sans remplir la sortie avec des modifications de fin uniquement. Il s'agit d'une décision d'implémentation visible dans une expression régulière et épinglée par des tests pour les trois formes.
La lignée du télétype et du système d'exploitation est une preuve extérieure au référentiel
Il est courant d'associer Unix à LF, Windows à CRLF et des systèmes plus anciens à un seul CR, mais le référentiel actuel ne peut pas servir de preuve historique de ces adoptions. La revendication de sécurité est opérationnelle : les trois entrées deviennent LF à l'intérieur de `splitLines`.
Un terminal LF ne crée pas de ligne vide finale, tandis que des lignes vides au milieu restent. Cette distinction signifie que le contenu logique est conservé même si les différences entre les séparateurs physiques sont effacées. La comparaison est orientée ligne et ne préserve pas les octets.
Le code prouve que trois conventions se normalisent ; cela ne prouve pas pourquoi les systèmes les ont adoptés
Certains protocoles de réseau et de messages spécifient des terminaisons de ligne exactes, mais leurs exigences doivent provenir de leurs spécifications. La normalisation de ToolAcre le rend inadapté pour prouver la conformité à un tel format de fil, car la preuve originale du séparateur est intentionnellement supprimée.
Utilisez une visionneuse hexadécimale ou un validateur de protocole avant d'analyser lorsque les séquences CRLF exactes sont importantes. Un résultat de différence de texte propre peut confirmer la correspondance des lignes logiques et simultanément masquer un défaut au niveau du transport. Les deux observations peuvent être vraies car les outils répondent à des questions différentes.
Les exigences du protocole nécessitent leurs propres spécifications et sont omises ici
Comparez `alpha bêta`, `alpha bêta` and `alpha bêta` par paires. Chacun produit deux lignes, alpha et bêta, et aucun ajout ni suppression. Ignorer les espaces ne provoque pas cette égalité ; la normalisation s'est déjà produite lors de la scission.
Ajoutez des espaces de fin à une ligne bêta et le mode ordinaire signalera désormais une différence. Activez Ignorer les espaces et il peut disparaître. La séquence sépare la gestion des nouvelles lignes de la gestion des espaces de touche de ligne et empêche de créditer la mauvaise option.
Exemple concret : les trois formes de fin se comparent comme étant égales avant les options d'espacement
Cette route ne configure pas les éditeurs, ne réécrit pas les fichiers, ne définit pas les attributs Git ou ne convertit pas les fins en masse. Il n'expose pas non plus le séparateur d'origine dans les lignes de résultats. Les chaînes collées entrent dans un pipeline de comparaison, pas dans un utilitaire de migration de nouvelle ligne.
Les normes historiques de causalité et de protocole sont omises dans les sources en attente. Cette restriction laisse un article plus petit mais précis : que font les trois conventions dans cette implémentation, quelles lignes vides restent et pourquoi l'égalité ici n'établit pas l'identité des octets.
À retenir : sachez quelle convention porte votre texte - résume l'historique et comment la comparaison de texte de ToolAcre aide à confirmer si une différence concerne uniquement les fins de ligne
Sachez quelles preuves ont survécu à l'outil. Après normalisation, ToolAcre peut comparer le contenu des lignes logiques entre les séparateurs communs. Il ne peut pas vous dire quelle convention l'une ou l'autre source a utilisée ou si un consommateur en aval a besoin d'une séquence d'octets exacte.
Utilisez la comparaison du navigateur pour un examen humain et une vérification au niveau des octets pour l'application du référentiel ou du protocole. Un outil est fiable lorsque ses transformations sont explicites ; les évaluateurs restent responsables de la sélection de celui qui préserve la propriété qu’ils doivent vérifier.