CRLF vs. LF ve Windows: Převod, konfigurace a vyhnutí se problémům s projektem

Pokud pracujete na Windows a střídáte se na projektech s lidmi na Linuxu nebo macOS, dříve či později narazíte na věčný boj CRLF vs. LF . Někdy to vypadá jako černá magie: upravíte soubor, nezměníte nic „viditelného“ a Git označí polovinu souboru jako upravenou. Nebojte se, není to čarodějnictví; jsou to konce řádků , které pracují proti vám.

Abyste si ušetřili bolesti hlavy, je užitečné pochopit, co se děje pod povrchem a jak upravit Git, editory a nástroje tak, aby každý soubor dorazil do repozitáře „čistý“, bez falešných změn nebo podivných chyb v CI/CD nebo skriptech. V této příručce podrobně a výstižně vysvětlím, jak převádět, konfigurovat a normalizovat CRLF a LF ve Windows bez ztráty času.

Co jsou LF a CRLF a proč jsou důležité?

Konce řádků jsou řídicí znaky, které vymezují jednotlivé řádky v textovém souboru: LF (\n, ASCII 10) a CRLF (\r\n, ASCII 13+10) . Unixové systémy (Linux, macOS) používají LF , zatímco Windows používá CRLF kvůli jeho odkazu z tiskáren a psacích strojů: nejprve návrat vozíku (CR), poté posun řádku (LF).

Volba není čistě estetická: přepínání z jednoho formátu do druhého může způsobit umělé rozdíly , skripty, které selžou s chybou „příkaz nenalezen“, pipeline, které selžou při spouštění souborů uložených pomocí CRLF v Linuxu, nebo editory, které zobrazují vše na jednom řádku. Ano, otevření souboru .sh s CRLF v Bashu může být nepříjemným překvapením.

Abychom to zaokrouhlili, Unicode rozpoznává více oddělovačů (NEL U+0085, LS U+2028, PS U+2029, VT U+000B, FF U+000C), ale v každodenním vývoji se skutečný boj odehrává mezi CRLF a LF . I tak je znalost jejich existence užitečná, když narazíte na text na mainframe nebo neobvyklé soubory, které starší editor dobře neinterpretuje.

Další užitečný technický detail: zalomení řádku lze považovat za oddělovač (mezi řádky) nebo za terminátor (označující konec). Tato jemnost vysvětluje, proč se při kombinaci nástrojů někdy zobrazí poslední řádek bez zalomení nebo s prázdnými řádky navíc. Pokud se potřebujete naučit, jak najít a nahradit zalomení odstavců , mějte na paměti, že některé analyzátory očekávají jednu nebo druhou věc.

Rozdíly mezi systémy a typické problémy

Ve Windows je standardem CRLF ; v Linuxu a macOS je to LF . Tento rozdíl je na smíšeném systému okamžitě patrný: někdo upraví soubor ve svém systému, uloží ho a soubor diff se zaplní změnami, které jsou ve skutečnosti jen zakončením řádků . V praxi to komplikuje revize a znečišťuje historii.

Existují také vedlejší účinky: skript s CRLF spuštěný v prostředí Unixu může selhat s kryptickými chybami nebo v CI může úloha přerušit, protože shell špatně interpretuje návratové hodnoty. Naopak otevření souboru pouze s LF ve starších editorech ve Windows ho může zploštit do jednoho řádku.

Buďte opatrní s nástroji pro kontinuální integraci, jako je Jenkins nebo GitHub Actions: pokud sestavení běží na Linuxu, ale nahrajete soubory s nekonzistentními konci řádků, můžete přerušit proces, i když „všechno na mém počítači funguje“. Mnoho lidí kvůli tomu ztratilo hodiny.

Dobrou zprávou je, že existuje jasné řešení: zavést konvenci a nechat nástroje, aby ji aplikovaly automaticky . To zahrnuje Git a váš editor. A pokud už je škoda napáchána, renormalizujte repozitář.

Mimochodem, moderní editory jako VS Code zobrazují typ zalomení ve stavovém řádku a umožňují jej měnit za chodu; je to záchrana, když zjistíte „křížově odkazované“ soubory a chcete rychle změnit jejich pořadí , nebo když se potřebujete vyhnout neočekávaným zalomením stránek a formátování při vkládání textu do dokumentů.

Git a konce řádků: core.autocrlf a .gitattributes

Git dokáže automaticky převádět konce řádků, aby historie zůstala čistá a vyhnul se překvapením. Klíčem je parametr ` core.autocrlf` , kterému byste měli před úpravou dobře porozumět a uvědomit si, že konfigurace může být globální nebo specifická pro daný repozitář (lokální nastavení má přednost).

Zkontrolujte si globální konfiguraci pomocí parametru `--global` a nezapomeňte, že repozitář může mít jinou hodnotu, která má přednost. Chcete-li zobrazit vše globálně, použijte `git config --list --global` . Pokud v repozitáři zaznamenáte neobvyklé chování, zkontrolujte lokální hodnotu a upřednostněte ji podle svých potřeb.

Režimy Core.autocrlf v praxi (Windows vs. Unix): `true` převádí na CRLF při checkoutu a zpět na LF při commitu; `input` převádí na LF pouze při commitu (ideální na Linuxu/macOS); `false` nedělá nic (a často je to krátkodobé řešení dlouhodobých problémů na smíšených systémech). Ve Windows je ` true` nejrozumnější volbou , pokud se chcete vyhnout překvapením.

Užitečné příkazy pro úpravu a čištění repozitáře bez přílišného komplikování: pokud chcete, aby repozitář používal globální hodnotu, odeberte lokální klíč; pokud chcete v repozitáři vynutit hodnotu, nakonfigurujte jej bez parametru `--global` . Pro opravu smíšených souborů proveďte renormalizaci a commit, přičemž změny na konci řádku seskupte.

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

Ale existuje něco ještě lepšího: soubor .gitattributes v kořenovém adresáři, který je dodáván s kódem. Pomocí pravidla *text=auto řeknete Gitu, aby detekoval textové soubory a správně zpracovával zalomení řádků (LF v repozitáři; CRLF v pracovní kopii Windows, pokud je to relevantní). A můžete to doladit pomocí rozšíření, např. vynutit, aby soubory .sln Visual Studia vždy používaly CRLF.

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

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

Když přidáváte soubor `.gitattributes` do existujícího repozitáře, nezapomeňte použít příkaz `git add --renormalize` a seskupit commit. Tím zabráníte každému přispěvateli ve vytváření vlastního „mega-commit cleanupu“. Je to jeden z těch úkolů, které uděláte jednou a ušetří vám starosti na roky.

Konfigurace editoru: VS Code, EditorConfig a Visual Studio

Velkou roli hraje i váš editor. Ve VS Code můžete nastavit zalomení řádků ze stavového řádku nebo pomocí volby `files.eol` . Pokud váš projekt používá zalomení řádků, jednoduše ji vyberte a je vše připraveno; editor se automaticky uloží, aniž byste museli procházet soubor po souboru. Je to rychlé a vyhnete se hlučným rozdílům.

Pokud každý v týmu používá jiný editor, přidání EditorConfig (.editorconfig) do kořenového adresáře je záchranou: konzistentně definuje pravidla, jako je ukončení řádků, kódování a nastavení mezer/tabulátoru. Většina moderních editorů to respektuje a bezproblémově se integruje s Gitem a CI.

Pro uživatele Visual Studia je k dispozici vyhrazený panel pro ukládání s určitým kódováním a zalomeními řádků (Rozšířené možnosti ukládání). K němu se dostanete přes Soubor > Uložit jako > rozbalovací nabídka Uložit > Uložit s kódováním nebo umístěním Rozšířených možností ukládání přímo do nabídky Soubor pro rychlý přístup.

1. Otevřeno Nástroje > Přizpůsobit.
2. Na kartě Příkazyvybrat Lišta menu a vyberte archiv.
3. lis Přidat příkaz, kategorie archiva dodává Pokročilé možnosti ukládání.
4. Přemístit pomocí Nahrát/Stáhnout a zavřete to. Máte to připravené.

Visual Studio se může setkat i se soubory s různými oddělovači (NEL, LS, PS). IDE se je pokusí normalizovat, když zjistí nekonzistence, a zobrazí výzvu k zadání pokynů. Správná konfigurace atributů .git a možností ukládání zabrání tomu, aby se váš projekt zaplnil neobvyklými případy.

Za hranicemi CRLF a LF: NEL, LS, PS a spol.

Unicode považuje určité další kódové body za zakončení řádků: NEL (U+0085) , LS (U+2028) a PS (U+2029) , kromě VT (U+000B) a FF (U+000C) . Tyto nejsou běžné v aplikačních/webových projektech, ale objevují se v mainframech IBM (EBCDIC) a v některých dokumentech zpracovaných staršími nebo specializovanými nástroji.

Pro zajištění kompatibility replikuje Unicode standardní ovládací prvky ASCII se stejnými číselnými hodnotami (CR a LF) a přidává nové pro bezztrátové převody mezi kódováními (např. mapování EBCDIC NL na Unicode NEL). Pokud obdržíte „podivný“ soubor, moderní editor jej obvykle zobrazí nebo vás vyzve k jeho normalizaci.

Charakter	popis	Unicode
ČR LF	Vrácení + záloha	U+000D + U+000A
LF	Posun řádku	U+000A
NEL	Další řádek	U + 0085
LS	Oddělovač řádků	U + 2028
PS	Oddělovač odstavců	U + 2029

Ve starších verzích programu Poznámkový blok ve Windows se ani LF nezobrazoval správně; dnes je podpora mnohem lepší, ale NEL je v některých prostředích stále problematický. Proto je pro repozitáře a CI/CD vítěznou strategií ponechat vše ve formátu LF v repozitáři a ponechat CRLF pracovní kopie Gitu/editorům ve Windows.

Programovací jazyky a zalomení řádků (\r, \n a trapy)

V řetězcích mnoho jazyků umožňuje escape sekvence: \n = LF , \r = CR . S nimi sestavíte CRLF jako \r\n , když je to potřeba, nebo vložíte „čistý“ LF pomocí \n. Ale buďte opatrní, protože ne všechna běhová prostředí se chovají stejně.

Případy, které je třeba mít na paměti: V Javě máte kromě \ry\n také %n (formátovací moduly) a System.lineSeparator() pro přenositelné získání systémového zalomení řádku; v C# totéž dělá Environment.NewLine ; v PHP je k dispozici PHP_EOL ; v Pythonu os.linesep . Pokud chcete tisknout podle platformy, použijte tyto konstanty místo spoléhání se na CRLF.

Zvláštní opatrnost je třeba věnovat jazykům C a C++ : v textovém režimu lze sekvenci \n namapovat na systémový znak zalomení řádku (CRLF ve Windows) a pokud vypíšete \r\n, můžete vygenerovat CRCRLF . V binárním režimu je to doslovný znak. Tato jemnost zaskočí mnoho lidí při kompilaci ve Windows a testování v Linuxu.

V JavaScriptu/TypeScriptu obvykle pro většinu použití postačuje znak \n, ale pokud zpracováváte vstup uživatele systému Windows, uvidíte znak \r\n a budete muset při zalomení řádků provést normalizaci. Navíc při generování HTML je konečné rozvržení řízeno tagy (p., br, p, h2…), nikoli znaky \r\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

Pokud generujete síťový provoz, nezapomeňte, že protokoly jako HTTP, SMTP, FTP a IRC jsou striktní: hlavičky a mnoho řídicích řádků musí používat CRLF . Žádné „vynálezy“: přizpůsobte svůj výstup RFC, jinak narazíte na servery, které vaše požadavky odmítnou.

Jak spolehlivě detekovat a převádět konce řádků

Neexistuje žádný jednotný „BOM“, který by vám řekl typ zalomení řádku v souboru: musíte se podívat na bajty . V praxi nástroje počítají CR (0x0D) a LF (0x0A) a analyzují jejich vzorce: pokud se objevují ve dvojicích, obvykle se jedná o CRLF; pokud se objeví pouze 0x0A, je to LF; pokud je zde nekonzistentní směs, máte nepořádek, který je třeba opravit.

Některé editory to detekují a varují vás; VS Code to zobrazuje ve stavovém řádku; Visual Studio může nabízet normalizaci. V Gitu je nejbezpečnějším přístupem definovat `.gitattributes` a v případě potřeby provést renormalizaci, aby se celý strom zarovnal s touto politikou. Váš repozitář (a vaše revize) vám poděkují.

Co když pracujete s „exotickými formáty“? Editory jako Notepad++ a VS Code dobře zvládají CRLF a LF a obvykle identifikují LS/PS . U NEL a EBCDIC budete někdy muset kromě zalomení řádku provést i předběžnou konverzi kódování.

Vítězná strategie pro většinu projektů je jednoduchá: uložit do repozitáře s parametrem LF , povolit automatickou konverzi ve Windows a blokovat výjimky pomocí parametru eol=crlf pro soubory, které to potřebují (např. .sln). Všechno ostatní je problém, kterému se lze vyhnout.

Repozitáře se smíšenými zalomeními řádků: jak opravit nepořádek

Je to velmi běžné: části kódu pocházejí z Linuxu (LF) a jiné části byly upraveny ve Windows (CRLF). Výsledkem je strom se spletenými řádky, nečitelnými rozdíly a lidmi, kteří se diví, proč se jejich skript dnes nespustí. Je čas dát věci do pořádku.

Rychlý a bezpečný plán :

1. Přidat .gitattributes s * text=automatický a v případě potřeby specifická pravidla (např. *.sln text eol=crlf).
2. Běh git add –renormalizovat. aby Git procházel repozitářem a upravoval zalomení řádků podle pravidel.
3. Make a jeden commit s jasnou zprávou (např. „Změny homogenizované linky“).
4. Sdělte to týmu a zeptejte se táhnout než se pustíte do minimalizace konfliktů.

Pokud máte citlivé skripty (sh, py atd.), ujistěte se, že jsou uloženy s LF a že soubor shebang není poškozen. Toto nastavení můžete vynutit pomocí vzorů v souboru .gitattributes nebo to zkontrolovat v editoru před commitem.

Ve Visual Studiu, pokud zjistí nekonzistentní skoky, navrhne normalizaci. Potvrďte, zkontrolujte rozdíl a poté potvrďte předchozí renormalizaci , abyste se ujistili, že vše funguje správně.

Od té chvíle, s řádně nakonfigurovanými .gitattributes a core.autocrlf, byly opravy typu „tentokrát to bylo zpracováno pomocí CRLF“ minulostí . A pokud někdo otevře projekt v Linuxu nebo macOS, vše zůstane stejné, protože soubory v repozitáři jsou uloženy s LF.