kodowanie znaku nowej linii

Kodowanie znaku nowej linii to sposób oznaczania końca wiersza, różniący się między systemami Windows, Unix i macOS.

Jak oznaczany jest koniec wiersza w pliku tekstowym

Kodowanie znaku nowej linii określa, w jaki sposób zapisany jest koniec jednego wiersza i początek następnego w pliku tekstowym. Nie chodzi o pojedynczy uniwersalny znak rozpoznawany identycznie przez każdy system operacyjny, lecz o ustaloną sekwencję bajtów interpretowaną przez program zapisujący lub odczytujący dane. Najczęściej spotykane oznaczenia to LF, CR oraz CRLF. LF pochodzi od angielskiego Line Feed i ma wartość szesnastkową 0A. CR oznacza Carriage Return i ma wartość 0D. CRLF jest dwu-bajtową sekwencją złożoną kolejno z CR i LF, czyli 0D 0A.

Współczesne systemy Unix i Linux standardowo zapisują koniec wiersza jako LF. Tak samo postępuje większość narzędzi używanych w środowiskach uniksowych, w tym wiele kompilatorów, interpreterów i programów pracujących z kodem źródłowym. Windows typowo używa sekwencji CRLF. Starsze systemy Apple, w szczególności klasyczny Mac OS, stosowały sam znak CR, ale współczesny macOS, którego podstawą jest system uniksowy, używa LF. W efekcie plik utworzony na jednym urządzeniu może zawierać inne oznaczenie końca wiersza niż plik zapisany na innym urządzeniu, mimo że widoczny tekst wydaje się taki sam.

Różnica między LF, CR i CRLF w praktyce

Program odczytujący plik musi wiedzieć, jak rozpoznawać granice wierszy. Jeżeli oczekuje LF, a otrzyma CRLF, może potraktować znak CR jako dodatkowy znak znajdujący się na końcu tekstu. W niektórych narzędziach objawia się to widocznym symbolem ^M, pustymi znakami na końcu linii albo błędami podczas porównywania plików. Odwrotna sytuacja również może powodować problemy: program oczekujący dwóch bajtów CRLF może nie uznać samego LF za prawidłowy separator wierszy.

Różnice są szczególnie widoczne w skryptach i plikach konfiguracyjnych. Interpreter uruchamiany w systemie Unix może odczytać końcową część wiersza polecenia razem z niewidocznym znakiem CR. Wtedy komunikat błędu może wskazywać na nieistniejącą nazwę pliku, nieprawidłową opcję albo polecenie zakończone znakami specjalnymi. Podobny problem występuje w plikach wsadowych, skryptach powłoki, plikach JSON, CSV i prostych plikach konfiguracyjnych, jeśli program analizujący format nie usuwa automatycznie końcowego CR.

Sam wybór LF lub CRLF nie zmienia kodowania znaków takich jak litery, cyfry czy polskie znaki. Jest to osobna właściwość pliku, niezależna od kodowania UTF-8, UTF-16 albo starszych stron kodowych. Plik może więc jednocześnie być zapisany w UTF-8 i używać LF, w UTF-8 i używać CRLF albo w innym kodowaniu znaków z takim samym separatorem wierszy. Prawidłowa diagnoza wymaga rozdzielenia tych dwóch kwestii.

Rozpoznawanie i konwersja zakończeń linii

Rodzaj zakończeń linii można sprawdzić w edytorze tekstu, który pokazuje bieżący format pliku, albo w narzędziu analizującym niewidoczne znaki. W systemach Unix przydatne może być polecenie file, chociaż jego wynik zależy od rodzaju pliku i zawartości. Do dokładnej kontroli bajtów można użyć narzędzia xxd lub innego podglądu szesnastkowego. W takim widoku koniec wiersza zapisany jako LF będzie widoczny jako 0a, a wariant Windows jako para 0d 0a. W pliku zawierającym mieszane zakończenia linii różne sekwencje mogą występować obok siebie.

Konwersję należy wykonywać świadomie, po ustaleniu, jaki format wymaga program docelowy. W wielu edytorach można wybrać format zakończeń linii LF, CRLF albo czasami CR, a następnie zapisać cały plik ponownie. W systemie Unix narzędzie dos2unix usuwa znak CR z zakończeń CRLF, przekształcając je w LF, natomiast unix2dos wykonuje konwersję w przeciwnym kierunku. Istotne jest zachowanie kopii pliku przed masową zmianą, ponieważ automatyczna konwersja może mieć znaczenie dla plików, w których sekwencje CR lub LF są częścią danych, a nie separatorami wierszy.

W projektach programistycznych format można ujednolicić za pomocą ustawień edytora, pliku konfiguracyjnego repozytorium albo reguł kontroli wersji. Git potrafi normalizować zakończenia linii przy użyciu atrybutu text w pliku .gitattributes, a ustawienie core.autocrlf wpływa na sposób konwersji podczas pobierania i zapisywania plików. Nie jest to jednak uniwersalne rozwiązanie dla każdego formatu: pliki binarne, dane generowane automatycznie i pliki, w których znaczenie ma dokładna zawartość bajtowa, wymagają odrębnych reguł.

Diagnostyka plików z nieprawidłowym końcem wiersza

Przy diagnozowaniu problemu warto najpierw ustalić, który program utworzył plik, w jakim systemie ma on zostać użyty oraz jaki komunikat błędu pojawia się podczas odczytu. Następnie należy sprawdzić, czy wszystkie wiersze mają ten sam separator. Mieszanie LF i CRLF może powstać po częściowej edycji pliku w różnych programach. Widoczny tekst może nie ujawnić problemu, dlatego samo otwarcie dokumentu w podstawowym edytorze nie zawsze wystarcza. Pomocne jest włączenie podglądu znaków niedrukowalnych albo analiza pliku w trybie szesnastkowym.

Jeżeli po konwersji zakończeń linii problem nadal występuje, trzeba sprawdzić także kodowanie znaków, obecność znacznika BOM, dodatkowe spacje, tabulatory oraz sposób interpretowania cudzysłowów i znaków specjalnych. Błąd przypisywany „nowej linii” może w rzeczywistości wynikać z niezgodności kilku cech pliku. W plikach CSV znaczenie ma również separator kolumn, a w skryptach — dokładna składnia polecenia i położenie niewidocznych znaków. Konwersja powinna obejmować tylko właściwy plik i zostać zakończona ponownym uruchomieniem programu, który wcześniej zgłaszał problem.

Warszawskie Pogotowie Komputerowe wykonuje profesjonalną diagnostykę i naprawę laptopów oraz komputerów PC, gdy nieprawidłowe kodowanie końców linii jest częścią szerszego problemu z oprogramowaniem, plikami tekstowymi albo konfiguracją systemu. Analiza może obejmować sprawdzenie pliku, ustawień aplikacji i zgodności środowiska, a także przywrócenie prawidłowego odczytu dokumentów na używanym komputerze.