CRLF kontra LF w systemie Windows: Konwersja, konfiguracja i unikanie problemów z projektem

Jeśli pracujesz w systemie Windows i zamieniasz się projektami z osobami z Linux lub macOS, prędzej czy później wpadniesz w wieczną walkę CRLF kontra LFCzasami wydaje się to czarną magią: edytujesz plik, nie zmieniasz niczego „widocznego”, a Git oznacza połowę pliku jako zmodyfikowaną. Nie martw się, to nie czary; to… zakończenia linii grając przeciwko tobie.

Aby oszczędzić sobie bólu głowy, warto zrozumieć, co się dzieje pod spodem i jak to dostosować Git, Twoje edytory i Twoje narzędzia aby każdy plik dotarł do repozytorium „czysty”, bez urojonych zmian lub dziwnych błędów w CI/CD lub skryptach. W tym przewodniku szczegółowo i na temat wyjaśniam, jak konwertować, konfigurować i znormalizuj CRLF i LF w systemie Windows bez utraty El Tiempo.

Czym są LF i CRLF i dlaczego są ważne?

Zakończenia wierszy to znaki kontrolne, które ograniczają każdy wiersz w pliku tekstowym: LF (\n, ASCII 10) y CRLF (\r\n, ASCII 13+10). W systemach typu Unix (Linux, macOS) jest używany LF, podczas gdy Windows używa CRLF odziedziczone po drukarkach i maszynach do pisania: najpierw powrót karetki (CR), a następnie nowy wiersz (LF).

Wybór nie jest estetyczny: zmiana formatu może powodować sztuczne dyferencjały, skrypty, które kończą się niepowodzeniem z komunikatem „polecenie nie zostało znalezione”, potoki, które ulegają awarii podczas uruchamiania plików zapisanych z CRLF w systemie Linux, czy edytory wyświetlające wszystko w jednym wierszu. Tak, otwierasz plik .sh z CRLF w Bashu i… możesz się nieźle przestraszyć.

Podsumowując, Unicode rozpoznaje więcej separatorów (NEL U+0085, LS U+2028, PS U+2029, VT U+000B, FF U+000C), ale w codziennym rozwoju prawdziwy pojedynek toczy się CRLF kontra LF. Mimo to świadomość ich istnienia pomaga, gdy natrafisz na teksty od komputery mainframe lub dziwne pliki, których starszy edytor nie potrafi dobrze zinterpretować.

Kolejna przydatna ciekawostka techniczna: skok można traktować jako separator (między wierszami) lub jako terminator (oznacza koniec). Ta subtelność wyjaśnia, dlaczego czasami widzisz ostatnią linię bez końca lub dodatkowe puste linie podczas mieszania narzędzi. Jeśli chcesz się nauczyć, jak… znajdź i zamień podziały akapitów, bądź ostrożny, ponieważ niektórzy analitycy spodziewają się jednego lub drugiego.

Różnice między systemami i typowe problemy

W systemie Windows normalną rzeczą jest CRLF; na Linuksie i macOS, LF. To zderzenie jest natychmiast zauważalne w zespole mieszanym: ktoś edytuje plik w swoim systemie, zapisuje go, a różnica zostaje wypełniona zmianami, które w rzeczywistości są tylko zakończenia liniiW praktyce komplikuje to badania kontrolne i zanieczyszcza historię choroby.

Istnieją również skutki uboczne: scenariusz W środowisku Unix z CRLF może wystąpić błąd z tajemniczymi błędami, a w CI zadanie może zostać przerwane, ponieważ powłoka błędnie zinterpretuje zwracane dane. Z kolei otwarcie pliku zawierającego tylko LF w starszych edytorach w systemie Windows może spłaszczyć to w linię.

Należy zachować ostrożność w przypadku narzędzi do ciągłej integracji, takich jak Jenkins lub GitHub Actions: jeśli kompilacja działa w systemie Linux, ale przesyłasz pliki z niespójnymi zakończeniami linii, możesz przerwać rurociąg Mimo że „wszystko działa na moim komputerze”, niejedna osoba straciła z tego powodu wiele godzin.

Dobra wiadomość jest taka, że ​​istnieje jasna recepta: ustal konwencję i zrealizuj ją. narzędzia stosują je same. Dzieje się to za pośrednictwem Gita i edytora. A jeśli szkody już zostały wyrządzone, renormalizować repozytorium.

Nawiasem mówiąc, nowoczesne edytory, takie jak VS Code, pokazują typ skoku na pasku stanu i pozwalają na jego zmianę w locie. To ratunek, gdy zauważysz pliki z „podziałem na części” i chcesz je usunąć. szybko uporządkować rzeczylub kiedy potrzebujesz unikaj podziałów stron i nieoczekiwanego formatowania podczas wklejania tekstu do dokumentów.

Git i zakończenia linii: core.autocrlf i .gitattributes

Git może automatycznie konwertować zakończenia linii, aby zachować przejrzystość historii i uniknąć nieprzyjemnych niespodzianek. Kluczem jest opcja rdzeń.autocrlf, który musisz dobrze zrozumieć zanim go dotkniesz i wiedzieć, że konfiguracja może być na poziomie światowy o miejscowy ze repozytorium (lokalne zasady).

Sprawdź swoje ustawienia globalne za pomocą -światowy i pamiętaj, że repozytorium może mieć inną, obowiązującą wartość. Aby wyświetlić wszystko globalnie, użyj git config –list –globalJeśli zauważysz dziwne zachowanie w repozytorium, sprawdź wartość lokalną i nadać temu priorytet zgodnie z tym, czego potrzebujesz.

Tryby Core.autocrlf w praktyce (Windows vs Unix): prawdziwy konwertuje na CRLF przy wymeldowaniu i z powrotem na LF przy zatwierdzeniu; wkład konwertuj do LF tylko przy zatwierdzaniu (świetne na Linuksie/macOS); fałszywy niczego nie dotyka (i zazwyczaj jest to szybka naprawa, jeśli zespół jest mieszany). W systemie Windows najrozsądniej jest prawdziwy jeśli nie chcesz niespodzianek.

Polecenia przydatne do dostosowywania i czyszczenia sytuacji w repozytorium bez nadmiernego jej komplikowania: jeśli chcesz, aby repozytorium używało wartości globalnej, usunąć klucz lokalny; jeśli wolisz wymusić wartość w tym repozytorium, ustaw ją bez -światowyAby naprawić już pomieszane pliki, należy dokonać ponownej normalizacji i zatwierdzić zmiany zakończeń wierszy.

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 jest coś jeszcze lepszego: .gitattributes w katalogu głównym, który podróżuje z kodem. Z regułą * tekst=auto Możesz polecić Gitowi wykrywanie plików tekstowych i odpowiednie obsługiwanie podziałów wierszy (LF w repozytorium; CRLF w kopii roboczej systemu Windows, jeśli ma to zastosowanie). Możesz też dostroić to poprzez rozszerzenie, np. wymusić na Git odpowiednie obsługiwanie nowych wierszy. .sln aby kody programu Visual Studio zawsze pozostawały CRLF.

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

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

Wprowadzając .gitattributes do już istniejącego repozytorium, nie zapomnij o git add –renormalize . i grupowanie commitów. W ten sposób unikniesz sytuacji, w której każdy współautor generuje własny „mega-commit czyszczący”. To jedno z tych zadań, które wykonuje się raz, a potem… zabiera twoje problemy latami.

Konfigurowanie edytora: VS Code, EditorConfig i Visual Studio

Twój redaktor też dużo maluje. W Kod VS Podział wiersza można ustawić na pasku stanu lub za pomocą opcji pliki.eolJeśli Twój projekt korzysta z formatu LF, zaznacz go i gotowe; edytor zapisze go w ten sposób, bez konieczności przeglądania pliku po pliku. To szybkie i oszczędza Ci szumów różnicowych.

Jeżeli każdy w zespole używa innego edytora, włącz Konfiguracja edytora Plik (.editorconfig) to w istocie dar niebios: definiuje reguły takie jak zakończenia linii, kodowanie oraz spacje/tabulatory w sposób spójny. Większość współczesnych edytorów go szanuje, a ponadto fenomenalnie integruje się z Gitem i CI.

Dla tych, którzy używają visual Studio, istnieje specjalny panel do zapisywania z określonym kodowaniem i podziałem wiersza (Zaawansowane opcje zapisu). Możesz przejść do Plik > Zapisz jako przepływ > menu rozwijane Zapisz > Zapisz z kodowaniemi również miejsce Zaawansowane opcje zapisywania bezpośrednio w menu Plik, co umożliwia szybki dostęp.

1. Otwórz Narzędzia > Dostosuj.
2. W zakładce Poleceniawybierz Pasek menu i wybierz Archiwum.
3. prasa Dodaj polecenie, Kategoria Archiwumi dodaje Zaawansowane opcje zapisywania.
4. Zmień położenie za pomocą Prześlij/Pobierz i zamknij. Masz gotowe.

W programie Visual Studio możesz również napotkać pliki z innymi separatorami (NEL, LS, PS). IDE spróbuj je znormalizować Gdy wykryje niespójności, poprosi o instrukcje. Prawidłowe ustawienie atrybutów .git i opcji zapisu zapobiega nagromadzeniu się w projekcie „egzotycznych przypadków”.

Poza CRLF i LF: NEL, LS, PS i spółka

Unicode uznaje pewne dodatkowe punkty kodowe za zakończenia linii: NEL (U+0085), LS (U+2028) y PS (U+2029), oprócz VT (U+000B) y FF (U+000C). Nie są one powszechne w projektach aplikacji/sieci, ale pojawiają się w Komputery mainframe IBM (EBCDIC) oraz w niektórych dokumentach przetworzonych za pomocą starszych lub specjalistycznych narzędzi.

W celu zapewnienia zgodności Unicode replikuje stare kontrolki ASCII z tą samą wartością liczbową (CR i LF) i dodaje nowe, aby umożliwić bezstratną konwersję między kodowaniami (np. mapowanie EBCDIC NL do Unicode NEL). Jeśli otrzymasz „dziwny” plik, współczesny edytor zazwyczaj go pokaże lub poprosi o niego normalizować.

W starszych wersjach Notatnika systemu Windows nie jest to nawet możliwe LF Wyglądało dobrze; dziś wsparcie jest znacznie lepsze, ale NEL nadal jest problematyczny w niektórych środowiskach. Dlatego w przypadku repozytoriów i CI należy zachować wszystko w LF w repozytorium a pozostawienie w Git/editorach CRLF kopii roboczej w systemie Windows jest zwycięskim posunięciem.

Języki programowania i podziały wierszy (\r, \n i pułapki)

W ciągach tekstowych wiele języków dopuszcza stosowanie sekwencji ucieczki: \n = LF, \r = CRW tym przypadku, w razie potrzeby, komponujesz CRLF jako \r\n lub wstawiasz „czysty” LF za pomocą \n. Należy jednak zachować ostrożność, ponieważ nie wszystkie środowiska wykonawcze zachowują się tak samo.

Przypadki, o których należy pamiętać: w Java, oprócz \r i \n, masz %n (formatomaty) i System.lineSeparator() aby uzyskać podział wiersza systemu w sposób przenośny; w C#, Środowisko.Nowa linia robi to samo; w PHP tam PHP_EOL; W Python, os.linesep. Jeśli chcesz drukować zgodnie z platformą, użyj tych stałych zamiast poślubić CRLF.

Specjalna opieka z C i C ++:W trybie tekstowym sekwencję \n można zmapować na podział wiersza systemowego (w systemie Windows CRLF), a jeśli wydrukujesz \r\n, możesz wygenerować CRCRLFW trybie binarnym sprawa jest dosłowna. Ta subtelność zaskakuje wiele osób podczas kompilacji w systemie Windows i testowania w systemie Linux.

En JavaScript / TypeScript, \n zazwyczaj wystarcza do większości zastosowań, ale jeśli przetwarzasz dane wejściowe od użytkowników systemu Windows, zobaczysz \r\n i będziesz musiał znormalizować łamanie wierszy. Ponadto, podczas generowania kodu HTML, ostateczny układ jest kontrolowany przez Tagi (p., br, p, h2…), a nie znaki \r lub \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

Jeżeli generujesz ruch sieciowy, pamiętaj, że protokoły takie jak HTTP, SMTP, FTP lub IRC są wyczerpujące: nagłówki i wiele linii kontrolnych idą z CRLF Tak lub tak. Żadnych „wynalazków”: dostosuj wynik do RFC, albo znajdziesz serwery, które odrzucać prośby.

Jak niezawodnie wykrywać i konwertować zakończenia linii

Nie ma „BOM”, który wskazywałby rodzaj podziału wiersza w pliku: musisz spójrz na bajtyW praktyce narzędzia liczą CR (0x0D) i LF (0x0A) i widzą ich wzorce: jeśli pojawiają się w parze, zwykle jest to CRLF; jeśli pojawia się tylko 0x0A, jest to LF; jeśli występuje niespójne mieszanie, masz galimatias to powinno zostać naprawione.

Niektórzy edytorzy wykrywają to i powiadamiają Cię o tym; VS Code wyświetla to na pasku stanu; Visual Studio może zaproponować normalizację. W Gicie bezpiecznym krokiem jest zdefiniowanie .gitattributes i, jeśli to konieczne, zrenormalizuj całe drzewo, aby dostosować je do polityki. Twoje repozytorium (i Twoje wersje) będą Ci za to wdzięczne.

A co, jeśli pracujesz z „egzotycznymi formatami”? Edytory takie jak Notepad++ i VS Code dobrze radzą sobie z CRLF i LF i zazwyczaj je identyfikują. LS/PSW przypadku NEL i EBCDIC czasami konieczne będzie przejście przez poprzednia konwersja kodowania oprócz podziału wiersza.

W większości projektów zwycięska strategia jest prosta: zapisz w repozytorium za pomocą LF, umożliwia automatyczną konwersję w systemie Windows i blokuje sporadyczne wyjątki eol=crlf dla plików, które tego wymagają (np. .sln). Reszta to zagrożenia, których można uniknąć.

Repozytoria z mieszanymi podziałami wierszy: jak naprawić ten bałagan

To bardzo typowe: fragmenty kodu pochodzą z Linuksa (LF), a inne zostały zmodyfikowane w systemie Windows (CRLF). Rezultatem jest drzewo z pomieszanymi wierszami, nieczytelnymi różnicami i ludźmi zastanawiającymi się, dlaczego ich skrypt nie chce się dzisiaj uruchomić. zaprowadzić porządek.

Plan szybki i bezpieczny:

1. Dodaj .gitattributes z * tekst=auto i szczegółowe zasady, jeśli to konieczne (np. *.sln tekst eol=crlf).
2. Biegać git add –renormalize . aby Git przeszukał repozytorium i dopasował podziały wierszy zgodnie z regułami.
3. Zrób pojedyncze zatwierdzenie z jasnym przekazem (np. „Ujednolicone zmiany linii”).
4. Poinformuj zespół i zapytaj Ciągnąć przed przystąpieniem do minimalizowania konfliktów.

Jeśli posiadasz poufne skrypty (sh, py itp.), upewnij się, że są one zapisane LF a shebang nie jest zdeformowany. Możesz wymusić to za pomocą wzorców w .gitattributes lub przejrzeć w edytorze przed zatwierdzeniem.

W przypadku wykrycia niespójnych skoków w programie Visual Studio zasugeruje normalizację. Zaakceptuj, przejrzyj różnicę i dołącz do niej zatwierdzenie. renormalizacja poprzednie, aby wszystko było okrągłe.

Od tego momentu, po poprawnym skonfigurowaniu .gitattributes i core.autocrlf, są skończeni poprawki typu „tym razem przeszło przez CRLF”. A jeśli ktoś otworzy projekt na Linuksie lub macOS, wszystko pozostanie bez zmian, ponieważ pliki w repozytorium są zapisywane z użyciem LF.

Podobne artykuł:

Formaty pakietu Microsoft Office: czym są i kiedy każdego z nich używać

Isaac

Pisarz z pasją zajmujący się światem bajtów i technologii w ogóle. Uwielbiam dzielić się swoją wiedzą poprzez pisanie i właśnie to będę robić na tym blogu, pokazywać Ci wszystkie najciekawsze rzeczy o gadżetach, oprogramowaniu, sprzęcie, trendach technologicznych i nie tylko. Moim celem jest pomóc Ci poruszać się po cyfrowym świecie w prosty i zabawny sposób.