CRLF vs. LF på Windows: Konverter, konfigurer og undgå projektbesvær

Hvis du arbejder i Windows og skifter projekter med folk fra Linux eller macOS, før eller siden løber du ind i den evige kamp CRLF vs. LFNogle gange virker det som sort magi: du redigerer en fil, ændrer ikke noget "synligt", og Git markerer halvdelen af ​​filen som ændret. Bare rolig, det er ikke hekseri; det er linjeafslutninger spiller imod dig.

For at spare dig selv hovedpine, hjælper det at forstå, hvad der er nedenunder, og hvordan du justerer Git, dine editorer og dine værktøjer så hver fil ankommer "ren" til arkivet, uden fantomændringer eller mærkelige fejl i CI/CD eller scripts. I denne guide fortæller jeg dig detaljeret og præcist, hvordan du konverterer, konfigurerer og normalisere CRLF og LF på Windows uden at miste El tiempo.

Hvad er LF og CRLF, og hvorfor er de vigtige?

Linjeafslutninger er kontroltegn, der afgrænser hver linje i en tekstfil: LF (\n, ASCII 10) y CRLF (\r\n, ASCII 13+10)På Unix-lignende systemer (Linux, macOS) bruges det LF, mens Windows bruger CRLF arvet fra printere og skrivemaskiner: først linjeretur (CR), derefter linjeskift (LF).

Valget er ikke æstetisk: at skifte fra ét format til et andet kan forårsage kunstige diffs, scripts der fejler med "kommandoen blev ikke fundet", pipelines der går ned, når man kører filer gemt med CRLF på Linux, eller editorer der viser alt på en enkelt linje. Ja, man åbner en .sh med CRLF i Bash og du kan blive godt forskrækket.

For at runde det hele af genkender Unicode flere separatorer (NEL U+0085, LS U+2028, PS U+2029, VT U+000B, FF U+000C), men i den daglige udvikling er den virkelige duel CRLF vs. LFAlligevel hjælper det at vide, at de findes, når man støder på tekster fra mainframe eller mærkelige filer, som en ældre editor ikke fortolker godt.

En anden nyttig teknisk kuriositet: et spring kan behandles som separator (mellem linjerne) eller som terminator (markerer slutningen). Denne subtilitet forklarer, hvorfor man nogle gange ser en sidste linje uden afbrydelse eller ekstra tomme linjer, når man blander værktøjer. Hvis du har brug for at lære, hvordan man finde og erstatte afsnitskift, vær forsigtig, for nogle analysatorer forventer det ene eller det andet.

Forskelle efter system og typiske problemer

I Windows er det normale CRLFpå Linux og macOS, LFDette sammenstød er øjeblikkeligt mærkbart på et blandet team: nogen redigerer en fil med deres system, gemmer den, og diff'en er fyldt med ændringer, der faktisk er kun linjeafslutningerI praksis komplicerer det dine helbredsundersøgelser og forurener din historie.

Der er også bivirkninger: a script med CRLF, der kører i et Unix-miljø, kan det mislykkes med kryptiske fejl, eller i CI afbrydes en opgave, fordi en shell misfortolker returvarerne. Omvendt kan åbning af en fil med kun LF i ældre editorer på Windows flad det ud i en linje.

Vær forsigtig med værktøjer til kontinuerlig integration som Jenkins eller GitHub Actions: Hvis buildet kører på Linux, men du uploader filer med inkonsistente linjeafslutninger, kan du bryde rørledningen Selvom "alt virker på min maskine." Mere end én person har mistet timer på grund af dette.

Den gode nyhed er, at der er en klar opskrift: sæt en konvention, og få den til at ske. Værktøjerne anvender det aleneDet sker gennem Git og din editor. Og hvis skaden allerede er sket, så ved renormalisere repoen.

Forresten viser moderne editorer som VS Code jump-typen i statuslinjen og giver dig mulighed for at ændre den på farten; det er en livredder, når du ser "krydsklippede" filer og vil få tingene hurtigt i orden, eller når du har brug for det undgå sideskift og uventet formatering når du indsætter tekst i dokumenter.

Git og linjeafslutninger: core.autocrlf og .gitattributes

Git kan automatisk konvertere linjeafslutninger for at holde din historik ren og undgå ubehagelige overraskelser. Nøglen er indstillingen. kerne.autocrlf, som du skal forstå godt, før du rører ved den, og vide, at konfigurationen kan være på niveauet global o lokale fra arkivet (lokale regler).

Tjek dine globale indstillinger med -global og husk at repoet kan have en anden værdi, der gælder. For at se alt globalt, brug git config –list –globalHvis du ser mærkelig opførsel i repoet, skal du kontrollere den lokale værdi og prioritér det alt efter hvad du har brug for.

Core.autocrlf-tilstande i praksis (Windows vs Unix): sand konverterer til CRLF ved checkout og tilbage til LF ved commit; indgang konverter kun til LF ved commit (godt på Linux/macOS); falsk rører ikke noget (og det er normalt en hurtig løsning, hvis der er et blandet team). I Windows er det mest fornuftige at gøre sand hvis du ikke ønsker overraskelser.

kommandoer nyttigt til at justere og rydde op i din repository-situation uden at rode for meget med det: hvis du vil have, at repository'et bruger den globale værdi, elimine den lokale nøgle; hvis du foretrækker at gennemtvinge en værdi i det pågældende lager, skal du indstille den uden -globalFor at rette allerede blandede filer, skal du renormalisere og committe linjeafslutningsændringerne sammen.

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

Men der er noget endnu bedre: en .gitattributes i roden, der følger med koden. Med reglen * tekst=auto Du beder Git om at detektere tekstfiler og håndtere linjeskift i overensstemmelse hermed (LF i repo'en; CRLF i Windows-arbejdskopien, hvis relevant). Og du kan finjustere ved hjælp af udvidelsen, f.eks. tvinge Git til at håndtere linjeskift i overensstemmelse hermed. .sln af Visual Studio til altid at forblive CRLF.

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

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

Når du introducerer .gitattributes i et allerede aktivt repo, skal du ikke glemme at git add –renormaliser. og gruppering af commit'en. På denne måde undgår du, at hver bidragyder genererer sin egen "oprydningsmega-commit". Det er en af ​​de opgaver, man udfører én gang imellem det fjerner dine problemer i løbet af år.

Konfigurer editoren: VS Code, EditorConfig og Visual Studio

Din redaktør maler også meget. VS-kode Du kan indstille linjeskiftet fra statuslinjen eller med indstillingen filer.eolHvis dit projekt bruger LF, skal du vælge det, og det er det; editoren gemmer det på den måde, uden at du behøver at gå fil for fil. Det er hurtigt og sparer dig for støjende diffs.

Hvis alle på teamet bruger en forskellig editor, så inkorporer Redigerkonfiguration (.editorconfig) i roden er en gave fra himlen: den definerer regler som linjeafslutninger, kodning og mellemrum/tabulaturer konsekvent. De fleste moderne editorer respekterer den, og den integrerer fænomenalt med Git og CI.

For dem, der bruger Visual Studio, er der et specifikt panel til at gemme med en specifik kodning og linjeskift (Avancerede gemmeindstillinger). Du kan få adgang til Filer > Gem som > rullemenuen Gem > Gem med kodning, og også sted Avancerede gemmemuligheder direkte i menuen Filer for hurtig adgang.

1. åbner Værktøjer > Tilpas.
2. Tab kommandoervælge Menu linje og vælg Arkiv.
3. tryk Tilføj kommando, kategori Arkiv, og tilføjer Avancerede gemmemuligheder.
4. Omplacer med Upload/Download og luk den. Du har den klar.

Med Visual Studio kan du også støde på filer, der har andre separatorer (NEL, LS, PS). IDE'en forsøge at normalisere dem Når den registrerer uoverensstemmelser, vil den bede dig om instruktioner. Ved at holde .gitattributes og gem-indstillingerne korrekt indstillet, forhindres dit projekt i at blive fyldt med "eksotiske tilfælde".

Ud over CRLF og LF: NEL, LS, PS og selskab

Unicode betragter visse yderligere kodepunkter som linjeafslutninger: NEL (U+0085), LS (U+2028) y PS (U+2029), Plus VT (U+000B) y FF (U+000C)De er ikke almindelige i app-/webprojekter, men de optræder i IBM-mainframes (EBCDIC) og i nogle dokumenter behandlet med ældre eller nicheværktøjer.

For kompatibilitet replikerer Unicode de gamle ASCII-kontroller med den samme numeriske værdi (CR og LF) og tilføjer nye til tabsfri konverteringer mellem kodninger (f.eks. kortlægning EBCDIC NL til Unicode NEL). Hvis du får en "mærkelig" fil, vil en moderne editor normalt vise eller bede om normalisere.

I ældre versioner af Windows Notepad gør det ikke engang LF Det gik godt; i dag er supporten meget bedre, men NEL er stadig problematisk i nogle miljøer. Derfor, for repos og CI, hold alt inde LF i repoet og at lade Git/editors være CRLF'en for arbejdskopien på Windows er det vindende træk.

Programmeringssprog og linjeskift (\r, \n og traps)

I tekststrenge tillader mange sprog escape-sekvenser: \n = LF, \r = CRMed dette kan du komponere CRLF som \r\n når det er nødvendigt, eller indsætte en "ren" LF med \n. Men vær forsigtig, for ikke alle runtime-funktioner opfører sig ens.

Tilfælde at huske på: i Java, udover \r og \n, har du %n (formateringsprogrammer) og System.linjeSeparator() at få systemets linjeskift på en bærbar måde; i C#, Miljø.NyLine gør det samme; i PHP der PHP_EOL; I Python, os.linesepHvis du vil udskrive i henhold til platformen, skal du bruge disse konstanter i stedet for gifte sig med CRLF.

Særlig pleje med C og C ++I teksttilstand kan sekvensen \n knyttes til systemets linjeskift (på Windows, CRLF), og hvis du udskriver \r\n, kan du ende med at generere CRCRLFI binær tilstand er det bogstaveligt. Denne subtilitet overrasker mange, når de kompilerer på Windows og tester på Linux.

En JavaScript/TypeScript, \n er normalt tilstrækkeligt til de fleste formål, men hvis du behandler input fra Windows-brugere, vil du se \r\n, og du skal normalisere, når du bryder linjer. Når du genererer HTML, styres det endelige layout også af tags (p., br, p, h2…), ikke tegnene \r eller \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

Hvis du genererer netværkstrafik, skal du huske, at protokoller som f.eks. HTTP, SMTP, FTP eller IRC er udtømmende: overskrifterne og mange kontrollinjer følger med CRLF Ja eller ja. Ingen "opfindelser": juster outputtet til RFC'en, ellers finder du servere, der afvise anmodningerne.

Sådan registrerer og konverterer du pålideligt linjeafslutninger

Der er ingen "BOM", der fortæller dig typen af ​​linjeskift i en fil: du skal se på byteseneI praksis tæller værktøjerne CR (0x0D) og LF (0x0A) og ser deres mønstre: hvis de vises parvis, er det normalt CRLF; hvis kun 0x0A vises, er det LF; hvis der er inkonsekvent blanding, har du en sammensurium det burde være rettet.

Nogle editorer registrerer dette og giver dig besked; VS Code viser det i statuslinjen; Visual Studio kan tilbyde at normalisere det. I Git er det sikreste trin at definere .gitattributes og, hvis det er passende, renormaliser for at justere hele træet med politikken. Dit repository (og dine revisioner) vil takke dig for det.

Hvad hvis du arbejder med "eksotiske formater"? Editorer som Notepad++ og VS Code håndterer CRLF og LF godt og identificerer normalt LS/PSI tilfælde af NEL og EBCDIC skal du nogle gange gennemgå en forrige konvertering af kodning ud over linjeskiftet.

Vinderstrategien i de fleste projekter er enkel: gem i repositoriet med LF, aktiverer automatisk konvertering i Windows og blokerer lejlighedsvise undtagelser med eol=crlf for filer, der har brug for det (f.eks. .sln). Resten er undgåelige skræmmepunkter.

Repos med blandede linjeskift: Sådan retter du rodet

Det er meget typisk: dele af koden kommer fra Linux (LF), og andre er blevet ændret på Windows (CRLF). Resultatet er et træ med blandede linjer, ulæselige diffs, og folk der undrer sig over, hvorfor deres script ikke starter i dag. sætte orden.

Plan hurtigt og sikkert:

1. tilføjer .gitattributes med * tekst=auto og specifikke regler om nødvendigt (f.eks. *.sln tekst eol=crlf).
2. Løb git add –renormaliser. at få Git til at gennemgå repoet og justere linjeskift i henhold til reglerne.
3. Lav en enkelt commit med et klart budskab (f.eks. "Homogeniserede linjeændringer").
4. Lad teamet vide det, og spørg Træk før man går videre med at minimere konflikter.

Hvis du har følsomme scripts (sh, py osv.), skal du sørge for at de gemmes med LF og det hele er ikke deformeret. Du kan fremtvinge det med mønstre i .gitattributes eller gennemgå det i din editor, før du committer.

Hvis Visual Studio registrerer inkonsistente hop, foreslår det normalisering. Accepter, gennemgå diff'en, og send den med commit af renormalisering forrige, så alt er rundt.

Fra det øjeblik, med .gitattributes og core.autocrlf korrekt konfigureret, de er færdige "denne gang gik det gennem CRLF"-patcherne. Og hvis nogen åbner projektet på Linux eller macOS, forbliver alt det samme, fordi filerne i repoet gemmes med LF.

relateret artikel:

Microsoft Office-formater: Hvad de er, og hvornår skal man bruge hver enkelt?

Isaac

Passioneret forfatter om bytes-verdenen og teknologien generelt. Jeg elsker at dele min viden gennem skrivning, og det er det, jeg vil gøre i denne blog, vise dig alle de mest interessante ting om gadgets, software, hardware, teknologiske trends og mere. Mit mål er at hjælpe dig med at navigere i den digitale verden på en enkel og underholdende måde.