Begreberne vognretur (CR) og line feed (LF) er tæt forbundet og kan betragtes enten separat eller sammen. I skrivemaskiner og printerers fysiske medier er der brug for to bevægelsesakser, “ned” og “på tværs” for at oprette en ny linje på siden. Selvom designet af en maskine (skrivemaskine eller printer) skal overveje dem separat, kan den abstrakte logik i software kombinere dem sammen som en begivenhed. Dette er grunden til, at en ny linje i tegnkodning kan defineres som CR og LF kombineret til en (kaldes almindeligvis CR + LF eller CRLF ).

Nogle tegnsæt giver en separat newline-tegnkode. EBCDIC leverer for eksempel en NL-tegnkode ud over CR- og LF-koderne. Unicode, ud over at tilvejebringe ASCII CR- og LF-kontrolkoderne, giver også en “næste linje” (NEL) -kontrolkode samt kontrolkoder til “linjeseparator” og “afsnit-separator” -markører.

• EBCDIC-systemer – hovedsageligt IBM-mainframesystemer, inklusive z / OS (OS / 390) og i5 / OS (OS / 400) – bruger NL (New Line, 0x15) som tegnet, der kombinerer funktionerne i linjefodring og transport Vend tilbage. Det ækvivalente Unicode-tegn ( 0x85 ) kaldes NEL (Next Line). EBCDIC har også kontroltegn kaldet CR og LF, men den numeriske værdi af LF (0x25) adskiller sig fra den, der bruges af ASCII (0x0A). Derudover bruger nogle EBCDIC-varianter også NL, men tildeler tegnet en anden numerisk kode. Disse operativsystemer bruger dog et rekordbaseret filsystem, der gemmer tekstfiler som en post pr. Linje. I de fleste filformater gemmes der faktisk ikke nogen linjeterminatorer.
• Operativsystemer til CDC 6000-serien definerede en ny linje som to eller flere nulværdige seks-bit tegn i slutningen af et 60-bit ord. Nogle konfigurationer definerede også et nulværdigt tegn som et kolon-tegn, hvilket resulterede i, at flere kolon kunne fortolkes som en ny linje afhængigt af position.
• RSX-11 og OpenVMS bruger også et rekordbaseret filsystem , der gemmer tekstfiler som en post pr. linje. I de fleste filformater gemmes der faktisk ikke nogen linjeterminatorer, men Record Management Services-faciliteten kan transparent tilføje en terminator til hver linje, når den hentes af en applikation. Selve optegnelserne kunne indeholde de samme linjeterminator-tegn, som enten kunne betragtes som en funktion eller en gener, afhængigt af applikationen. RMS lagrede ikke kun poster, men lagrede også metadata om pladeseparatorerne i forskellige bits for at filen skulle komplicere tingene endnu mere (da filer kunne have poster med fast længde, poster, der var forud for en optælling eller poster, der blev afsluttet med en bestemt karakter ). Bitene var ikke generiske, så selvom de kunne specificere, at CRLF eller LF eller endda CR var linjeterminatoren, kunne den ikke erstatte en anden kode.
• Fast linjelængde blev brugt af nogle tidlige mainframe-operativsystemer systemer. I et sådant system blev der antaget en implicit slutning af linjen for eksempel hver 72 eller 80 tegn. Ingen newline-tegn blev gemt. Hvis en fil blev importeret fra omverdenen, skulle linjer, der var kortere end linjelængden, polstres med mellemrum, mens linjer, der var længere end linjelængden, skulle afkortes. Dette efterlignede brugen af stansede kort, hvor hver linje blev gemt på et separat kort, normalt med 80 kolonner på hvert kort, ofte med sekvensnumre i kolonne 73-80. Mange af disse systemer tilføjede en vognkontrolkarakter til starten af den næste post; dette kunne indikere, om den næste post var en fortsættelse af linjen startet af den forrige post eller en ny linje, eller om den skulle overtrykke den forrige linje (svarende til en CR). Ofte var dette et normalt udskrivningskarakter som # , som således ikke kunne bruges som det første tegn i en linje. Nogle tidlige linieprintere fortolkede disse tegn direkte i de poster, der blev sendt til dem.

UnicodeEdit

Unicode-standarden definerer et antal tegn, som i overensstemmelse med applikationer skal genkendes som linjeterminatorer:

LF: Line Feed, U + 000A VT: Lodret fane, U + 000B FF: Form Feed, U + 000C CR: Vognretur, U + 000D CR + LF: CR (U + 000D) efterfulgt af LF (U + 000A) NEL: Næste linje, U + 0085 LS: Linjeseparator, U + 2028 PS: Afsnitsseparator, U + 2029

Dette kan virke for kompliceret i forhold til en fremgangsmåde som f.eks. At konvertere alle linjeterminatorer til et enkelt tegn, for eksempel LF. Unicode blev imidlertid designet til at bevare al information, når man konverterer en tekstfil fra enhver eksisterende kodning til Unicode og tilbage. Derfor bør Unicode indeholde tegn inkluderet i eksisterende kodninger.NL er inkluderet i EBCDIC med kode 0x15 og kortlægges ofte til NEL, hvilket er et kontroltegn i C1-kontrolsættet. Som sådan er det defineret af ECMA 48 og anerkendt af kodninger, der er i overensstemmelse med ISO / IEC 2022 (hvilket svarer til ECMA 35). C1 kontrolsæt er også kompatibelt med ISO-8859-1. Den tilgang, der tages i Unicode-standarden, tillader, at rundturstransformation er informationsbevarende, mens applikationer stadig kan genkende alle mulige typer linjeterminatorer.

Genkendelse og brug af de nye linjekoder større end 0x7F (NEL, LS og PS) gøres ikke ofte. De er flere bytes i UTF-8, og koden til NEL er blevet brugt som ellipsen (… ) i Windows-1252. For eksempel:

• ECMAScript accepterer LS og PS som linjeskift, men betragter U + 0085 (NEL) hvidt mellemrum i stedet for et linjeskift.
• Windows 10 behandler ikke nogen af NEL, LS eller PS som linjeskift i dets standardteksteditor, Notesblok.
• gedit, standardteksteditor for GNOME-skrivebordsmiljøet , behandler LS og PS som nye linjer, men ikke for NEL.
• JSON tillader LS og PS-tegn inden for strenge, mens ECMAScript før ES2019 behandlede dem som nye linjer og derfor ulovlig syntaks.
• YAML genkender dem ikke længere som specielle fra version 1.2 for at være kompatible med JSON.

Unicode-tegnene U + 2424 (SYMBOL TIL NEWLINE, ␤ ), U + 23CE (RETURN SYMBOL, ⏎ ), U + 240D (SYMBOL FOR VOGNRETUR, ␍ ) og U + 240A (SYMBOL FOR LINJEFODRING, ␊ ) er beregnet til at præsentere et brugersynligt tegn for læseren af dokumentet og genkendes således ikke selv som en ny linje.

Escape sequencesEdit

En escape-sekvens er en kombination af tegn, som repræsenterer ingen tekst i stedet for at blive vist (som tekst) skal det aflyttes af programmet, og der skal udføres en speciel funktion. Escape-sekvenser bruges også til at håndtere (sæt, søg, udskift osv.) Specialtegn.

I programmeringssprog Rediger

For at lette oprettelsen af bærbare programmer giver programmeringssprog nogle abstraktioner til at håndtere de forskellige typer newline-sekvenser, der bruges i forskellige miljøer.

C-programmeringssproget giver escape-sekvenser “\ n” (newline) og “\ r” (vognretur). Disse kræves dog ikke at svare til ASCII LF- og CR-kontroltegnene. C-standarden garanterer kun to ting:

1. Hver af disse escape-sekvenser kortlægges til et unikt implementeringsdefineret tal, der kan lagres i en enkelt tegnværdi.
2. Når du skriver til en fil, enhedsknudepunkt eller socket / fifo i teksttilstand oversættes “\ n” transparent til den oprindelige nye liniesekvens, der bruges af systemet, som kan være længere end et tegn. Når du læser i teksttilstand, oversættes den oprindelige nye liniesekvens tilbage til “\ n”. I binær tilstand udføres der ingen oversættelse, og den interne repræsentation produceret af “\ n” sendes direkte ud.

På Unix-platforme, hvor C opstod, er den oprindelige nyline-sekvens ASCII LF 0x0A), så “\ n” blev simpelthen defineret til at være den værdi. Da den interne og eksterne repræsentation er identisk, er oversættelsen, der udføres i teksttilstand, en no-op, og Unix har ingen forestilling om teksttilstand eller binær tilstand. Dette har fået mange programmører, der udviklede deres software på Unix-systemer, simpelthen til at ignorere sondringen fuldstændigt, hvilket resulterer i kode, der ikke er bærbar til forskellige platforme.

C-biblioteksfunktionen fgets () undgås bedst i binær tilstand fordi enhver fil, der ikke er skrevet med Unix newline-konventionen, læses forkert. Også i teksttilstand vil enhver fil, der ikke er skrevet med systemets oprindelige nye liniesekvens (f.eks. En fil oprettet på et Unix-system og derefter kopieret til et Windows-system) også blive fejllæst.

En anden almindeligt problem er brugen af “\ n” ved kommunikation ved hjælp af en internetprotokol, der pålægger brug af ASCII CR + LF til slutning af linjer. Skrivning “\ n” til en teksttilstandsstrøm fungerer korrekt på Windows-systemer, men producerer kun LF på Unix, og noget helt andet på mere eksotiske systemer. Brug af “\ r \ n” i binær tilstand er lidt bedre.

Java I / O-bibliotekerne oversætter disse ikke gennemsigtigt til platformafhængige newline-sekvenser på input eller output. I stedet giver de funktioner til at skrive en hel linje, der automatisk tilføjer den oprindelige newline-sekvens og funktioner til læsning af linjer, der accepterer nogen af CR, LF eller CR + LF som en linjeterminator (se BufferedReader.readLine () System.lineSeparator () -metoden kan bruges til at hente den underliggende linjeseparator.

Eksempel:

 String eol = System.lineSeparator(); String lineColor = "Color: Red" + eol;

Python tillader “Universal Newline Support”, når en fil åbnes til læsning, når import af moduler, og når der udføres en fil.

Nogle sprog har oprettet specielle variabler, konstanter og underrutiner for at lette nye linjer under programudførelse. På nogle sprog som PHP og Perl kræves der dobbelt anførselstegn for at udføre escape-erstatning for alle escape-sekvenser, inklusive “\ n” og “\ r”. For at undgå bærbarhedsproblemer i PHP skal newline-sekvenser udstedes ved hjælp af PHP_EOL-konstanten.

Eksempel i C #:

 string eol = Environment.NewLine; string lineColor = "Color: Red" + eol; string eol2 = "\n"; string lineColor2 = "Color: Blue" + eol2;

Problemer med forskellige newline-formater Rediger

Selvom kontroltegnene entydigt er defineret i den tilsvarende tegnkodningstabel, der bruges af en tekstfil , der er stadig et problem: der er forskellige konventioner til at indstille og vise et linjeskift.

For at betegne et enkelt linjeskift bruger Unix-programmer linjefeed , hvis hexadecimale værdi i ASCII er 0a , mens de fleste programmer, der er fælles for MS-DOS og Microsoft Windows, bruger vognretur + linjefeed , hvis hexadecimale værdi i ASCII er 0d 0a . I ASCII er vognretur et tydeligt kontroltegn.

De forskellige newline-konventioner får tekstfiler, der er overført mellem forskellige typer systemer, forkert.

Tekst i oprettede filer med programmer, der er almindelige på Unix-lignende eller klassiske Mac OS, vises som en enkelt lang linje på de fleste programmer, der er fælles for MS-DOS og Microsoft Windows, fordi disse ikke viser en enkelt linjefeed eller en enkelt vognretur som en linjeskift.

Omvendt, når du ser en fil, der stammer fra en Windows-computer på et Unix-lignende system kan den ekstra CR vises som et andet linjeskift som ^ M eller som < cr > i slutningen af hver linje.

Desuden accepterer andre programmer end teksteditorer muligvis ikke en fil, f.eks nogle konfigurationsfiler, kodet ved hjælp af den udenlandske newline-konvention, som en gyldig fil.

Problemet kan være svært at få øje på, fordi nogle programmer håndterer de udenlandske nye linjer korrekt, mens andre ikke gør det. For eksempel kan en kompilator mislykkes med obskure syntaksfejl, selvom kildefilen ser korrekt ud, når den vises på konsollen eller i en editor. På et Unix-lignende system sender kommandoen cat -v myfile.txt filen til stdout (normalt terminalen) og gør ^ M synlig, hvilket kan være nyttigt til fejlfinding. Moderne teksteditorer genkender generelt alle varianter af CR + LF-nye linjer og tillader brugere at konvertere mellem de forskellige standarder. Webbrowsere er normalt også i stand til at vise tekstfiler og websteder, der bruger forskellige typer nye linjer.

Selvom et program understøtter forskellige newline-konventioner, er disse funktioner ofte ikke tilstrækkeligt mærket, beskrevet eller dokumenteret. Typisk vises en menu eller kombinationsboks, der tæller forskellige newline-konventioner, for brugerne uden en indikation, hvis markeringen vil fortolke, midlertidigt konvertere eller konvertere de nye linjer permanent. Nogle programmer konverteres implicit til åben, kopiere, indsætte eller gemme – ofte inkonsekvent.

De fleste tekstlige internetprotokoller (inklusive HTTP, SMTP, FTP, IRC og mange andre) pålægger brugen af ASCII CR + LF (“\ r \ n”, 0x0D 0x0A) på protokolniveau, men anbefaler, at tolerante applikationer også genkender ensom LF (“\ n”, 0x0A). På trods af den dikterede standard bruger mange applikationer fejlagtigt C newline escape-sekvensen “\ n” (LF) i stedet for den korrekte kombination af carriage return escape og newline escape-sekvenser “\ r \ n” (CR + LF) (se afsnit Newline i programmeringssprog ovenfor). Denne utilsigtede brug af de forkerte flugtsekvenser fører til problemer, når man prøver at kommunikere med systemer, der overholder strengere fortolkning af standarderne i stedet for den foreslåede tolerante fortolkning. Et sådant intolerant system er qmail-mailoverføringsagenten, der aktivt nægter at acceptere beskeder fra systemer, der sender bare LF i stedet for det krævede CR + LF.

Standardmeddelelsesformatet til e-mail angiver: CR og LF SKAL forekommer kun sammen som CRLF; de SKAL IKKE vises uafhængigt i kroppen.

Filoverførselsprotokollen kan automatisk konvertere nye linjer i filer, der overføres mellem systemer med forskellige repræsentationer af nye linjer, når overførslen sker i “ASCII-tilstand”.Imidlertid har overførsel af binære filer i denne tilstand normalt katastrofale resultater: enhver forekomst af newline-bytesekvensen – som ikke har linjeterminatorsemantik i denne sammenhæng, men kun er en del af en normal række af bytes – vil blive oversat til hvilken som helst newline-repræsentation det andet system bruger, hvilket effektivt ødelægger filen. FTP-klienter anvender ofte nogle heuristikker (for eksempel inspektion af filnavneudvidelser) til automatisk at vælge enten binær eller ASCII-tilstand, men i sidste ende er det op til brugerne at sikre, at deres filer overføres i den korrekte tilstand. Hvis der er tvivl om den korrekte tilstand, skal binær tilstand bruges, da ingen filer ændres af FTP, selvom de muligvis vises forkert.

Konvertering mellem newline-formater Rediger

Teksteditorer bruges ofte til at konvertere en tekstfil mellem forskellige newline-formater; de fleste moderne redaktører kan læse og skrive filer ved hjælp af mindst de forskellige ASCII CR / LF-konventioner. F.eks. kan editoren Vim gøre en fil kompatibel med Windows Notepad-teksteditor. Inden for vim

 :set fileformat=dos :wq

Redaktører kan være uegnede til at konvertere større filer eller massekonvertering af mange filer. For større filer (på Windows NT / 2000 / XP) bruges følgende kommando ofte:

D:\>TYPE unix_file | FIND /V "" > dos_file

Specielle programmer til konvertering filer mellem forskellige newline-konventioner inkluderer unix2dos og dos2unix, mac2unix og unix2mac, mac2dos og dos2mac og flip. tr-kommandoen er tilgængelig på stort set alle Unix-lignende systemer og kan bruges til at udføre vilkårlige udskiftningsoperationer på enkelte tegn. En DOS / Windows-tekstfil kan konverteres til Unix-format ved simpelthen at fjerne alle ASCII CR-tegn med

$ tr -d "\r" < inputfile > outputfile

eller, hvis teksten kun har CR-nye linjer, ved konvertering af alle CR-nye linjer til LF med

$ tr "\r" "\n" < inputfile > outputfile

De samme opgaver udføres undertiden med awk, sed eller i Perl, hvis platformen har en Perl-fortolker:

Filkommandoen kan identificere typen af linieendelser:

 $ file myfile.txt myfile.txt: ASCII English text, with CRLF line terminators

Kommandoen Unix egrep (udvidet grep) kan bruges til at udskrive filnavne på Unix- eller DOS-filer (forudsat at kun Unix- og DOS-filer er uden Mac OS):

$ egrep -L "\r\n" myfile.txt # show UNIX style file (LF terminated)$ egrep -l "\r\n" myfile.txt # show DOS style file (CRLF terminated)

Andre værktøjer tillader brugeren at visualisere EOL-tegn:

$ od -a myfile.txt$ cat -e myfile.txt$ hexdump -c myfile.txt