Strumenti per sviluppatori · Confronto di testi
Ogni riga è cambiata? Fine riga, spazi finali e distinte materiali in una differenza
· Come funziona
testo-diff terminazioni di riga debug
Diagnostica le tre cause invisibili di un confronto che segnala ogni riga come diversa e mostra come capire quale si ha prima di incolpare l'autore.
Lo stesso file, salvato due volte, apparentemente riscritto, costituisce il caso comune di un file modificato su due sistemi operativi
Due salvataggi possono sembrare una riscrittura quando un editor modifica i caratteri invisibili, ma il comportamento di ToolAcre dipende da quali caratteri sono stati modificati. Normalizza le terminazioni di riga prima della corrispondenza, mentre gli spazi sul bordo di una riga e U+FEFF all'inizio rimangono il normale contenuto della riga a meno che un'altra opzione non modifichi la chiave.
Costruisci un dispositivo diagnostico invece di indovinare dal colore. Confronta una coppia che differisce solo per la desinenza, un'altra che differisce per gli spazi finali e una terza con BOM iniziale. Le coppie controllate rivelano i confini dello strumento in modo più affidabile di un file reale contenente diverse modifiche invisibili contemporaneamente.
CRLF contro LF: il carattere alla fine di ogni riga - spiega perché Windows termina le righe con due caratteri, Unix con uno e come un diff vede il ritorno a capo aggiuntivo
`splitLines` sostituisce CRLF e l'unico CR con LF, quindi si divide. I test stabiliscono che tutte e tre le convenzioni producono gli stessi array. Pertanto una differenza CRLF è invisibile anche quando Ignora spazi bianchi è disattivato; l’affermazione dello schema secondo cui ogni riga sarebbe diversa contraddice questa implementazione.
Inoltre, un ritorno a capo finale non crea una riga aggiuntiva. Dopo la divisione, viene rimossa una voce vuota del terminale. Le linee vuote autentiche al centro rimangono unità di confronto, quindi il comportamento distingue una convenzione di fine file dalla separazione verticale intenzionale all'interno del documento.
ToolAcre normalizza CRLF, CR e LF prima del confronto, quindi le modifiche solo finali scompaiono
Gli spazi finali rimangono nelle righe originali. Con il confronto ordinario, `name=value` e `name=value ` hanno chiavi diverse. Ignora gli spazi bianchi taglia entrambe le estremità e comprime le sequenze interne, in modo che l'opzione possa far corrispondere la coppia preservando il testo originale sinistro nella riga uguale visualizzata.
La libreria implementa anche un'opzione `ignoreTrailingWhitespace` più ristretta, ma l'interfaccia utente corrente non la espone. Gli articoli non devono descrivere una casella di controllo che gli utenti non possono selezionare. Il pannello fornito offre Ignora maiuscole/minuscole, Ignora tutte le differenze di spazi bianchi e Comprimi le sequenze prolungate invariate.
Il segno dell'ordine dei byte nella parte superiore del file: descrive il carattere U+FEFF che alcuni editor antepongono ai file UTF-8 e perché rende diversa solo la prima riga
Un segno dell'ordine dei byte UTF-8 decodificato nel testo JavaScript è U+FEFF all'inizio della prima riga. `splitLines` non ha una rimozione esplicita di BOM. Con la corrispondenza ordinaria, quel carattere può far differire solo la prima riga mentre le righe successive rimangono uguali.
Le operazioni di JavaScript spazi bianchi possono trattare U+FEFF come spazi bianchi quando Ignora spazi bianchi chiama `trim`, ma questo articolo non generalizza questo comportamento nel comportamento di decodifica dei file. L'editor riceve le stringhe; non legge i byte dei file né riporta le codifiche. Ispeziona il carattere effettivo quando la provenienza a livello di byte è importante.
Esempio pratico: distinguere le tre cause: fornisce un percorso decisionale: una differenza della sola prima riga punta a BOM, ogni linea punta a finali, le linee sparse puntano a spazi finali
Inizia con "alfa". beta` and `alpha beta`: the result is identical. Next compare `alpha beta` with `alpha beta`: la modalità ordinaria riporta le righe sostitutive, mentre la modalità spazi bianchi le abbina. Infine prefiggi l'alfa di un lato con U+FEFF e osserva l'effetto della prima riga.
Tale sequenza separa le cause utilizzando operazioni comprovate dal repository. Se ogni riga differisce ancora dopo aver terminato la normalizzazione, esamina il contenuto, il rientro o i caratteri finali anziché incolpare solo CRLF. Se differisce solo la prima riga, esamina i suoi punti di codice principali prima di riscrivere l'intero file.
Utilizzo dell'opzione degli spazi bianchi come diagnostica: mostra come l'abilitazione dell'ignora spazi bianchi nel confronto del testo di ToolAcre può assorbire lo spazio finale e il rumore di fine riga in modo che le modifiche reali risaltino
Ignorare gli spazi bianchi è utile per il rumore degli spazi finali perché taglia e condensa le chiavi di linea. Non è responsabile di nascondere CRLF rispetto a LF; ciò è già avvenuto durante la suddivisione. Mantenere separate queste fasi impedisce di trarre conclusioni fuorvianti su quale opzione abbia corretto il confronto.
Esegui entrambe le visualizzazioni perché il taglio può nascondere un rientro significativo e la condensazione può alterare i valori a larghezza fissa o i valori letterali delle stringhe. Un risultato normalizzato indica che le chiavi corrispondono in base a tale trasformazione. Non certifica che i file originali siano identici in byte o semanticamente intercambiabili.
La modalità Spazio bianco diagnostica gli spazi finali, mentre le terminazioni di riga sono già normalizzate
La differenza di testo non converte file, configura Git, modifica le impostazioni dell'editor o espone byte esadecimali. Accetta stringhe incollate e riporta operazioni sulla riga. I consigli su `.gitattributes`, `core.autocrlf` o sulla riparazione della codifica appartengono a strumenti il cui comportamento può essere verificato separatamente.
Lo strumento inoltre non è in grado di distinguere il modo in cui un carattere invisibile è entrato nel testo. Un formattatore, appunti, decodificatore o una modifica manuale possono produrre la stessa stringa. Utilizza il confronto per individuare la riga, quindi ispeziona la pipeline di origine prima di assegnare una causa.
Conclusione: controlla gli invisibili prima di incolpare l'autore: riassume il percorso diagnostico e nota il confronto eseguito nel tuo browser, in modo che i file sensibili rimangano sul tuo computer
Controlla gli invisibili in un ordine fisso: finali, spazi bianchi finali o interni, quindi i caratteri speciali iniziali. I test di ToolAcre danno un risultato sicuro per la prima categoria e le sue opzioni aiutano a isolare la seconda. Il terzo potrebbe aver bisogno di un ispettore dei personaggi al di fuori di questo percorso.
La divisione della linea lato browser fa sì che le differenze finali multipiattaforma scompaiano in base alla progettazione. Ciò è conveniente, ma significa anche che questo strumento non può dimostrare che due file sorgente utilizzano gli stessi byte fisici di nuova riga. Scegliere un'utilità in grado di riconoscere i byte quando è necessario preservare una rappresentazione esatta del cavo o del repository.