CRLF vs. LF su Windows: convertire, configurare ed evitare problemi di progetto

Se lavori in Windows e alterni progetti con persone di Linux o macOS, prima o poi ti imbatti nell'eterna battaglia CRLF contro LFA volte sembra magia nera: modifichi un file, non cambi nulla di "visibile" e Git contrassegna metà del file come modificato. Non preoccuparti, non è stregoneria; è... terminazioni di riga giocare contro di te.

Per risparmiarti mal di testa, è utile capire cosa c'è sotto e come regolarsi Git, i tuoi editor e i tuoi strumenti in modo che ogni file arrivi "pulito" al repository, senza modifiche fantasma o strani errori in CI/CD o negli script. In questa guida ti spiego, in dettaglio e conciso, come convertire, configurare e normalizzare CRLF e LF su Windows senza perdere il tempo.

Cosa sono LF e CRLF e perché sono importanti?

Le terminazioni di riga sono caratteri di controllo che delimitano ogni riga in un file di testo: LF (\n, ASCII 10) y CRLF (\r\n, ASCII 13+10)Sui sistemi Unix-like (Linux, macOS) viene utilizzato LF, mentre Windows utilizza CRLF ereditato dalle stampanti e dalle macchine da scrivere: prima il ritorno a capo (CR), poi l'avanzamento riga (LF).

La scelta non è estetica: passare da un formato all'altro può causare differenziali artificiali, script che falliscono con "comando non trovato", pipeline che si bloccano quando si eseguono file salvati con CRLF su Linux o editor che visualizzano tutto su una singola riga. Sì, apri un file .sh con CRLF in Bash e puoi prenderti un bello spavento.

Per concludere, Unicode riconosce più separatori (NEL U+0085, LS U+2028, PS U+2029, VT U+000B, FF U+000C), ma nello sviluppo quotidiano il vero duello è CRLF contro LFTuttavia, sapere che esistono aiuta quando ci si imbatte in testi provenienti da mainframe o file strani che un editor più vecchio non interpreta bene.

Un'altra curiosità tecnica utile: un salto può essere trattato come separatore (tra le righe) o come terminatore (segna la fine). Questa sottigliezza spiega perché a volte si vede un'ultima riga "senza interruzioni" o righe vuote extra quando si combinano gli strumenti. Se hai bisogno di imparare come trova e sostituisci interruzioni di paragrafo, fate attenzione, perché alcuni analizzatori si aspettano una cosa o l'altra.

Differenze per sistema e problemi tipici

In Windows, la cosa normale è CRLF; su Linux e macOS, LFQuesto conflitto è immediatamente evidente in un team misto: qualcuno modifica un file con il proprio sistema, lo salva e il diff viene riempito con modifiche che in realtà sono solo terminazioni di rigaA livello pratico, complica i controlli e contamina la tua storia clinica.

Ci sono anche effetti collaterali: a copione con CRLF in esecuzione in un ambiente Unix può fallire con errori criptici, oppure in CI un'attività si interrompe perché una shell interpreta male i ritorni. Al contrario, l'apertura di un file con solo LF in editor più vecchi su Windows può appiattiscilo in una linea.

Fai attenzione agli strumenti di integrazione continua come Jenkins o GitHub Actions: se la build viene eseguita su Linux ma carichi file con terminazioni di riga incoerenti, puoi rompere la conduttura Anche se "tutto funziona sulla mia macchina", più di una persona ha perso ore per questo motivo.

La buona notizia è che esiste una ricetta chiara: stabilire una convenzione e farla rispettare. gli strumenti lo applicano da soliCiò avviene tramite Git e il tuo editor. E se il danno è già fatto, rinormalizzare il repo.

A proposito, gli editor moderni come VS Code mostrano il tipo di salto nella barra di stato e consentono di modificarlo al volo; è una vera salvezza quando si individuano file "cross-cut" e si desidera mettere le cose in ordine velocemente, o quando ne hai bisogno evitare interruzioni di pagina e formattazioni inaspettate quando si incolla del testo nei documenti.

Git e terminazioni di riga: core.autocrlf e .gitattributes

Git può convertire automaticamente le terminazioni di riga per mantenere pulita la cronologia ed evitare spiacevoli sorprese. La chiave è l'opzione core.autocrlf, che devi capire bene prima di toccarlo, e sapere che la configurazione può essere a livello globale o locale dal repository (regole locali).

Controlla le tue impostazioni globali con -globale e ricorda che il repository potrebbe avere un valore diverso da quello prevalente. Per visualizzare tutto globalmente, usa git config –list –globalSe noti un comportamento strano nel repository, controlla il valore locale e dargli la priorità secondo ciò di cui hai bisogno.

Modalità Core.autocrlf in termini pratici (Windows vs Unix): vero si converte in CRLF al momento del checkout e torna a LF al momento del commit; ingresso converti in LF solo al momento del commit (ottimo su Linux/macOS); falso non tocca nulla (e di solito è una soluzione rapida se c'è un team misto). In Windows, la cosa più sensata da fare è vero se non vuoi sorprese.

comandi utile per regolare e ripulire la situazione del tuo repository senza rovinarla troppo: se vuoi che il repository utilizzi il valore globale, eliminazione la chiave locale; se preferisci forzare un valore in quel repository, impostalo senza -globalePer correggere i file già mischiati, rinormalizzare e confermare insieme le modifiche di fine riga.

git config --list --global
# Ver el valor global efectivo

git config --unset core.autocrlf
# Quitar el valor local y heredar el global

git config core.autocrlf true
# Fijar el valor solo en el repo actual (Windows)

git add --renormalize .
# Recorrerá el repo y homogeneizará line endings según la config

git commit -m 'Homogeneizados los cambios de línea'
# Sube un solo commit de normalización

Ma c'è qualcosa di ancora meglio: un .gitattributes nella radice che viaggia con il codice. Con la regola * testo=auto puoi dire a Git di rilevare i file di testo e gestire le interruzioni di riga di conseguenza (LF nel repository; CRLF nella copia di lavoro di Windows, se applicabile). Puoi anche fare delle regolazioni più precise tramite estensione, ad esempio forzando Git a gestire le nuove righe di conseguenza. .sln I caratteri di Visual Studio vengono sempre mantenuti come CRLF.

* text=auto
# Homogeneiza automáticamente (LF en el repo)

*.sln text eol=crlf
# Asegura CRLF en soluciones de Visual Studio

Quando introduci .gitattributes in un repository già attivo, non dimenticare di git add –renormalize . e raggruppando i commit. In questo modo, eviti che ogni collaboratore generi il proprio "mega-commit di pulizia". È uno di quei compiti che si fanno una volta sola e ti toglie i problemi durante gli anni.

Configurare l'editor: VS Code, EditorConfig e Visual Studio

Anche il tuo editor dipinge molto. In Codice VS. È possibile impostare l'interruzione di riga dalla barra di stato o con l'opzione file.eolSe il tuo progetto usa LF, selezionalo e il gioco è fatto; l'editor lo salverà in questo modo, senza che tu debba procedere file per file. È veloce e ti risparmia differenze rumorose.

Se tutti nel team utilizzano un editor diverso, incorporalo EditorConfig (.editorconfig) alla radice è una manna dal cielo: definisce regole come terminazioni di riga, codifica e spazi/tabulazioni in modo coerente. La maggior parte degli editor moderni lo rispetta e si integra in modo fenomenale con Git e CI.

Per chi usa Di Visual Studio, c'è un pannello specifico per salvare con una codifica e un'interruzione di riga specifiche (Opzioni di salvataggio avanzate). Puoi accedere al flusso File > Salva con nome > menu a discesa Salva > Salva con codifica, e anche il luogo Opzioni di salvataggio avanzate direttamente nel menu File per un accesso rapido.

1. apre Strumenti > Personalizza.
2. Nella scheda comandi, scegli Barra dei menu e selezionare archivio.
3. stampa aggiungi comando, categoria archivioe aggiungi Opzioni di salvataggio avanzate.
4. Riposizionare con Carica/Scarica e chiudilo. Ecco fatto.

Con Visual Studio, potresti anche incontrare file che hanno altri separatori (NEL, LS, PS). L'IDE cercare di normalizzarli Quando rileva incongruenze, ti chiederà istruzioni. Mantenere .gitattributes e le opzioni di salvataggio impostate correttamente impedisce che il tuo progetto si riempia di "casi esotici".

Oltre CRLF e LF: NEL, LS, PS e compagnia

Unicode considera alcuni punti di codice aggiuntivi come terminazioni di riga: NEL (U+0085), LS (U+2028) y PS (U+2029), Plus VT (U+000B) y FF (U+000C)Non sono comuni nei progetti app/web, ma compaiono in Mainframe IBM (EBCDIC) e in alcuni documenti elaborati con strumenti più vecchi o di nicchia.

Per compatibilità, Unicode replica i vecchi controlli ASCII con lo stesso valore numerico (CR e LF) e ne aggiunge di nuovi per conversioni senza perdita di dati tra codifiche (ad esempio, mappatura EBCDIC NL in Unicode NEL). Se si ottiene un file "strano", un editor moderno di solito mostrerà o chiederà normalizar.

carattere	RIPARARE CENTRALINA ABS INFINITI	Unicode
CR LF	Ritorno + anticipo	U+000D + U+000A
LF	Avanzamento riga	U + 000A
NEL	Riga successiva	U + 0085
LS	Separatore di riga	U + 2028
PS	Separatore di paragrafo	U + 2029

Nelle versioni precedenti del Blocco note di Windows non è nemmeno LF Stava andando bene; oggi il supporto è molto migliore, ma NEL è ancora problematico in alcuni ambienti. Pertanto, per repository e CI, mantenete tutto in LF nel repo e lasciare a Git/editor il CRLF della copia di lavoro su Windows è la mossa vincente.

Linguaggi di programmazione e interruzioni di riga (\r, \n e trap)

Nelle stringhe di testo, molti linguaggi consentono le sequenze di escape: \n = LF, \r = CRIn questo modo, quando necessario, si compone CRLF come \r\n, oppure si inserisce un LF "pulito" con \n. Ma attenzione, perché non tutti i runtime si comportano allo stesso modo.

Casi da tenere a mente: in Java, oltre a \r e \n, hai %n (formattatori) e System.lineSeparator() per ottenere l'interruzione di linea del sistema in modo portabile; in C#, Ambiente.NuovaRiga fa lo stesso; in PHP ci PHP_EOL; In Python, os.linesepSe vuoi stampare in base alla piattaforma, usa quelle costanti invece di sposare CRLF.

Attenzione speciale con C e C ++: In modalità testo, la sequenza \n può essere mappata all'interruzione di riga del sistema (su Windows, CRLF) e se si stampa \r\n si potrebbe finire per generare CRCRLFIn modalità binaria, la cosa è letterale. Questa sottigliezza coglie di sorpresa molti utenti quando compilano su Windows e testano su Linux.

En JavaScript / TypeScript, \n è solitamente sufficiente per la maggior parte degli usi, ma se si elabora l'input di utenti Windows si vedrà \r\n e sarà necessario normalizzare quando si interrompono le righe. Inoltre, quando si genera HTML, il layout finale è controllato da i tag (p., br, p, h2…), non i caratteri \r o \n.

// C#
var s1 = "Primera\nSegunda";            // LF explícito
var s2 = "Primera" + Environment.NewLine + "Segunda"; // Salto del sistema

// Java
String a = "Uno\r\nDos";                 // CRLF explícito
String b = "Uno" + System.lineSeparator() + "Dos";    // Portátil

// Python
s = 'Linea1' + os.linesep + 'Linea2'

// JavaScript
const t = 'L1\nL2'; // Normaliza entrada si viene con \r\n

Se generi traffico di rete, ricorda che protocolli come HTTP, SMTP, FTP o IRC sono esaustivi: le intestazioni e molte linee di controllo vanno con CRLF Sì o sì. Niente “invenzioni”: adatta l’output all’RFC o troverai server che rifiutare le richieste.

Come rilevare e convertire in modo affidabile le terminazioni di riga

Non esiste un "BOM" che ti dica il tipo di interruzione di riga in un file: devi guarda i byteIn pratica, gli strumenti contano CR (0x0D) e LF (0x0A) e ne osservano gli schemi: se appaiono accoppiati, di solito è CRLF; se appare solo 0x0A, è LF; se c'è una miscelazione incoerente, si ha un miscuglio che dovrebbe essere risolto.

Alcuni editor lo rilevano e ti avvisano; VS Code lo visualizza nella barra di stato; Visual Studio potrebbe offrirti di normalizzarlo. In Git, il passaggio sicuro è definire .gitattributes e, se opportuno, rinormalizzare per allineare l'intero albero alla policy. Il tuo repository (e le tue revisioni) te ne saranno grati.

E se lavorassi con "formati esotici"? Editor come Notepad++ e VS Code gestiscono bene CRLF e LF e di solito li identificano LS/PSPer i casi NEL ed EBCDIC, a volte dovrai passare attraverso un conversione precedente di codifica oltre all'interruzione di riga.

La strategia vincente nella maggior parte dei progetti è semplice: salvare nel repository con LF, consente la conversione automatica in Windows e blocca le eccezioni occasionali con eol=crlf per i file che ne hanno bisogno (ad esempio, .sln). Il resto sono spaventi evitabili.

Repository con interruzioni di riga miste: come risolvere il problema

È molto tipico: parti del codice provengono da Linux (LF) e altre sono state modificate su Windows (CRLF). Il risultato è un albero con righe miste, diff illeggibili e persone che si chiedono perché il loro script non si avvia oggi. mettere le cose in ordine.

Pianifica veloce e sicuro:

1. Inserisci .gitattributes con * testo=auto e regole specifiche se necessario (ad esempio, *.sln testo eol=crlf).
2. Correre git add –renormalize . per far sì che Git attraversi il repository e regoli le interruzioni di riga in base alle regole.
3. Fai un singolo commit con un messaggio chiaro (ad esempio, "Modifiche alla linea omogeneizzata").
4. Informa il team e chiedi tirare prima di procedere per ridurre al minimo i conflitti.

Se hai script sensibili (sh, py, ecc.) assicurati che siano salvati con LF e il tutto non è deformato. Puoi forzarlo con i pattern in .gitattributes o rivederlo nel tuo editor prima di eseguire il commit.

Per Visual Studio, se rileva salti incoerenti, suggerirà la normalizzazione. Accetta, rivedi la differenza e allegala il commit di rinormalizzazione precedente in modo che tutto sia rotondo.

Da quel momento in poi, con .gitattributes e core.autocrlf impostati correttamente, sono finiti le patch "questa volta è passato attraverso CRLF". E se qualcuno apre il progetto su Linux o macOS, tutto rimarrà uguale perché i file nel repository vengono salvati con LF.