De concepten van carriage return (CR) en line feed (LF) zijn nauw met elkaar verbonden en kunnen afzonderlijk of samen worden beschouwd. In de fysieke media van typemachines en printers zijn twee bewegingsassen, “omlaag” en “over”, nodig om een nieuwe regel op de pagina te creëren. Hoewel het ontwerp van een machine (typemachine of printer) ze afzonderlijk moet beschouwen, kan de abstracte logica van software ze als één gebeurtenis combineren. Dit is de reden waarom een nieuwe regel in tekencodering kan worden gedefinieerd als CR en LF gecombineerd tot één (gewoonlijk CR + LF of CRLF genoemd).

Sommige tekensets bieden een aparte tekencode voor een nieuwe regel. EBCDIC levert bijvoorbeeld een NL-tekencode naast de CR- en LF-codes. Unicode biedt niet alleen de ASCII CR- en LF-controlecodes, maar ook een “next line” (NEL) controlecode, evenals controlecodes voor “line separator” en “paragraaf separator” markers.

• EBCDIC-systemen – voornamelijk IBM-mainframesystemen, inclusief z / OS (OS / 390) en i5 / OS (OS / 400) – gebruiken NL (New Line, 0x15) als het teken dat de functies van regeldoorvoer en wagen combineert terugkeer. Het equivalente Unicode-teken ( 0x85 ) wordt NEL (Next Line) genoemd. EBCDIC heeft ook besturingstekens genaamd CR en LF, maar de numerieke waarde van LF (0x25) verschilt van die gebruikt door ASCII (0x0A). Bovendien gebruiken sommige EBCDIC-varianten ook NL, maar kennen ze een andere numerieke code toe aan het teken. Die besturingssystemen gebruiken echter een op records gebaseerd bestandssysteem, dat tekstbestanden opslaat als één record per regel. In de meeste bestandsformaten worden feitelijk geen regelafsluiters opgeslagen.
• Besturingssystemen voor de CDC 6000-serie definieerden een nieuwe regel als twee of meer zes-bits tekens met nulwaarde aan het einde van een 60-bits woord. Sommige configuraties definieerden ook een teken met een nulwaarde als een dubbele punt, met als resultaat dat meerdere dubbele punten konden worden geïnterpreteerd als een nieuwe regel, afhankelijk van de positie.
• RSX-11 en OpenVMS gebruiken ook een op records gebaseerd bestandssysteem , dat tekstbestanden opslaat als één record per regel. In de meeste bestandsformaten worden feitelijk geen regelterminators opgeslagen, maar de Record Management Services-faciliteit kan op transparante wijze een terminator aan elke regel toevoegen wanneer deze wordt opgehaald door een toepassing. De records zelf kunnen dezelfde lijnterminatortekens bevatten, die als een kenmerk of hinderlijk kunnen worden beschouwd, afhankelijk van de toepassing. RMS bewaarde niet alleen records, maar ook bewaarde metadata over de recordscheidingstekens in verschillende bits voor het bestand om de zaken nog ingewikkelder te maken (aangezien bestanden records met een vaste lengte kunnen hebben, records die werden voorafgegaan door een telling of records die werden beëindigd door een specifiek teken ). De bits waren niet algemeen, dus hoewel ze konden specificeren dat CRLF of LF of zelfs CR de lijnafsluiter was, kon het niet een andere code vervangen.
• Vaste lijnlengte werd gebruikt door een aantal vroege mainframes. systemen. In een dergelijk systeem werd bijvoorbeeld uitgegaan van een impliciete end-of-line om de 72 of 80 karakters. Er is geen teken voor een nieuwe regel opgeslagen. Als een bestand uit de buitenwereld werd geïmporteerd, moesten regels die korter waren dan de regellengte worden opgevuld met spaties, terwijl regels die langer waren dan de regellengte moesten worden afgekapt. Dit bootste het gebruik van ponskaarten na, waarbij elke regel op een aparte kaart was opgeslagen, meestal met 80 kolommen op elke kaart, vaak met volgnummers in de kolommen 73-80. Veel van deze systemen hebben aan het begin van het volgende record een wagenbesturingsteken toegevoegd; dit zou kunnen aangeven of het volgende record een voortzetting was van de regel die door het vorige record is gestart, of een nieuwe regel, of dat het de vorige regel moet overdrukken (vergelijkbaar met een CR). Vaak was dit een normaal afdrukteken zoals # dat dus niet als het eerste teken op een regel kon worden gebruikt. Sommige vroege regelprinters interpreteerden deze tekens rechtstreeks in de records die naar hen werden gestuurd.

UnicodeEdit

De Unicode-standaard definieert een aantal karakters die conforme applicaties zouden moeten herkennen als regelterminators:

LF: Line Feed, U + 000A VT: Verticaal tabblad, U + 000B FF: Form Feed, U + 000C CR: Carriage Return, U + 000D CR + LF: CR (U + 000D) gevolgd door LF (U + 000A) NEL: Volgende regel, U + 0085 LS: Regelscheidingsteken, U + 2028 PS: Alineascheidingsteken, U + 2029

Dit lijkt misschien overdreven gecompliceerd in vergelijking met een benadering als het converteren van alle regelafsluiters naar een enkel teken, bijvoorbeeld LF. Unicode is echter ontworpen om alle informatie te behouden bij het converteren van een tekstbestand van een bestaande codering naar Unicode en omgekeerd. Daarom moet Unicode tekens bevatten die in bestaande coderingen zijn opgenomen.NL is opgenomen in EBCDIC met code 0x15, en vaak toegewezen aan NEL, wat een controleteken is in de C1-controleset. Als zodanig wordt het gedefinieerd door ECMA 48 en herkend door coderingen die voldoen aan ISO / IEC 2022 (wat gelijk is aan ECMA 35). C1-bedieningsset is ook compatibel met ISO-8859-1. De aanpak van de Unicode-standaard maakt het mogelijk dat round-trip-transformatie informatie behoudt, terwijl applicaties nog steeds alle mogelijke soorten lijnterminators kunnen herkennen.

Herkennen en gebruiken van de nieuwe lijncodes groter dan 0x7F (NEL, LS en PS) wordt niet vaak gedaan. Het zijn meerdere bytes in UTF-8, en de code voor NEL is gebruikt als het weglatingsteken (… ) in Windows-1252. Bijvoorbeeld:

• ECMAScript accepteert LS en PS als regeleinden, maar beschouwt U + 0085 (NEL) witruimte in plaats van een regeleinde.
• Windows 10 behandelt NEL, LS of PS niet als regeleinden in de standaardteksteditor, Kladblok.
• gedit, de standaardteksteditor van de GNOME-desktopomgeving , behandelt LS en PS als nieuwe regels, maar niet voor NEL.
• JSON staat LS- en PS-tekens binnen strings toe, terwijl ECMAScript vóór ES2019 ze als nieuwe regels behandelde, en daarom een illegale syntaxis.
• YAML herkent ze niet langer als speciaal vanaf versie 1.2, om compatibel te zijn met JSON.

De Unicode-tekens U + 2424 (SYMBOOL VOOR NEWLINE, ␤ ), U + 23CE (RETURN SYMBOOL, ⏎ ), U + 240D (SYMBOOL VOOR CARRIAGE RETURN, ␍ ) en U + 240A (SYMBOOL VOOR LIJNINVOER, ␊ ) zijn bedoeld om een voor de gebruiker zichtbaar teken te presenteren aan de lezer van het document, en worden dus zelf niet herkend als een nieuwe regel.

Escape-sequenties Bewerken

Een escape-reeks is een combinatie van tekens die vertegenwoordigt geen tekst; in plaats van weergegeven te worden (als tekst), zou het onderschept moeten worden door het programma en er zou een speciale functie uitgevoerd moeten worden. Escape-reeksen worden ook gebruikt om speciale tekens af te handelen (instellen, zoeken, vervangen, enz.).

In programmeertalen Bewerken

Om het maken van draagbare programma’s te vergemakkelijken, bieden programmeertalen enkele abstracties om te gaan met de verschillende soorten nieuwe regelreeksen die in verschillende omgevingen worden gebruikt.

De programmeertaal C biedt de escape-reeksen “\ n” (nieuwe regel) en “\ r” (regelterugloop). Deze hoeven echter niet gelijk te zijn aan de ASCII LF- en CR-besturingstekens. De C-standaard garandeert slechts twee dingen:

1. Elk van deze escape-reeksen wordt toegewezen aan een uniek door de implementatie gedefinieerd nummer dat kan worden opgeslagen in een enkele tekenwaarde.
2. Bij het schrijven naar een bestand, apparaatknooppunt of socket / fifo in tekstmodus, “\ n” wordt transparant vertaald naar de oorspronkelijke reeks nieuwe regels die door het systeem wordt gebruikt, die langer kan zijn dan één teken. Bij het lezen in tekstmodus wordt de oorspronkelijke reeks van nieuwe regels terugvertaald naar “\ n”. In binaire modus wordt er geen vertaling uitgevoerd en wordt de interne weergave geproduceerd door “\ n” rechtstreeks uitgevoerd.

Op Unix-platforms, waar C is ontstaan, is de oorspronkelijke sequentie van de nieuwe regel ASCII LF ( 0x0A), dus “\ n” werd simpelweg gedefinieerd als die waarde. Omdat de interne en externe weergave identiek zijn, is de vertaling die in tekstmodus wordt uitgevoerd een no-op, en Unix heeft geen idee van tekstmodus of binaire modus. Dit heeft ertoe geleid dat veel programmeurs die hun software op Unix-systemen ontwikkelden het onderscheid eenvoudigweg negeerden, wat resulteerde in code die niet naar verschillende platforms kan worden overgedragen.

De C-bibliotheekfunctie fgets () kan het beste worden vermeden in binaire modus omdat elk bestand dat niet is geschreven met de Unix newline-conventie, verkeerd wordt gelezen. Bovendien wordt in de tekstmodus elk bestand dat niet is geschreven met de oorspronkelijke reeks nieuwe regels van het systeem (zoals een bestand dat op een Unix-systeem is gemaakt en vervolgens naar een Windows-systeem is gekopieerd) ook verkeerd wordt gelezen.

Een ander bestand een veelvoorkomend probleem is het gebruik van “\ n” bij communicatie met behulp van een internetprotocol dat het gebruik van ASCII CR + LF verplicht voor eindregels. Het schrijven van “\ n” naar een tekstmodusstream werkt correct op Windows-systemen, maar produceert alleen LF op Unix, en iets heel anders op meer exotische systemen. Het gebruik van “\ r \ n” in binaire modus is iets beter.

De Java I / O-bibliotheken vertalen deze niet transparant naar platformafhankelijke newline-sequenties op invoer of uitvoer. In plaats daarvan bieden ze functies voor het schrijven van een volledige regel die automatisch de oorspronkelijke reeks nieuwe regels toevoegt, en functies voor het lezen van regels die CR, LF of CR + LF accepteren als regelterminator (zie BufferedReader.readLine () De methode System.lineSeparator () kan worden gebruikt om het onderliggende lijnscheidingsteken op te halen.

Voorbeeld:

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

Python staat “Universal Newline Support” toe bij het openen van een bestand om te lezen, wanneer modules importeren, en bij het uitvoeren van een bestand.

Sommige talen hebben speciale variabelen, constanten en subroutines gemaakt om nieuwe regels tijdens het uitvoeren van het programma te vergemakkelijken. In sommige talen, zoals PHP en Perl, zijn dubbele aanhalingstekens vereist om escape-substitutie uit te voeren voor alle escape-reeksen, inclusief “\ n” en “\ r”. Om in PHP overdraagbaarheidsproblemen te voorkomen, moeten sequenties voor nieuwe regels worden uitgegeven met de constante PHP_EOL.

Voorbeeld in C #:

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

Problemen met verschillende formaten voor nieuwe regels Bewerken

Ook al zijn de besturingstekens ondubbelzinnig gedefinieerd in de corresponderende tekencoderingstabel die wordt gebruikt door een tekstbestand , is er nog steeds een probleem: er zijn verschillende conventies om een regeleinde in te stellen en weer te geven.

Om een enkele regeleinde aan te duiden, gebruiken Unix-programma’s line feed , waarvan de hexadecimale waarde in ASCII 0a is, terwijl de meeste programma’s die in MS-DOS en Microsoft Windows voorkomen regelterugloop + line feed , waarvan de hexadecimale waarde in ASCII 0d 0a . In ASCII is regelterugloop een duidelijk controleteken.

De verschillende nieuwe regelconventies zorgen ervoor dat tekstbestanden die zijn overgedragen tussen systemen van verschillende typen, onjuist worden weergegeven.

Tekst in aangemaakte bestanden met programma’s die veel voorkomen op Unix-achtige of klassieke Mac OS, verschijnen als een enkele lange regel op de meeste programma’s die gebruikelijk zijn voor MS-DOS en Microsoft Windows, omdat deze geen enkele weergeven line feed of een enkele regelterugloop als een regeleinde.

Omgekeerd, wanneer u een bestand bekijkt dat afkomstig is van een Windows-computer op een Unix-achtig systeem kan de extra CR worden weergegeven als een tweede regeleinde, als ^ M, of als < cr > aan het einde van elke regel.

Bovendien kunnen andere programma’s dan teksteditors een bestand niet accepteren, bijv een configuratiebestand, gecodeerd met behulp van de foreign newline-conventie, als een geldig bestand.

Het probleem kan moeilijk te herkennen zijn omdat sommige programma’s de vreemde newlines correct behandelen en andere niet. Een compiler kan bijvoorbeeld mislukken met obscure syntaxisfouten, ook al ziet het bronbestand er correct uit wanneer het op de console of in een editor wordt weergegeven. Op een Unix-achtig systeem zal het commando cat -v myfile.txt het bestand naar stdout (normaal gesproken de terminal) sturen en de ^ M zichtbaar maken, wat handig kan zijn voor het opsporen van fouten. Moderne teksteditors herkennen over het algemeen alle smaken van CR + LF-nieuwe regels en stellen gebruikers in staat om te schakelen tussen de verschillende standaarden. Webbrowsers zijn meestal ook in staat om tekstbestanden en websites weer te geven die verschillende soorten nieuwe regels gebruiken.

Zelfs als een programma verschillende nieuwe regels ondersteunt, zijn deze functies vaak niet voldoende gelabeld, beschreven of gedocumenteerd. Gewoonlijk wordt een menu of keuzelijst met invoervak waarin verschillende nieuwe regelconventies worden opgesomd, aan gebruikers getoond zonder een indicatie of de selectie de nieuwe regels opnieuw zal interpreteren, tijdelijk zal converteren of permanent zal converteren. Sommige programma’s converteren impliciet bij openen, kopiëren, plakken of opslaan – vaak inconsistent.

De meeste tekstuele internetprotocollen (inclusief HTTP, SMTP, FTP, IRC en vele andere) verplichten het gebruik van ASCII CR + LF (“\ r \ n”, 0x0D 0x0A) op protocolniveau, maar raden aan dat tolerante applicaties ook alleenstaande LF (“\ n”, 0x0A) herkennen. Ondanks de gedicteerde standaard, gebruiken veel toepassingen ten onrechte de C newline escape-reeks “\ n” (LF) in plaats van de juiste combinatie van een regelterugloop-escape en newline escape-reeksen “\ r \ n” (CR + LF) (zie sectie programmeertalen hierboven). Dit onbedoelde gebruik van de verkeerde ontsnappingssequenties leidt tot problemen bij het communiceren met systemen die zich houden aan de strengere interpretatie van de normen in plaats van de voorgestelde tolerante interpretatie. Een dergelijk intolerant systeem is de qmail mail transfer agent die actief weigert berichten te accepteren van systemen die kale LF verzenden in plaats van de vereiste CR + LF.

Het standaard Internet Message Format voor e-mail stelt: CR en LF MOET komen alleen samen voor als CRLF; ze MOGEN NIET onafhankelijk in de body verschijnen.

Het File Transfer Protocol kan automatisch nieuwe regels converteren in bestanden die worden overgedragen tussen systemen met verschillende newline-representaties wanneer de overdracht plaatsvindt in “ASCII-modus”.Het overbrengen van binaire bestanden in deze modus heeft echter meestal rampzalige resultaten: elk voorkomen van de newline-byte-reeks – die in deze context geen line-terminator-semantiek heeft, maar slechts een deel is van een normale reeks bytes – zal worden vertaald naar welke newline-weergave dan ook het andere systeem gebruikt, waardoor het bestand effectief wordt beschadigd. FTP-clients gebruiken vaak een aantal heuristieken (bijvoorbeeld inspectie van bestandsnaamextensies) om automatisch de binaire of ASCII-modus te selecteren, maar uiteindelijk is het aan de gebruikers om ervoor te zorgen dat hun bestanden in de juiste modus worden overgedragen. Als er enige twijfel bestaat over de juiste modus, moet de binaire modus worden gebruikt, omdat dan geen bestanden worden gewijzigd door FTP, hoewel ze mogelijk onjuist worden weergegeven.

Conversie tussen formaten voor nieuwe regels Bewerken

Teksteditors worden vaak gebruikt voor het converteren van een tekstbestand tussen verschillende newline-formaten; de meeste moderne editors kunnen bestanden lezen en schrijven met behulp van ten minste de verschillende ASCII CR / LF-conventies. De editor Vim kan bijvoorbeeld een bestand compatibel maken met de Windows Kladblok-teksteditor. Binnen vim

 :set fileformat=dos :wq

Editors kunnen ongeschikt zijn voor het converteren van grotere bestanden of bulkconversie van veel bestanden. Voor grotere bestanden (op Windows NT / 2000 / XP) wordt vaak het volgende commando gebruikt:

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

Programma’s voor speciale doeleinden om te converteren bestanden tussen verschillende newline-conventies zijn onder andere unix2dos en dos2unix, mac2unix en unix2mac, mac2dos en dos2mac, en flip. De tr-opdracht is beschikbaar op vrijwel elk Unix-achtig systeem en kan worden gebruikt om willekeurige vervangingsbewerkingen uit te voeren op enkele tekens. Een DOS / Windows-tekstbestand kan worden geconverteerd naar Unix-indeling door eenvoudig alle ASCII CR-tekens te verwijderen met

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

of, als de tekst alleen CR-nieuwe regels heeft, door alle CR-nieuwe regels converteren naar LF met

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

Dezelfde taken worden soms uitgevoerd met awk, sed of in Perl als het platform een Perl-interpreter heeft:

Het file commando kan het type regeleinde identificeren:

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

Het Unix egrep (extended grep) commando kan worden gebruikt om bestandsnamen van Unix- of DOS-bestanden af te drukken (aangenomen dat alleen Unix- en DOS-bestanden, geen 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)

Met andere tools kan de gebruiker de EOL-tekens visualiseren:

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