Strumenti per sviluppatori · Confronto di testi
Perché Windows e Unix non sono d'accordo sulle terminazioni di linea: la storia di CR, LF e CRLF
· Sfondo
testo-diff terminazioni di riga storia del software
Traccia le terminazioni di linea dalle macchine da scrivere e telescriventi ai moderni sistemi operativi e spiega perché due convenzioni coesistono ancora in ogni progetto multipiattaforma.
Un personaggio invisibile, decenni di attriti: si apre con il persistente fastidio multipiattaforma
Le terminazioni di riga sono invisibili negli editor ordinari ma possono avere importanza per file e protocolli. In ToolAcre, tuttavia, CR, LF e CRLF vengono normalizzati prima del confronto delle linee. Una coppia che differisce solo per questi separatori produce lo stesso line array e un risultato identico.
Questo comportamento risolve il problema pratico di questo percorso limitando ciò che può diagnosticare. Il confronto non può provare quale fine riga byte i file originali contenuti dopo che il testo ha raggiunto i suoi editor. È necessario uno strumento in grado di riconoscere i byte per la conservazione o i controlli del protocollo.
Ritorno a capo e avanzamento riga su una macchina da scrivere: spiega le due azioni fisiche originariamente descritte dai personaggi
I termini ritorno a capo e avanzamento riga hanno significati fisici e storici, ma il repository non contiene fonti di macchine da scrivere. Ripetere a memoria una storia di origine meccanica violerebbe il contratto di prova anche se il racconto suonasse familiare.
Il presente articolo considera pertanto CR come il ` ` code unit and LF as ` ` solo dove l'implementazione li utilizza. La spiegazione storica dovrebbe essere aggiunta in seguito da standard o archivi primari piuttosto che presa in prestito da uno schema che non è esplicitamente una fonte.
I significati della macchina da scrivere sono affermazioni storiche che richiedono fonti esterne
Allo stesso modo, i file sorgente non documentano le convenzioni della telescrivente o le prime decisioni sul sistema operativo. Rivelano solo una scelta di compatibilità nell'attuale JavaScript: sostituire ogni CRLF o CR singolo con LF prima della divisione.
Questa trasformazione accetta testo incollato prodotto secondo diverse convenzioni senza riempire l'output con modifiche solo finali. È una decisione di implementazione visibile in un'espressione regolare e fissata da test per tutte e tre le forme.
La discendenza della telescrivente e del sistema operativo è al di fuori delle prove del repository
È comune associare Unix con LF, Windows con CRLF e i sistemi più vecchi con un solo CR, ma l'attuale repository non può servire come prova storica di tali adozioni. L'affermazione sicura è operativa: tutti e tre gli ingressi diventano LF all'interno di `splitLines`.
Un terminale LF non crea un'ultima riga vuota, mentre rimangono le righe vuote al centro. Questa distinzione significa che il contenuto logico viene mantenuto anche se le differenze di separatore fisico vengono cancellate. Il confronto è orientato alla linea, non alla preservazione dei byte.
Il codice dimostra che tre convenzioni si normalizzano; non dimostra perché i sistemi li abbiano adottati
Alcuni protocolli di rete e di messaggio specificano esattamente i terminatori di linea, ma i loro requisiti devono derivare dalle loro specifiche. La normalizzazione di ToolAcre lo rende inadatto a dimostrare la conformità a tale formato di collegamento perché la prova del separatore originale viene intenzionalmente rimossa.
Utilizza un visualizzatore esadecimale o un validatore di protocollo prima di analizzare quando contano le sequenze CRLF esatte. Un risultato di differenza testo pulito può confermare la corrispondenza delle linee logiche e contemporaneamente nascondere un difetto a livello di trasporto. Entrambe le osservazioni possono essere vere perché gli strumenti rispondono a domande diverse.
I requisiti del protocollo necessitano di specifiche specifiche e vengono omessi qui
Confronta "alfa". beta`, `alpha beta` and `alpha beta` in coppia. Ciascuno produce due righe, alfa e beta, e nessuna aggiunta o rimozione. Ignorare gli spazi bianchi non causa questa uguaglianza; la normalizzazione è già avvenuta durante la suddivisione.
Aggiungi spazi finali a una riga beta e la modalità ordinaria ora riporterà una differenza. Abilita Ignora spazi bianchi e potrebbe scomparire. La sequenza separa la gestione del ritorno a capo dalla gestione degli spazi bianchi dei tasti di riga e impedisce di accreditare l'opzione sbagliata.
Esempio realizzato: tutte e tre le forme finali vengono confrontate come uguali prima delle opzioni degli spazi bianchi
Questo percorso non configura editor, riscrive file, imposta attributi Git o converte in blocco i finali. Inoltre non espone il separatore originale nelle righe dei risultati. Le stringhe incollate entrano in una pipeline di confronto, non in un'utilità di migrazione di nuova riga.
La causalità storica e gli standard di protocollo vengono omessi in attesa delle fonti. Questa restrizione lascia un articolo più piccolo ma esatto: cosa fanno le tre convenzioni in questa implementazione, quali righe vuote rimangono e perché l'uguaglianza qui non stabilisce l'identità dei byte.
Conclusione: scopri quale convenzione porta il tuo testo: riassume la cronologia e in che modo il confronto del testo di ToolAcre aiuta a confermare se una differenza riguarda solo le terminazioni di riga
Scopri quali prove sono sopravvissute allo strumento. Dopo la normalizzazione, ToolAcre può confrontare il contenuto della linea logica tra separatori comuni. Non può dirti quale convenzione è stata utilizzata dalla fonte o se un consumatore a valle richiede una sequenza di byte esatta.
Utilizza la differenza del browser per la revisione umana e un controllo a livello di byte per l'applicazione del repository o del protocollo. Uno strumento è affidabile quando le sue trasformazioni sono esplicite; i revisori rimangono responsabili di selezionarne uno che preservi la proprietà che devono verificare.