Begreppen vagnretur (CR) och linjematning (LF) är nära kopplade och kan betraktas antingen separat eller tillsammans. I det fysiska mediet för skrivmaskiner och skrivare behövs två rörelseaxlar, ”ner” och ”tvärs över”, för att skapa en ny rad på sidan. Även om utformningen av en maskin (skrivmaskin eller skrivare) måste beakta dem separat, kan mjukvarans abstrakta logik kombinera dem som en händelse. Det är därför en ny rad i teckenkodning kan definieras som CR och LF kombineras till en (kallas vanligen CR + LF eller CRLF ).

Några teckenuppsättningar ger en separat newline-teckenkod. EBCDIC tillhandahåller till exempel en NL-teckenkod utöver CR- och LF-koderna. Unicode tillhandahåller, förutom att tillhandahålla ASCII CR- och LF-kontrollkoderna, också en ”nästa rad” (NEL) -kontrollkod, såväl som kontrollkoder för ”linjeseparator” och ”styckseparator” -markörer.

• EBCDIC-system – huvudsakligen IBM-system, inklusive z / OS (OS / 390) och i5 / OS (OS / 400) – använder NL (New Line, 0x15) som karaktär som kombinerar funktionerna för linjematning och transport. lämna tillbaka. Motsvarande Unicode-tecken ( 0x85 ) heter NEL (Next Line). EBCDIC har också kontrolltecken som heter CR och LF, men det numeriska värdet på LF (0x25) skiljer sig från det som används av ASCII (0x0A). Dessutom använder vissa EBCDIC-varianter också NL men tilldelar karaktären en annan numerisk kod. Dessa operativsystem använder dock ett rekordbaserat filsystem som lagrar textfiler som en post per rad. I de flesta filformat lagras faktiskt inga radterminatorer.
• Operativsystem för CDC 6000-serien definierade en ny linje som två eller flera nollvärderade sexbitars tecken i slutet av ett 60-bitars ord. Vissa konfigurationer definierade också ett nollvärderat tecken som ett kolontecken, vilket resulterade i att flera kolon kunde tolkas som en ny linje beroende på position.
• RSX-11 och OpenVMS använder också ett rekordbaserat filsystem , som lagrar textfiler som en post per rad. I de flesta filformat lagras faktiskt inga linjeterminatorer, men Record Management Services-anläggningen kan transparent lägga till en terminator i varje rad när den hämtas av en applikation. Själva posterna kan innehålla samma radterminatortecken, som antingen kan betraktas som en funktion eller olägenhet beroende på applikation. RMS lagrade inte bara poster utan lagrade också metadata om skivavskiljare i olika bitar för att filen skulle komplicera sakerna ännu mer (eftersom filer kunde ha poster med fast längd, poster som föregicks av ett antal eller poster som avslutades med en viss karaktär ). Bitarna var inte generiska, så även om de kunde specificera att CRLF eller LF eller till och med CR var linjetermineraren kunde den inte ersätta någon annan kod.
• Fast linjelängd användes av någon tidig mainframe-drift system. I ett sådant system antogs en implicit slut på rad till exempel var 72 eller 80 tecken. Ingen newline karaktär lagrades. Om en fil importerades från omvärlden, måste linjer som var kortare än linjelängden fyllas med mellanslag, medan linjer som var längre än linjelängden måste avkortas. Detta efterliknade användningen av stansade kort, där varje rad lagrades på ett separat kort, vanligtvis med 80 kolumner på varje kort, ofta med sekvensnummer i kolumnerna 73–80. Många av dessa system lade till en vagnkontrollkaraktär i början av nästa post; detta kan indikera om nästa post var en fortsättning på linjen som startades av den tidigare posten, eller en ny rad, eller om den skulle skriva över föregående rad (liknar en CR). Ofta var detta ett normalt utskriftstecken som # som således inte kunde användas som det första tecknet i en rad. Vissa tidiga skrivare tolkade dessa tecken direkt i posterna som skickades till dem.

UnicodeEdit

Unicode-standarden definierar ett antal tecken som överensstämmer med applikationer ska kännas igen som linjeterminatorer:

LF: Line Feed, U + 000A VT: Vertikal flik, U + 000B FF: Formmatning, U + 000C CR: Vagnretur, U + 000D CR + LF: CR (U + 000D) följt av LF (U + 000A) NEL: Nästa rad, U + 0085 LS: Linjeseparator, U + 2028 PS: Paragrafavskiljare, U + 2029

Detta kan verka alltför komplicerat jämfört med en metod som att konvertera alla linjeterminatorer till ett enda tecken, till exempel LF. Unicode var dock utformat för att bevara all information när du konverterar en textfil från någon befintlig kodning till Unicode och tillbaka. Därför bör Unicode innehålla tecken som ingår i befintliga kodningar.NL ingår i EBCDIC med kod 0x15 och mappas ofta till NEL, vilket är ett styrtecken i C1-kontrolluppsättningen. Som sådan definieras den av ECMA 48 och känns igen av kodningar som överensstämmer med ISO / IEC 2022 (vilket motsvarar ECMA 35). C1-kontrolluppsättningen är också kompatibel med ISO-8859-1. Tillvägagångssättet i Unicode-standarden gör att rundturstransformation kan vara informationsbevarande samtidigt som applikationer kan känna igen alla möjliga typer av linjeterminatorer. och PS) görs inte ofta. De är flera byte i UTF-8, och koden för NEL har använts som ellips (… ) i Windows-1252. Till exempel:

• ECMAScript accepterar LS och PS som radbrytningar, men betraktar U + 0085 (NEL) mellanslag istället för ett linjeskift.
• Windows 10 behandlar inte någon av NEL, LS eller PS som radbrytningar i standardtextredigeraren Notepad.
• gedit, standardtextredigeraren för skrivbordsmiljön GNOME , behandlar LS och PS som nya rader men inte för NEL.
• JSON tillåter LS- och PS-tecken inom strängar, medan ECMAScript före ES2019 behandlade dem som nya rader och därför olaglig syntax.
• YAML känner inte längre igen dem som speciella från version 1.2 för att vara kompatibla med JSON.

Unicode-tecknen U + 2424 (SYMBOL FÖR NEWLINE, ␤ ), U + 23CE (RETURN SYMBOL, ⏎ ), U + 240D (SYMBOL FÖR VAGNRETUR, ␍ ) och U + 240A (SYMBOL FÖR LINJEMAT, ␊ ) är avsedd för att presentera en användarsynlig karaktär för läsaren av dokumentet och känns således inte igen som en ny rad.

Escape sequencesEdit

En escape-sekvens är en kombination av tecken som representerar ingen text; istället för att visas (som text) ska den fångas upp av programmet och en speciell funktion ska utföras. Escape-sekvenser används också för att hantera (ställa in, söka, ersätta osv.) Specialtecken.

I programmeringsspråk Redigera

För att underlätta skapandet av bärbara program ger programmeringsspråk några abstraktioner för att hantera de olika typerna av nylinjesekvenser som används i olika miljöer.

C-programmeringsspråket tillhandahåller escape-sekvenserna ”\ n” (newline) och ”\ r” (vagnretur). Dessa måste dock inte motsvara ASCII LF- och CR-kontrolltecken. C-standarden garanterar bara två saker:

1. Var och en av dessa escape-sekvenser mappar till ett unikt implementeringsdefinierat nummer som kan lagras i ett enda teckenvärde.
2. När du skriver till en fil, enhetsnod eller socket / fifo i textläge översätts ”\ n” transparent till den ursprungliga nylinjesekvensen som används av systemet, som kan vara längre än ett tecken. När du läser i textläge översätts den ursprungliga newline-sekvensen tillbaka till ”\ n”. I binärt läge utförs ingen översättning och den interna representationen som produceras av ”\ n” matas ut direkt.

På Unix-plattformar, där C har sitt ursprung, är den ursprungliga nylinjesekvensen ASCII LF ( 0x0A), så ”\ n” definierades helt enkelt för att vara det värdet. Eftersom den interna och externa representationen är identisk är översättningen som utförs i textläge ett no-op, och Unix har inget begrepp om textläge eller binärt läge. Detta har fått många programmerare som utvecklat sin programvara på Unix-system helt enkelt att ignorera skillnaden helt, vilket resulterar i kod som inte är portabel till olika plattformar.

C-biblioteksfunktionen fgets () undviks bäst i binärt läge eftersom alla filer som inte skrivs med Unix newline-konventionen kommer att läsas fel. I textläge kommer alla filer som inte är skrivna med systemets ursprungliga nylinjesekvens (till exempel en fil som skapats på ett Unix-system och sedan kopierats till ett Windows-system) också att läsas fel.

En annan vanligt problem är användningen av ”\ n” när du kommunicerar med ett internetprotokoll som föreskriver användning av ASCII CR + LF för att avsluta rader. Att skriva ”\ n” till en textlägesström fungerar korrekt i Windows-system, men producerar bara LF på Unix, och något helt annat på mer exotiska system. Att använda ”\ r \ n” i binärt läge är något bättre.

Java I / O-biblioteken översätter inte dessa till plattformsberoende newline-sekvenser på Inmatning eller utgång. Istället tillhandahåller de funktioner för att skriva en hel rad som automatiskt lägger till den ursprungliga newline-sekvensen och funktioner för att läsa rader som accepterar någon av CR, LF eller CR + LF som en linjeterminator (se BufferedReader.readLine () System.lineSeparator () -metoden kan användas för att hämta den underliggande linjeseparatorn.

Exempel:

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

Python tillåter ”Universal Newline Support” när en fil öppnas för läsning, när importera moduler och när en fil körs.

Vissa språk har skapat speciella variabler, konstanter och underrutiner för att underlätta nya rader under programkörning. På vissa språk som PHP och Perl krävs dubbla citat för att utföra escape-substitution för alla escape-sekvenser, inklusive ”\ n” och ”\ r”. För att undvika bärbarhetsproblem i PHP bör newline-sekvenser utfärdas med PHP_EOL-konstanten.

Exempel i C #:

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

Problem med olika newline-format Redigera

Även om kontrolltecken är otvetydigt definierade i motsvarande teckenkodningstabell som används av en textfil , det finns fortfarande ett problem: det finns olika konventioner för att ställa in och visa en radbrytning.

För att beteckna en enda radbrytning använder Unix-program radmatning , vars hexadecimala värde i ASCII är 0a , medan de flesta gemensamma program för MS-DOS och Microsoft Windows använder vagnretur + radmatning , vars hexadecimala värde i ASCII är 0d 0a . I ASCII är vagnretur ett tydligt kontrolltecken.

De olika newline-konventionerna gör att textfiler som har överförts mellan olika typer av system visas felaktigt.

Text i skapade filer med program som är vanliga på Unix-liknande eller klassiska Mac OS, visas som en enda lång rad på de flesta program som är gemensamma för MS-DOS och Microsoft Windows eftersom dessa inte visar en enda radmatning eller en enda transportretur som en radbrytning.

Omvänt när du visar en fil som kommer från en Windows-dator på ett Unix-liknande system kan den extra CR visas som en andra radbrytning, som ^ M, eller som < cr > i slutet av varje rad.

Dessutom kan andra program än textredigerare inte acceptera en fil, t.ex. någon konfigurationsfil, kodad med den utländska newline-konventionen, som en giltig fil.

Problemet kan vara svårt att upptäcka eftersom vissa program hanterar de utländska nylinjerna ordentligt medan andra inte gör det. Till exempel kan en kompilator misslyckas med dunkla syntaxfel även om källfilen ser korrekt ut när den visas på konsolen eller i en redigerare. På ett Unix-liknande system skickar kommandot cat -v myfile.txt filen till stdout (normalt terminalen) och gör ^ M synlig, vilket kan vara användbart för felsökning. Moderna textredigerare känner vanligtvis till alla smaker av CR + LF-nylinjer och låter användare konvertera mellan de olika standarderna. Webbläsare kan vanligtvis också visa textfiler och webbplatser som använder olika typer av nya rader.

Även om ett program stöder olika newline-konventioner är dessa funktioner ofta inte tillräckligt märkta, beskrivna eller dokumenterade. Vanligtvis visas en meny eller kombinationsruta som räknar upp olika newline-konventioner för användare utan en indikation om valet kommer att tolka om, tillfälligt konvertera eller konvertera de nya raderna permanent. Vissa program kommer implicit att konvertera till öppna, kopiera, klistra in eller spara – ofta inkonsekvent.

De flesta textliga internetprotokoll (inklusive HTTP, SMTP, FTP, IRC och många andra) föreskriver användning av ASCII CR + LF (”\ r \ n”, 0x0D 0x0A) på protokollnivå, men rekommenderar också att toleranta applikationer känner igen ensam LF (”\ n”, 0x0A). Trots den dikterade standarden använder många applikationer felaktigt C newline escape-sekvensen ”\ n” (LF) istället för rätt kombination av vagnretur-escape och newline-escape-sekvenser ”\ r \ n” (CR + LF) (se avsnitt Newline i programmeringsspråk ovan). Denna oavsiktliga användning av fel escape-sekvenser leder till problem när man försöker kommunicera med system som följer den strängare tolkningen av standarderna istället för den föreslagna toleranta tolkningen. Ett sådant intolerant system är qmail-postöverföringsagenten som aktivt vägrar att acceptera meddelanden från system som skickar bara LF istället för den erforderliga CR + LF.

Standardmeddelandeformatet för e-post anger: CR och LF MÅSTE förekommer endast tillsammans som CRLF; de FÅR INTE visas oberoende i kroppen.

File Transfer Protocol kan automatiskt konvertera nya rader i filer som överförs mellan system med olika newline-representationer när överföringen sker i ”ASCII-läge”.Överföring av binära filer i det här läget har dock vanligtvis katastrofala resultat: varje förekomst av den nya linjebytesekvensen – som inte har linjeterminatorsemantik i det här sammanhanget, men bara är en del av en normal sekvens av byte – kommer att översättas till vilken nylinjerepresentation som helst det andra systemet använder, vilket skadar filen effektivt. FTP-klienter använder ofta en del heuristik (till exempel inspektion av filnamnstillägg) för att automatiskt välja antingen binärt eller ASCII-läge, men i slutändan är det upp till användarna att se till att deras filer överförs i rätt läge. Om det råder något tvivel om rätt läge bör binärt läge användas, eftersom inga filer kommer att ändras av FTP, även om de kan visas felaktigt.

Konvertering mellan newline-format Redigera

Textredigerare används ofta för att konvertera en textfil mellan olika newline-format; de flesta moderna redaktörer kan läsa och skriva filer med åtminstone de olika ASCII CR / LF-konventionerna. Till exempel kan redigeraren Vim göra en fil kompatibel med Windows Notepad textredigerare. Inom vim

 :set fileformat=dos :wq

Redigerare kan vara olämpliga för konvertering av större filer eller masskonvertering av många filer. För större filer (på Windows NT / 2000 / XP) används ofta följande kommando:

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

Specialprogram för att konvertera filer mellan olika newline-konventioner inkluderar unix2dos och dos2unix, mac2unix och unix2mac, mac2dos och dos2mac och flip. tr-kommandot är tillgängligt på praktiskt taget alla Unix-liknande system och kan användas för att utföra godtyckliga ersättningsoperationer på enstaka tecken. En DOS / Windows-textfil kan konverteras till Unix-format genom att helt enkelt ta bort alla ASCII CR-tecken med

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

eller, om texten bara har CR-nya rader, av konvertera alla CR-nya linjer till LF med

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

Samma uppgifter utförs ibland med awk, sed eller i Perl om plattformen har en Perl-tolk:

Filkommandot kan identifiera typen av radändar:

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

Kommandot Unix egrep (utökad grep) kan användas för att skriva ut filnamn på Unix- eller DOS-filer (förutsatt att endast Unix- och DOS-filer, 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)

Andra verktyg tillåter användaren att visualisera EOL-tecken:

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