Begrepene vognretur (CR) og linjefôr (LF) er nært knyttet og kan betraktes enten hver for seg eller sammen. I det fysiske mediet til skrivemaskiner og skrivere er det nødvendig med to bevegelsesakser, «ned» og «tvers», for å lage en ny linje på siden. Selv om utformingen av en maskin (skrivemaskin eller skriver) må vurdere dem separat, kan den abstrakte logikken til programvaren kombinere dem sammen som en hendelse. Dette er grunnen til at en ny linje i tegnkoding kan defineres som CR og LF kombinert til en (ofte kalt CR + LF eller CRLF ).

Noen tegnsett gir en egen newline tegnkode. EBCDIC gir for eksempel en NL-tegnkode i tillegg til CR- og LF-kodene. Unicode gir, i tillegg til å gi ASCII CR- og LF-kontrollkoder, også en «neste linje» (NEL) -kontrollkode, samt kontrollkoder for «linjeseparator» og «avsnitt separator» -markører.

• EBCDIC-systemer – hovedsakelig IBM-hovedrammesystemer, inkludert z / OS (OS / 390) og i5 / OS (OS / 400) – bruker NL (New Line, 0x15) som tegnet som kombinerer funksjonene til linjefôring og vogn komme tilbake. Tilsvarende Unicode-tegn ( 0x85 ) heter NEL (Next Line). EBCDIC har også kontrolltegn som heter CR og LF, men den numeriske verdien til LF (0x25) skiller seg fra den som brukes av ASCII (0x0A). I tillegg bruker noen EBCDIC-varianter også NL, men tilordner en annen numerisk kode til tegnet. Imidlertid bruker disse operativsystemene et rekordbasert filsystem, som lagrer tekstfiler som en post per linje. I de fleste filformater er det faktisk ikke lagret noen linjeterminatorer.
• Operativsystemer for CDC 6000-serien definerte en ny linje som to eller flere nullverdier seks-biters tegn på slutten av et 60-biters ord. Noen konfigurasjoner definerte også et nullverdi som et kolon, med det resultat at flere kolon kunne tolkes som en ny linje avhengig av posisjon.
• RSX-11 og OpenVMS bruker også et rekordbasert filsystem , som lagrer tekstfiler som en post per linje. I de fleste filformater lagres det faktisk ingen linjeterminatorer, men Record Management Services-anlegget kan transparent legge til en terminator på hver linje når den blir hentet av et program. Postene i seg selv kan inneholde de samme linjeterminatortegnene, som enten kan betraktes som en funksjon eller en plage avhengig av applikasjonen. RMS lagret ikke bare poster, men lagret også metadata om plateseparatorene i forskjellige biter for at filen skulle komplisere saken enda mer (siden filer kunne ha poster med fast lengde, poster som ble prefikset av en telling eller poster som ble avsluttet med et bestemt tegn ). Bittene var ikke generiske, så mens de kunne spesifisere at CRLF eller LF eller til og med CR var linjeterminatoren, kunne den ikke erstatte en annen kode.
• Fast linjelengde ble brukt av noen tidlige hovedrammedrifter. systemer. I et slikt system antok man for eksempel en implisitt end-of-line hver 72 eller 80 tegn. Ingen newline-tegn ble lagret. Hvis en fil ble importert fra omverdenen, måtte linjer kortere enn linjelengden polstres med mellomrom, mens linjer som var lengre enn linjelengden måtte avkortes. Dette etterlignet bruken av stansede kort, hvor hver linje var lagret på et eget kort, vanligvis med 80 kolonner på hvert kort, ofte med sekvensnummer i kolonnene 73–80. Mange av disse systemene la til en vognkontrollkarakter til starten av neste plate; dette kan indikere om neste post var en fortsettelse av linjen startet av forrige post, eller en ny linje, eller om den skulle overtrykke den forrige linjen (ligner på en CR). Ofte var dette et vanlig trykktegn som # som dermed ikke kunne brukes som det første tegnet i en linje. Noen tidlige linjeskrivere tolket disse tegnene direkte i postene som ble sendt til dem.

UnicodeEdit

Unicode-standarden definerer et antall tegn som samsvarende applikasjoner skal gjenkjenne som linjeterminatorer:

LF: Line Feed, U + 000A VT: Vertikal fane, U + 000B FF: Skjemamat, U + 000C CR: Vognretur, U + 000D CR + LF: CR (U + 000D) etterfulgt av LF (U + 000A) NEL: Neste linje, U + 0085 LS: Linjeseparator, U + 2028 PS: Paragrafseparator, U + 2029

Dette kan virke for komplisert sammenlignet med en tilnærming som å konvertere alle linjeterminatorer til ett tegn, for eksempel LF. Unicode ble imidlertid designet for å bevare all informasjon når du konverterer en tekstfil fra eksisterende koding til Unicode og tilbake. Derfor bør Unicode inneholde tegn som er inkludert i eksisterende kodinger.NL er inkludert i EBCDIC med kode 0x15, og ofte kartlagt til NEL, som er et kontrolltegn i C1-kontrollsettet. Som sådan er den definert av ECMA 48, og gjenkjent av kodinger som er i samsvar med ISO / IEC 2022 (som tilsvarer ECMA 35). C1-kontrollsett er også kompatibelt med ISO-8859-1. Tilnærmingen i Unicode-standarden gjør at rundturstransformasjon kan være informasjonsbevarende, mens applikasjoner fortsatt gjenkjenner alle mulige typer linjeterminatorer.

Gjenkjenne og bruke de nye linjekodene større enn 0x7F (NEL, LS og PS) gjøres ikke ofte. De er flere byte i UTF-8, og koden for NEL har blitt brukt som ellipsen (… ) i Windows-1252. For eksempel:

• ECMAScript aksepterer LS og PS som linjeskift, men anser U + 0085 (NEL) hvitt mellomrom i stedet for linjeskift.
• Windows 10 behandler ikke NEL, LS eller PS som linjeskift i standard teksteditor, Notisblokk.
• gedit, standard tekstredigerer for skrivebordsmiljøet GNOME , behandler LS og PS som nye linjer, men ikke for NEL.
• JSON tillater LS og PS-tegn i strenger, mens ECMAScript før ES2019 behandlet dem som nye linjer, og derfor ulovlig syntaks.
• YAML gjenkjenner dem ikke lenger som spesielle fra versjon 1.2, for å være kompatible med JSON.

Unicode-tegnene U + 2424 (SYMBOL FOR NEWLINE, ␤ ), U + 23CE (RETURN SYMBOL, ⏎ ), U + 240D (SYMBOL FOR VOGNTILBAKE, ␍ ) og U + 240A (SYMBOL FOR LINE FEED, ␊ ) er ment for å presentere et brukersynlig tegn til leseren av dokumentet, og blir dermed ikke anerkjent som en ny linje.

Escape sequencesEdit

En escape-sekvens er en kombinasjon av tegn som representerer ingen tekst; i stedet for å bli vist (som tekst) skal det avlyttes av programmet og en spesiell funksjon skal utføres. Escape-sekvenser brukes også til å håndtere (angi, søke, erstatte osv.) Spesialtegn.

I programmeringsspråk Rediger

For å lette opprettelsen av bærbare programmer, gir programmeringsspråk noen abstraksjoner for å håndtere de forskjellige typene av nye linjesekvenser som brukes i forskjellige miljøer.

C-programmeringsspråket gir rømningssekvensene «\ n» (ny linje) og «\ r» (vognretur). Disse kreves imidlertid ikke å være ekvivalente med ASCII LF- og CR-kontrolltegnene. C-standarden garanterer bare to ting:

1. Hver av disse rømningssekvensene tilordnes til et unikt implementeringsdefinert tall som kan lagres i en enkelt tegnverdi.
2. Når du skriver til en fil, enhetsnode eller socket / fifo i tekstmodus blir «\ n» oversatt transparent til den opprinnelige nylinjesekvensen som brukes av systemet, som kan være lengre enn ett tegn. Når du leser i tekstmodus, blir den opprinnelige nylinjesekvensen oversatt tilbake til «\ n». I binær modus utføres ingen oversettelse, og den interne representasjonen som produseres av «\ n» sendes ut direkte.

På Unix-plattformer, der C har sitt utspring, er den opprinnelige nylinjesekvensen ASCII LF ( 0x0A), så «\ n» ble ganske enkelt definert til å være den verdien. Med den interne og eksterne representasjonen som identisk, er oversettelsen utført i tekstmodus en no-op, og Unix har ingen forestilling om tekstmodus eller binærmodus. Dette har fått mange programmerere som utviklet programvaren sin på Unix-systemer, rett og slett til å ignorere skillet fullstendig, noe som resulterer i kode som ikke er bærbar til forskjellige plattformer.

C-biblioteksfunksjonen fgets () unngås best i binær modus. fordi alle filer som ikke er skrevet med Unix newline-konvensjonen blir lest feil. I tekstmodus vil også alle filer som ikke er skrevet med systemets innfødte nylinjesekvens (for eksempel en fil opprettet på et Unix-system, og deretter kopiert til et Windows-system) bli lest feil.

En annen vanlig problem er bruken av «\ n» når du kommuniserer ved hjelp av en Internett-protokoll som pålegger bruk av ASCII CR + LF for å avslutte linjer. Å skrive «\ n» til en tekstmodusstrøm fungerer riktig på Windows-systemer, men produserer bare LF på Unix, og noe helt annet på mer eksotiske systemer. Å bruke «\ r \ n» i binær modus er litt bedre.

Java I / O-bibliotekene oversetter ikke disse på en transparent måte til plattformavhengige nylinjesekvenser på Inngang eller utgang. I stedet gir de funksjoner for å skrive en hel linje som automatisk legger til den opprinnelige nye linjesekvensen, og funksjoner for å lese linjer som godtar hvilken som helst av CR, LF eller CR + LF som en linjeterminator (se BufferedReader.readLine () System.lineSeparator () -metoden kan brukes til å hente den underliggende linjeseparatoren.

Eksempel:

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

Python tillater «Universal Newline Support» når du åpner en fil for lesing, når importere moduler, og når du kjører en fil.

Noen språk har opprettet spesielle variabler, konstanter og underrutiner for å lette nye linjer under programutførelse. På noen språk som PHP og Perl kreves det dobbelt anførselstegn for å utføre fluksubstitusjon for alle rømningssekvenser, inkludert «\ n» og «\ r». I PHP, for å unngå bærbarhetsproblemer, bør nye linjesekvenser utstedes ved hjelp av 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 forskjellige newline-formater Rediger

Selv om kontrolltegnene er entydig definert i den tilsvarende tegnkodingstabellen som brukes av en tekstfil , det er fortsatt et problem: det er forskjellige konvensjoner for å angi og vise en linjeskift.

For å betegne en enkelt linjeskift, bruker Unix-programmer linjefôr , hvis heksadesimale verdi i ASCII er 0a , mens de fleste programmer som er vanlige for MS-DOS og Microsoft Windows, bruker vognretur + linjefôring , hvis heksadesimale verdi i ASCII er 0d 0a . I ASCII er vognretur et tydelig kontrolltegn.

De forskjellige newline-konvensjonene fører til at tekstfiler som er overført mellom systemer av forskjellige typer vises feil.

Tekst i filer som er opprettet med programmer som er vanlige på Unix-lignende eller klassiske Mac OS, vises som en enkelt lang linje på de fleste programmer som er felles for MS-DOS og Microsoft Windows fordi disse ikke viser en eneste linjefôring eller en enkelt vognretur som linjeskift.

Omvendt når du ser på en fil som stammer fra en Windows-datamaskin på et Unix-lignende system kan den ekstra CR vises som en annen linjeskift, som ^ M, eller som < cr > på slutten av hver linje.

Videre kan det hende at andre programmer enn tekstredigerere ikke godtar en fil, f.eks noen konfigurasjonsfiler, kodet ved hjelp av den utenlandske newline-konvensjonen, som en gyldig fil.

Problemet kan være vanskelig å oppdage fordi noen programmer håndterer de utenlandske nye linjene riktig, mens andre ikke gjør det. For eksempel kan en kompilator mislykkes med uklare syntaksfeil selv om kildefilen ser riktig ut når den vises på konsollen eller i en redaktør. På et Unix-lignende system vil kommandoen cat -v myfile.txt sende filen til stdout (vanligvis terminalen) og gjøre ^ M synlig, noe som kan være nyttig for feilsøking. Moderne tekstredigerere anerkjenner vanligvis alle smaker av CR + LF-nye linjer og lar brukerne konvertere mellom de forskjellige standardene. Nettlesere er vanligvis også i stand til å vise tekstfiler og nettsteder som bruker forskjellige typer nye linjer.

Selv om et program støtter forskjellige newline-konvensjoner, er disse funksjonene ofte ikke tilstrekkelig merket, beskrevet eller dokumentert. Vanligvis vil en meny eller kombinasjonsboks som viser forskjellige newline-konvensjoner vises til brukerne uten en indikasjon på om valget vil tolke, midlertidig konvertere eller konvertere de nye linjene permanent. Noen programmer vil implisitt konvertere til åpne, kopiere, lime inn eller lagre – ofte inkonsekvent.

De fleste tekstlige internettprotokoller (inkludert HTTP, SMTP, FTP, IRC og mange andre) pålegger bruk av ASCII CR + LF («\ r \ n», 0x0D 0x0A) på protokollnivå, men anbefaler at tolerante applikasjoner også gjenkjenner ensom LF («\ n», 0x0A). Til tross for den dikterte standarden, bruker mange applikasjoner feilaktig C newline escape-sekvensen «\ n» (LF) i stedet for riktig kombinasjon av vognretur-escape og newline escape-sekvenser «\ r \ n» (CR + LF) (se avsnitt Newline i programmeringsspråk ovenfor). Denne utilsiktede bruken av feil rømningssekvenser fører til problemer når man prøver å kommunisere med systemer som følger strengere tolkning av standardene i stedet for den foreslåtte tolerante tolkningen. Et slikt intolerant system er qmail-postoverføringsagenten som aktivt nekter å akseptere meldinger fra systemer som sender bare LF i stedet for den nødvendige CR + LF.

Standard Internet Message Format for e-post sier: CR og LF MUST bare forekomme sammen som CRLF; de MÅ IKKE vises uavhengig i kroppen.

File Transfer Protocol kan automatisk konvertere nye linjer i filer som overføres mellom systemer med forskjellige representasjoner for nye linjer når overføringen skjer i «ASCII-modus».Overføring av binære filer i denne modusen har imidlertid vanligvis katastrofale resultater: enhver forekomst av den nye linjebytesekvensen – som ikke har linjetermineringssemantikk i denne sammenhengen, men bare er en del av en normal bytesekvens – vil bli oversatt til hvilken som helst linjepresentasjon det andre systemet bruker, effektivt ødelegger filen. FTP-klienter bruker ofte noen heuristikker (for eksempel inspeksjon av filnavnutvidelser) for automatisk å velge enten binær- eller ASCII-modus, men til slutt er det opp til brukerne å sørge for at filene deres blir overført i riktig modus. Hvis det er tvil om riktig modus, bør binærmodus brukes, da vil ingen filer endres av FTP, selv om de kan vises feil.

Konvertering mellom newline-formaterRediger

Tekstredigerere brukes ofte til å konvertere en tekstfil mellom forskjellige newline-formater; de fleste moderne redaktører kan lese og skrive filer ved hjelp av minst de forskjellige ASCII CR / LF-konvensjonene. For eksempel kan redigeringsprogrammet Vim gjøre en fil kompatibel med Windows Notepad-teksteditoren. Innenfor vim

 :set fileformat=dos :wq

Redaktører kan være uegnet for å konvertere større filer eller massekonvertering av mange filer. For større filer (på Windows NT / 2000 / XP) brukes ofte følgende kommando:

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

Spesialprogrammer for konvertering filer mellom forskjellige newline-konvensjoner inkluderer unix2dos og dos2unix, mac2unix og unix2mac, mac2dos og dos2mac og flip. tr-kommandoen er tilgjengelig på praktisk talt alle Unix-lignende systemer og kan brukes til å utføre vilkårlige erstatningsoperasjoner på enkelttegn. En DOS / Windows-tekstfil kan konverteres til Unix-format ved å fjerne alle ASCII CR-tegn med

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

eller, hvis teksten bare har CR-nye linjer, av konvertere alle CR-nye linjer til LF med

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

De samme oppgavene blir noen ganger utført med awk, sed eller i Perl hvis plattformen har en Perl-tolk:

Filkommandoen kan identifisere typen linjeendelser:

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

Unix egrep (utvidet grep) -kommando kan brukes til å skrive ut filnavn på Unix- eller DOS-filer (forutsatt at bare Unix- og DOS-filer er, ingen 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 verktøy tillater brukeren å visualisere EOL-tegnene:

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