Nowa linia

Nowa linia wstawiona między słowami „Hello” i „world”

Nowa linia (często nazywana zakończeniem linii , końcem linii ( EOL ), następną linią ( NEL ) lub końcem linii ) to znak kontrolny lub sekwencja znaków kontrolnych w specyfikacjach kodowania znaków , takich jak ASCII , EBCDIC , Unicode itp. Ten znak, lub ciąg znaków, używany do oznaczenia końca wiersza tekstu i początku nowego.

Historia

W połowie XIX wieku, na długo przed pojawieniem się dalekopisów i dalekopisów, operatorzy alfabetu Morse'a lub telegrafiści wynaleźli i używali znaków alfabetu Morse'a do kodowania formatowania tekstu białych znaków w formalnych wiadomościach tekstowych. W alfabecie Morse'a do kodowania i wskazywania _ _ nowa linia lub nowa sekcja w oficjalnej wiadomości tekstowej.

Później, w dobie nowoczesnych dalekopisów , opracowano znormalizowane kody kontrolne zestawów znaków, aby pomóc w formatowaniu tekstu z białymi znakami. ASCII został opracowany jednocześnie przez Międzynarodową Organizację Normalizacyjną (ISO) i Amerykańskie Stowarzyszenie Normalizacyjne (ASA), przy czym ta ostatnia organizacja była poprzedniczką Amerykańskiego Narodowego Instytutu Normalizacyjnego (ANSI). W okresie od 1963 do 1968 projekty norm ISO wspierały użycie CR + LF lub samego LF jako nowej linii, podczas gdy projekty ASA obsługiwały tylko CR + LF .

Sekwencja CR + LF była powszechnie używana w wielu wczesnych systemach komputerowych, które przyjęły maszyny Teletype - zwykle Teletype Model 33 ASR - jako urządzenie konsolowe, ponieważ ta sekwencja była wymagana do ustawienia tych drukarek na początku nowej linii. Rozdzielenie nowej linii na dwie funkcje ukrywało fakt, że głowica drukująca nie mogła wrócić z prawej strony na początek następnej linii na czas, aby wydrukować następny znak. Każdy znak wydrukowany po CR często był drukowany jako smuga na środku strony, gdy głowica drukująca nadal przesuwała karetkę z powrotem do pierwszej pozycji. „Rozwiązaniem było uczynienie nowej linii dwoma znakami: CR , aby przesunąć karetkę do pierwszej kolumny i LF , aby przesunąć papier w górę.” W rzeczywistości często konieczne było wysłanie dodatkowych znaków — zbędnych CR lub NUL — które są ignorowane, ale dają głowicy drukującej czas na przesunięcie się na lewy margines Wiele wczesnych wyświetlaczy wideo wymagało również wielu znaków, aby przewinąć ekran.

W takich systemach aplikacje musiały komunikować się bezpośrednio z maszyną Teletype i postępować zgodnie z jej konwencjami, ponieważ koncepcja sterowników urządzeń ukrywających takie szczegóły sprzętowe przed aplikacją nie była jeszcze dobrze rozwinięta. Dlatego tekst był rutynowo komponowany, aby zaspokoić potrzeby dalekopisów. Większość systemów minikomputerowych firmy DEC korzystała z tej konwencji. CP/M używało go również do drukowania na tych samych terminalach, z których korzystały minikomputery. Stamtąd MS-DOS (1981) przyjął CR + LF CP /M aby była kompatybilna, a ta konwencja została odziedziczona przez późniejszy system operacyjny Windows firmy Microsoft .

Multics rozpoczął się w 1964 roku i wykorzystywał sam LF jako nową linię. Multics użył sterownika urządzenia do przetłumaczenia tego znaku na dowolną sekwencję potrzebną drukarce (w tym dodatkowe znaki dopełniające), a pojedynczy bajt był wygodniejszy do programowania. To, co wydaje się bardziej oczywistym wyborem — CR — nie zostało użyte, ponieważ CR zapewniało przydatną funkcję nadrukowywania jednej linii drugą w celu uzyskania efektów pogrubienia , podkreślenia i przekreślenia . Być może ważniejsze jest użycie LF jako terminator linii został już włączony do projektów ewentualnej normy ISO/IEC 646 . Unix podążał za praktyką Multics, a później systemy uniksopodobne podążyły za Unixem. Spowodowało to konflikty między systemami operacyjnymi Windows i podobnymi do systemu Unix , w wyniku których pliki utworzone w jednym systemie operacyjnym nie mogły zostać odpowiednio sformatowane lub zinterpretowane przez inny system operacyjny (na przykład skrypt powłoki UNIX napisany w edytorze tekstu systemu Windows, takim jak Notatnik ).

Reprezentacja

Pojęcia powrotu karetki (CR) i wysuwu wiersza (LF) są ze sobą ściśle powiązane i można je rozpatrywać osobno lub razem. W fizycznych nośnikach maszyn do pisania i drukarek potrzebne są dwie osie ruchu, „w dół” i „w poprzek”, aby utworzyć nową linię na stronie . Chociaż projekt maszyny (maszyny do pisania lub drukarki) musi uwzględniać je oddzielnie, abstrakcyjna logika oprogramowania może łączyć je razem jako jedno zdarzenie. Dlatego znak nowej linii w kodowaniu znaków można zdefiniować jako CR i LF połączone w jeden (powszechnie nazywane CR+LF lub CRLF ).

Niektóre zestawy znaków zawierają oddzielny kod znaku nowej linii. Na przykład EBCDIC oprócz kodów CR i LF udostępnia kod znaku NL . Unicode , oprócz kodów kontrolnych ASCII CR i LF , zapewnia również kod kontrolny „następnej linii” ( NEL ), a także kody kontrolne dla znaczników „separatora linii” i „separatora akapitu”.

Reprezentacja nowego wiersza w aplikacjach i systemie operacyjnym z jednym lub dwoma znakami kontrolnymi
System operacyjny	Kodowanie znaków	Skrót	wartość szesnastkowa	wartość dec	Sekwencja ewakuacyjna
Unix i Unix-podobne ( Linux , macOS , FreeBSD , AIX , Xenix itp.), Multics , BeOS , Amiga , RISC OS i inne	ASCII	LF	0A	10	\N
Microsoft Windows , DOS ( MS-DOS , PC DOS itp.), Atari TOS , DEC TOPS-10 , RT-11 , CP/M , MP/M , OS/2 , Symbian OS , Palm OS , Amstrad CPC i większość innych wczesnych systemów operacyjnych innych niż Unix i innych niż IBM		CR LF	0D 0A	13 10	\r\n
Maszyny 8-bitowe Commodore ( C64 , C128 ), Acorn BBC , ZX Spectrum , TRS-80 , seria Apple II , Oberon , klasyczny Mac OS , MIT Lisp Machine i OS-9		CR	0D	13	\R
QNX przed POSIX (wersja <4)		RS	1E	30	\036
Buforowane wyjście tekstowe Acorn BBC i RISC OS		LF CR	0A 0D	10 13	\n\r
8-bitowe maszyny Atari	ATASCII		9B	155
Systemy mainframe IBM , w tym z/OS ( OS/390 ) i IBM i ( OS/400 )	EBCDIC	NL	15	21	\025
ZX80 i ZX81 (komputery domowe firmy Sinclair Research Ltd )	użył określonego zestawu znaków innych niż ASCII	NOWA LINIA	76	118

EBCDIC - głównie systemy mainframe IBM , w tym z/OS ( OS/390 ) i IBM i ( OS/400 ) - używają NL (New Line, 0x15 ) jako znaku łączącego funkcje nowego wiersza i powrotu karetki. Odpowiednik znaku Unicode ( 0x85 ) nazywa się NEL (Next Line). EBCDIC ma również znaki kontrolne zwane CR i LF , ale wartość liczbowa LF ( 0x25 ) różni się od używanego przez ASCII ( 0x0A ). Ponadto niektóre warianty EBCDIC również używają NL , ale przypisują znakowi inny kod numeryczny. Jednak te systemy operacyjne używają systemu plików opartego na rekordach , w którym pliki tekstowe są przechowywane jako jeden rekord w wierszu. W większości formatów plików w rzeczywistości nie są przechowywane żadne terminatory linii.
Systemy operacyjne dla serii CDC 6000 zdefiniowały nowy wiersz jako dwa lub więcej sześciobitowych znaków o wartości zero na końcu 60-bitowego słowa. Niektóre konfiguracje definiowały również znak o wartości zerowej jako dwukropka , w wyniku czego wiele dwukropków mogło być interpretowanych jako znak nowej linii w zależności od pozycji.
RSX-11 i OpenVMS również używają systemu plików opartego na rekordach, który przechowuje pliki tekstowe jako jeden rekord w wierszu. W większości formatów plików w rzeczywistości nie są przechowywane żadne terminatory linii, ale Record Management Services może w przejrzysty sposób dodać terminator do każdej linii, gdy jest ona pobierana przez aplikację. Same rekordy mogą zawierać te same znaki terminatora linii, co w zależności od aplikacji może być uważane za cechę lub uciążliwość. RMS nie tylko przechowuje rekordy, ale także przechowuje metadane dotyczące separatorów rekordów w różnych bitach, co jeszcze bardziej komplikuje sprawę (ponieważ pliki mogą mieć rekordy o stałej długości, rekordy poprzedzone liczbą lub rekordy zakończone określonym znakiem ). Bity nie są ogólne, więc chociaż mogą to określić CR LF lub LF lub nawet CR jest terminatorem linii, nie mogą zastąpić żadnego innego kodu.
Stała długość linii była używana przez niektóre wczesne systemy operacyjne komputerów mainframe . W takim systemie zakładano na przykład niejawny koniec linii co 72 lub 80 znaków. Nie zapisano znaku nowej linii. Jeśli plik był importowany ze świata zewnętrznego, linie krótsze niż długość linii musiały być wypełnione spacjami, a linie dłuższe niż długość linii musiały zostać obcięte. Naśladowało to użycie kart perforowanych , na których każda linia była przechowywana na osobnej karcie, zwykle z 80 kolumnami na każdej karcie, często z kolejnymi numerami w kolumnach 73–80. Wiele z tych systemów dodało znak kontrolny karetki do początku następnego rekordu ; mogłoby to wskazywać, czy następny rekord był kontynuacją linii rozpoczętej przez poprzedni rekord, czy nową linią, czy też powinien nadrukować poprzednią linię (podobnie jak CR ) . Często był to normalny znak drukarski, taki jak # , którego nie można było użyć jako pierwszego znaku w wierszu. Niektóre drukarnie wczesnej linii interpretowały te znaki bezpośrednio w wysyłanych do nich zapisach.

Unikod

Standard Unicode definiuje liczbę znaków, które zgodne aplikacje powinny rozpoznawać jako terminatory linii:

LF : Wysuw wiersza, U+000A

VT : Zakładka pionowa , U+000B

FF : Wysuw strony , U+000C

CR : Powrót karetki , U+000D

CR + LF : CR ( U+000D ), a następnie LF ( U+000A )

NEL : Następna linia, U+0085

LS : Separator linii, U+2028

PS : Separator akapitów, U+2029

Może się to wydawać zbyt skomplikowane w porównaniu z podejściem takim jak konwersja wszystkich terminatorów linii na pojedynczy znak, na przykład LF . Jednak Unicode został zaprojektowany w celu zachowania wszystkich informacji podczas konwersji pliku tekstowego z dowolnego istniejącego kodowania na Unicode iz powrotem. Dlatego Unicode powinien zawierać znaki zawarte w istniejących kodowaniach.

Na przykład: NL jest częścią EBCDIC , która używa kodu 0x15 ; zwykle jest mapowany na Unicode NEL , 0x85 , który jest znakiem kontrolnym w zestawie kontrolnym C1. Jako taki jest zdefiniowany przez ECMA 48 i rozpoznawany przez kodowanie zgodne z ISO/IEC 2022 (co jest odpowiednikiem ECMA 35). Zestaw kontrolny C1 jest również zgodny z normą ISO-8859-1 . ^{[ potrzebne źródło ]} Podejście przyjęte w standardzie Unicode umożliwia transformację w obie strony z zachowaniem informacji, jednocześnie umożliwiając aplikacjom rozpoznawanie wszystkich możliwych typów terminatorów linii.

Rozpoznawanie i używanie kodów nowej linii większych niż 0x7F ( NEL , LS i PS ) nie jest często wykonywane. Są to wielokrotne bajty w UTF-8 , a kod dla NEL został użyty jako znak wielokropka ( … ) w Windows-1252 . Na przykład:

ECMAScript akceptuje LS i PS jako podziały linii, ale traktuje białe znaki U+0085 ( NEL ) zamiast podziału linii.
Windows 10 nie traktuje żadnego z NEL , LS ani PS jako podziału linii w swoim domyślnym edytorze tekstu, Notatniku .
gedit , domyślny edytor tekstu środowiska graficznego GNOME , traktuje LS i PS jako znaki nowej linii, ale nie dla NEL .
JSON dopuszcza znaki LS i PS w łańcuchach, podczas gdy ECMAScript przed ES2019 traktował je jako znaki nowej linii, a zatem nielegalną składnię.
YAML nie rozpoznaje ich już jako specjalnych od wersji 1.2, aby były kompatybilne z JSON .

Zwróć uwagę, że znaki specjalne Unicode U+2424 ( SYMBOL NOWEJ LINII , ␤ ), U+23CE ( SYMBOL POWROTU , ⏎ ), U+240D ( SYMBOL POWROTU KARNETU , ␍ ) i U+240A ( SYMBOL WYSUNIĘCIA WIERSZA , ␊ ) to glify przeznaczone do przedstawiania czytelnikowi dokumentu znaku widocznego dla użytkownika, a zatem nie są rozpoznawane jako nowa linia.

W językach programowania

Aby ułatwić tworzenie przenośnych programów, języki programowania zapewniają pewne abstrakcje dotyczące różnych typów sekwencji nowej linii używanych w różnych środowiskach.

Język programowania C udostępnia sekwencje specjalne „\n” (nowa linia) i „\r” (powrót karetki). Jednak nie muszą one być równoważne ze znakami kontrolnymi ASCII LF i CR . Standard C gwarantuje tylko dwie rzeczy:

Każda z tych sekwencji ucieczki jest mapowana na unikatową liczbę zdefiniowaną w implementacji, która może być przechowywana w pojedynczej wartości char .
Podczas zapisywania w pliku, węźle urządzenia lub gnieździe/fifo w trybie tekstowym , '\n' jest przezroczyście tłumaczone na natywną sekwencję nowej linii używaną przez system, która może być dłuższa niż jeden znak. Podczas czytania w trybie tekstowym natywna sekwencja nowej linii jest tłumaczona z powrotem na '\n' . W trybie binarnym nie jest wykonywana żadna translacja, a wewnętrzna reprezentacja tworzona przez '\n' jest wyprowadzana bezpośrednio.

Na platformach Unix, z których pochodzi C, natywną sekwencją nowej linii jest ASCII LF ( 0x0A ), więc „\n” zostało po prostu zdefiniowane jako ta wartość. Ponieważ wewnętrzna i zewnętrzna reprezentacja są identyczne, tłumaczenie wykonywane w trybie tekstowym nie wymaga żadnej operacji , a Unix nie ma pojęcia trybu tekstowego ani binarnego. To spowodowało, że wielu programistów, którzy opracowali swoje oprogramowanie w systemach Unix, po prostu całkowicie zignorowało to rozróżnienie, w wyniku czego kod nie jest przenośny na różne platformy.

Funkcji biblioteki C fgets () najlepiej unikać w trybie binarnym, ponieważ każdy plik, który nie jest napisany zgodnie z konwencją nowego wiersza systemu Unix, zostanie błędnie odczytany. Również w trybie tekstowym każdy plik niezapisany z natywną sekwencją nowej linii systemu (taki jak plik utworzony w systemie Unix, a następnie skopiowany do systemu Windows) również zostanie błędnie odczytany.

Innym powszechnym problemem jest użycie znaku „\n” podczas komunikacji przy użyciu protokołu internetowego, który wymaga użycia znaków ASCII CR + LF na końcach wierszy. Zapisanie „\n” do strumienia w trybie tekstowym działa poprawnie w systemach Windows, ale tworzy tylko LF w systemie Unix i coś zupełnie innego w bardziej egzotycznych systemach. Używanie „\r\n” w trybie binarnym jest nieco lepsze.

Wiele języków, takich jak C++ , Perl i Haskell zapewnia taką samą interpretację '\n' jak C. C++ ma alternatywny model wejścia/wyjścia , w którym manipulator std::endl może być użyty do wyprowadzenia nowej linii (i opróżnienia strumienia bufor).

Java , PHP i Python zapewniają sekwencję „\r\n” (dla ASCII CR + LF ). W przeciwieństwie do C, gwarantują one odpowiednio reprezentację wartości U+000D i U+000A .

Biblioteki Java I/O nie tłumaczą ich w przejrzysty sposób na zależne od platformy sekwencje nowej linii na wejściu lub wyjściu. Zamiast tego zapewniają funkcje do pisania pełnego wiersza, które automatycznie dodają natywną sekwencję nowej linii, oraz funkcje do odczytywania wierszy, które akceptują dowolny z CR , LF lub CR + LF jako terminator wiersza (zobacz BufferedReader.readLine() ). Metoda System.lineSeparator () może służyć do pobierania podstawowego separatora linii.

Przykład:

      
         Ciąg  eol  =  System  .  separator linii  ();  String  lineColor  =  "Kolor: czerwony"  +  eol  ;

Python zezwala na „Universal Newline Support” podczas otwierania pliku do odczytu, importowania modułów i wykonywania pliku.

Niektóre języki stworzyły specjalne zmienne , stałe i podprogramy ułatwiające stosowanie nowych linii podczas wykonywania programu. W niektórych językach, takich jak PHP i Perl , podwójne cudzysłowy są wymagane do wykonania podstawienia dla wszystkich sekwencji specjalnych, w tym '\n' i '\r' . W PHP, aby uniknąć problemów z przenośnością, sekwencje nowej linii powinny być wydawane przy użyciu stałej PHP_EOL.

Przykład w C# :

      
        
   
      
         string  eol  =  Środowisko  .  Nowa linia  ;  string  lineColor  =  "Kolor: czerwony"  +  eol  ;  string  eol2  =  "\n"  ;  string  lineColor2  =  "Kolor: niebieski"  +  eol2  ;

Problemy z różnymi formatami nowej linii

Plik tekstowy utworzony za pomocą gedit i przeglądany za pomocą edytora szesnastkowego . Oprócz obiektów tekstowych istnieją tylko znaczniki EOL o szesnastkowej 0A.

Różne konwencje nowej linii powodują, że pliki tekstowe, które zostały przesłane między systemami różnych typów, są wyświetlane niepoprawnie.

Tekst w plikach utworzonych za pomocą programów, które są powszechne w systemie Unix lub klasycznym systemie Mac OS , pojawia się jako pojedyncza długa linia w większości programów typowych dla systemów MS-DOS i Microsoft Windows , ponieważ nie wyświetlają one pojedynczego przesunięcia wiersza ani pojedynczego powrotu karetki jako przerwa w linii.

I odwrotnie, podczas przeglądania pliku pochodzącego z komputera z systemem Windows w systemie uniksopodobnym dodatkowy CR może być wyświetlany jako podział drugiej linii, jako ^M lub jako <cr> na końcu każdej linii.

Ponadto programy inne niż edytory tekstu mogą nie akceptować pliku, np. pliku konfiguracyjnego, zakodowanego przy użyciu obcej konwencji nowego wiersza, jako poprawnego pliku.

Problem może być trudny do wykrycia, ponieważ niektóre programy poprawnie obsługują obce znaki nowej linii, podczas gdy inne nie. Na przykład kompilator może zakończyć się niepowodzeniem z powodu niejasnych błędów składniowych, mimo że plik źródłowy wygląda poprawnie, gdy jest wyświetlany na konsoli lub w edytorze . Nowoczesne edytory tekstu na ogół rozpoznają wszystkie odmiany znaków CR + LF i umożliwiają użytkownikom konwersję między różnymi standardami. Przeglądarki internetowe zazwyczaj potrafią również wyświetlać pliki tekstowe i strony internetowe, które wykorzystują różne rodzaje znaków nowej linii.

Nawet jeśli program obsługuje różne konwencje nowej linii, funkcje te często nie są wystarczająco oznaczone, opisane lub udokumentowane. Zazwyczaj menu lub pole kombi wyliczające różne konwencje nowego wiersza będą wyświetlane użytkownikom bez wskazania, czy wybór spowoduje reinterpretację, tymczasowe przekształcenie lub trwałe przekonwertowanie nowych wierszy. Niektóre programy domyślnie konwertują podczas otwierania, kopiowania, wklejania lub zapisywania — często niekonsekwentnie.

Większość tekstowych protokołów internetowych (w tym HTTP , SMTP , FTP , IRC i wiele innych) wymaga użycia ASCII CR + LF ( '\r\n' , 0x0D 0x0A ) na poziomie protokołu, ale zaleca, aby tolerancyjne aplikacje rozpoznawały samotny LF ( '\n' , 0x0A ) również. Pomimo narzuconego standardu, wiele aplikacji błędnie używa sekwencji specjalnej C nowej linii '\n' ( LF ) zamiast poprawnej kombinacji sekwencji ucieczki karetki i znaku nowej linii '\r\n' ( CR + LF ) (patrz sekcja Nowa linia w językach programowania powyżej). To przypadkowe użycie niewłaściwych sekwencji specjalnych prowadzi do problemów podczas próby komunikacji z systemami stosującymi bardziej rygorystyczną interpretację standardów zamiast sugerowanej tolerancji tolerancji. Jednym z takich nietolerancyjnych systemów jest agent przesyłania poczty qmail który aktywnie odmawia przyjmowania komunikatów z systemów wysyłających puste LF zamiast wymaganego CR + LF .

Standardowy format wiadomości internetowych dla wiadomości e-mail stwierdza: „CR i LF MUSZĄ występować tylko razem jako CRLF; NIE MOGĄ pojawiać się niezależnie w treści”.

File Transfer Protocol może automatycznie konwertować znaki nowej linii w plikach przesyłanych między systemami z różnymi reprezentacjami nowej linii, gdy przesyłanie odbywa się w „trybie ASCII”. Jednak przesyłanie plików binarnych w tym trybie zwykle ma katastrofalne skutki: każde wystąpienie sekwencji bajtów nowej linii — która w tym kontekście nie ma semantyki terminatora linii, ale jest tylko częścią normalnej sekwencji bajtów — zostanie przetłumaczone na dowolną reprezentację nowej linii używany przez inny system, skutecznie uszkadzając plik. Klienci FTP często stosują heurystykę (na przykład kontrola rozszerzeń nazw plików ), aby automatycznie wybrać tryb binarny lub ASCII, ale ostatecznie to użytkownicy muszą upewnić się, że ich pliki są przesyłane we właściwym trybie. W przypadku wątpliwości co do właściwego trybu, należy użyć trybu binarnego, gdyż wówczas żadne pliki nie zostaną zmienione przez FTP, choć mogą się nieprawidłowo wyświetlać.

Konwersja między formatami nowej linii

Edytory tekstu są często używane do konwersji pliku tekstowego między różnymi formatami nowej linii; większość współczesnych edytorów może odczytywać i zapisywać pliki przy użyciu co najmniej różnych konwencji ASCII CR / LF .

Na przykład edytor Vim może sprawić, że plik będzie zgodny z edytorem tekstu Notatnika systemu Windows. W ramach vima

  :  ustaw  format pliku  =  dos :  wq

Edytory mogą być nieodpowiednie do konwertowania większych plików lub masowej konwersji wielu plików. W przypadku większych plików (w systemie Windows NT/2000/XP) często używane jest następujące polecenie:

  D:\>  TYP  plik_unix  |  ZNAJDŹ /V  ""  >  plik_dos

Programy specjalnego przeznaczenia do konwersji plików między różnymi konwencjami nowego wiersza obejmują unix2dos i dos2unix , mac2unix i unix2mac , mac2dos i dos2mac oraz flip . Polecenie tr jest dostępne w praktycznie każdym systemie uniksopodobnym i może być używane do wykonywania dowolnych operacji zamiany pojedynczych znaków. Plik tekstowy DOS/Windows można przekonwertować do formatu Unix, po prostu usuwając wszystkie znaki ASCII CR za pomocą

 $  tr  -d '\r' <  plik wejściowy  >  plik wyjściowy

lub, jeśli tekst ma tylko znaki nowej linii CR , konwertując wszystkie znaki nowej linii CR na LF za pomocą

 $  tr  '\r' '\n' <  plik wejściowy  >  plik wyjściowy

Te same zadania są czasami wykonywane z awk , sed lub w Perlu , jeśli platforma ma interpreter Perla:



 $  awk  '{sub("$","\r\n"); printf("%s",$0);}'   inputfile > outputfile  # UNIX do DOS (dodawanie CR w systemach Linux i BSD, które nie mają rozszerzeń GNU)  $  awk  '{gsub("\r",""); print;}'   inputfile > outputfile  # DOS to UNIX (usuwanie CR w systemach Linux i BSD, które nie mają rozszerzeń GNU)  $  sed -e  's/$/\r/'  inputfile > outputfile 



 # UNIX do DOS (dodawanie CR w systemie operacyjnym opartym na Linuksie, który używa rozszerzeń GNU)  $  sed -e  's/\r$//'  plik wejściowy > plik wyjściowy  # DOS do UNIX (usuwanie CR w systemie operacyjnym opartym na Linuksie, który używa rozszerzeń GNU)  $  perl -pe  's/\r?\n|\r/\r\n/g'  plik wejściowy > plik wyjściowy  # Konwertuj na DOS  $  perl -pe  's/\r?\n|\r/\n/g'  plik wejściowy > plik wyjściowy  # Konwersja do systemu UNIX  $  perl -pe  's/\r?\n|\r/\r/g'  plik wejściowy > plik wyjściowy  # Konwertuj na starego Maca

Polecenie file może zidentyfikować typ zakończeń linii:

 $  plik myfile.txt  myfile.txt: tekst w języku angielskim ASCII z terminatorami linii CRLF

Unix egrep (extended grep) może być używana do drukowania nazw plików plików Unix lub DOS (zakładając tylko pliki w stylu Unix i DOS, bez klasycznych plików w stylu Mac OS):


 $  egrep -L  '\r\n'  myfile.txt  # pokaż plik w stylu UNIX (zakończony LF)  $  egrep -l  '\r\n'  mójplik.txt  # pokaż plik w stylu DOS (zakończony CRLF)

Inne narzędzia pozwalają użytkownikowi na wizualizację znaków EOL:

 $  od -a mój plik.txt  $  cat -e mój plik.txt  $  cat -v mój plik.txt  $  hexdump -c mój plik.txt

Interpretacja

Dwa sposoby postrzegania nowych linii, z których oba są spójne , polegają na tym, że nowe linie oddzielają linie lub kończą linie. Jeśli znak nowej linii jest uważany za separator, po ostatnim wierszu pliku nie będzie znaku nowej linii. Niektóre programy mają problemy z przetwarzaniem ostatniej linii pliku, jeśli nie jest ona zakończona znakiem nowej linii. Z drugiej strony programy, które oczekują użycia nowej linii jako separatora, zinterpretują ostatnią nową linię jako początek nowej (pustej) linii. I odwrotnie, jeśli nowy wiersz jest traktowany jako terminator, oczekuje się, że wszystkie wiersze tekstu, w tym ostatni, będą zakończone znakiem nowej linii. Jeśli końcowa sekwencja znaków w pliku tekstowym nie jest znakiem nowej linii, ostatnia linia pliku może zostać uznana za niewłaściwą lub niekompletną lub plik może zostać uznany za niewłaściwie obcięty.

W tekście przeznaczonym głównie do czytania przez ludzi za pomocą oprogramowania, które implementuje funkcję zawijania wyrazów , znak nowej linii zwykle musi być przechowywany tylko wtedy, gdy wymagany jest podział wiersza, niezależnie od tego, czy następne słowo zmieściłoby się w tej samej linii, na przykład między akapitami oraz na listach pionowych. Dlatego w logice edytorów tekstu i większości edytorów tekstu znak nowej linii jest używany jako znak podziału akapitu i jest znany jako „twardy zwrot”, w przeciwieństwie do „miękkich zwrotów”, które są tworzone dynamicznie w celu zaimplementowania zawijania słów i można je zmieniać w każdej instancji wyświetlania. W wielu aplikacjach istnieje osobny znak kontrolny zwany „ręcznym łamaniem wiersza”, służący do wymuszania łamania wierszy w pojedynczym akapicie. Glifem znaku kontrolnego dla twardego powrotu jest zwykle pilcrow ( ¶), a dla ręcznego podziału wiersza jest to zwykle strzałka powrotu karetki (↵) .

Odwrotne i częściowe wysuwy wierszy

RI , ( U +008D REVERSE LINE FEED, ISO/IEC 6429 8D, dziesiętne 141) służy do przesunięcia pozycji drukowania o jeden wiersz wstecz (przez odwrócenie podawania papieru lub przesunięcie kursora wyświetlacza o jeden wiersz w górę), tak aby inne znaki mogą być drukowane na istniejącym tekście. Można to zrobić, aby je pogrubić lub dodać podkreślenia, przekreślenia lub inne znaki, takie jak znaki diakrytyczne .

Podobnie, PLD ( U +008B CZĘŚCIOWA LINIA DO PRZODU, dziesiętnie 139) i PLU ( U +008C CZĘŚCIOWA LINIA DO PRZÓD, dziesiętnie 140) mogą być użyte do przesunięcia lub odwrócenia pozycji drukowania tekstu o pewien ułamek odstępu między wierszami w pionie (zwykle o połowę ). Można ich używać w połączeniu z indeksami dolnymi (przez przechodzenie do przodu, a następnie cofanie) i indeksami górnymi (przez cofanie, a następnie do przodu), a także mogą być przydatne do drukowania znaków diakrytycznych.

Zobacz też

Linki zewnętrzne

Odniesienie do Unicode, patrz paragraf 5.8 w rozdziale 5 standardu Unicode 4.0 (PDF)
„Postać nowej linii [NEL]” .
Łamigłówka końca linii
Zrozumienie nowych linii w Wayback Machine (archiwum 20 sierpnia 2006)
„Opowieść o końcu linii”