Die Konzepte von Wagenrücklauf (CR) und Zeilenvorschub (LF) sind eng miteinander verbunden und können entweder einzeln oder zusammen betrachtet werden. In den physischen Medien von Schreibmaschinen und Druckern sind zwei Bewegungsachsen „unten“ und „quer“ erforderlich, um eine neue Zeile auf der Seite zu erstellen. Obwohl das Design einer Maschine (Schreibmaschine oder Drucker) sie separat berücksichtigen muss, kann die abstrakte Logik der Software sie als ein Ereignis kombinieren. Aus diesem Grund kann eine neue Zeile in der Zeichenkodierung als CR und LF definiert werden (allgemein als CR + LF oder CRLF bezeichnet).

Einige Zeichensätze bieten einen separaten Zeilenumbruch-Zeichencode. EBCDIC bietet beispielsweise zusätzlich zu den CR- und LF-Codes einen NL-Zeichencode. Unicode bietet neben den ASCII-CR- und LF-Steuercodes auch einen NEL-Steuercode (Next Line) sowie Steuercodes für die Markierungen „Zeilentrennzeichen“ und „Absatztrennzeichen“.

• EBCDIC-Systeme – hauptsächlich IBM Mainframe-Systeme, einschließlich z / OS (OS / 390) und i5 / OS (OS / 400) – verwenden NL (New Line, 0x15) als Zeichen, das die Funktionen von Zeilenvorschub und Wagen kombiniert Rückkehr. Das entsprechende Unicode-Zeichen ( 0x85 ) heißt NEL (Next Line). EBCDIC hat auch Steuerzeichen namens CR und LF, aber der numerische Wert von LF (0x25) unterscheidet sich von dem von ASCII (0x0A) verwendeten. Darüber hinaus verwenden einige EBCDIC-Varianten auch NL, weisen dem Zeichen jedoch einen anderen numerischen Code zu. Diese Betriebssysteme verwenden jedoch ein auf Datensätzen basierendes Dateisystem, in dem Textdateien als ein Datensatz pro Zeile gespeichert werden. In den meisten Dateiformaten werden tatsächlich keine Zeilenabschlüsse gespeichert.
• Betriebssysteme für die CDC 6000-Serie definierten eine neue Zeile als zwei oder mehr nullwertige Sechs-Bit-Zeichen am Ende eines 60-Bit-Wortes. In einigen Konfigurationen wurde auch ein Zeichen mit dem Wert Null als Doppelpunktzeichen definiert, sodass mehrere Doppelpunkte je nach Position als neue Zeile interpretiert werden können.
• RSX-11 und OpenVMS verwenden ebenfalls ein auf Datensätzen basierendes Dateisystem , in dem Textdateien als ein Datensatz pro Zeile gespeichert werden. In den meisten Dateiformaten werden tatsächlich keine Zeilenabschlusszeichen gespeichert, aber die Record Management Services-Funktion kann jeder Zeile transparent ein Abschlusszeichen hinzufügen, wenn sie von einer Anwendung abgerufen wird. Die Datensätze selbst können dieselben Zeilenabschlusszeichen enthalten, die je nach Anwendung entweder als Merkmal oder als störend angesehen werden können. RMS speicherte nicht nur Datensätze, sondern auch Metadaten zu den Datensatztrennzeichen in verschiedenen Bits für die Datei, um die Sache noch komplizierter zu machen (da Dateien Datensätze fester Länge, Datensätze mit einem Präfix vorangestellt oder Datensätze mit einem bestimmten Zeichen abgeschlossen haben könnten ). Die Bits waren nicht generisch, so dass sie zwar angeben konnten, dass CRLF oder LF oder sogar CR der Leitungsterminator war, aber keinen anderen Code ersetzen konnten.
• Die feste Leitungslänge wurde von einigen frühen Mainframe-Betrieben verwendet Systeme. In einem solchen System wurde beispielsweise alle 72 oder 80 Zeichen ein implizites Zeilenende angenommen. Es wurde kein Zeilenumbruchzeichen gespeichert. Wenn eine Datei aus der Außenwelt importiert wurde, mussten Zeilen, die kürzer als die Zeilenlänge waren, mit Leerzeichen aufgefüllt werden, während Zeilen, die länger als die Zeilenlänge waren, abgeschnitten werden mussten. Dies ahmte die Verwendung von Lochkarten nach, bei denen jede Zeile auf einer separaten Karte gespeichert war, normalerweise mit 80 Spalten auf jeder Karte, häufig mit Sequenznummern in den Spalten 73–80. Viele dieser Systeme haben am Anfang des nächsten Datensatzes ein Wagensteuerzeichen hinzugefügt. Dies könnte anzeigen, ob der nächste Datensatz eine Fortsetzung der vom vorherigen Datensatz gestarteten Zeile oder eine neue Zeile war oder die vorherige Zeile überdrucken sollte (ähnlich einer CR). Oft war dies ein normales Druckzeichen wie # , das daher nicht als erstes Zeichen in einer Zeile verwendet werden konnte. Einige frühe Zeilendrucker interpretierten diese Zeichen direkt in den an sie gesendeten Datensätzen.

UnicodeEdit

Der Unicode-Standard definiert eine Reihe von Zeichen, die konforme Anwendungen als Zeilenabschlüsse erkennen sollten:

LF: Zeilenvorschub, U + 000A VT: Vertikale Registerkarte, U + 000B FF: Formularvorschub, U + 000C CR: Wagenrücklauf, U + 000D CR + LF: CR (U + 000D) gefolgt von LF (U + 000A) NEL: Nächste Zeile, U + 0085 LS: Zeilentrenner, U + 2028 PS: Absatztrenner, U + 2029

Dies mag im Vergleich zu einem Ansatz wie der Konvertierung aller Zeilenterminatoren in ein einzelnes Zeichen, z. B. LF, übermäßig kompliziert erscheinen. Unicode wurde jedoch entwickelt, um alle Informationen beim Konvertieren einer Textdatei von einer vorhandenen Codierung in Unicode und zurück beizubehalten. Daher sollte Unicode Zeichen enthalten, die in vorhandenen Codierungen enthalten sind.NL ist in EBCDIC mit dem Code 0x15 enthalten und wird häufig NEL zugeordnet, einem Steuerzeichen im C1-Steuerungssatz. Als solches wird es von ECMA 48 definiert und durch Codierungen erkannt, die ISO / IEC 2022 entsprechen (was ECMA 35 entspricht). Das C1-Steuergerät ist auch mit ISO-8859-1 kompatibel. Der im Unicode-Standard verfolgte Ansatz ermöglicht eine informationserhaltende Round-Trip-Transformation, während Anwendungen weiterhin alle möglichen Arten von Leitungsabschlusszeichen erkennen können.

Erkennen und Verwenden von Zeilenumbruchcodes größer als 0x7F (NEL, LS) und PS) wird nicht oft gemacht. In UTF-8 sind dies mehrere Bytes, und der Code für NEL wurde in Windows-1252 als Auslassungszeichen (… ) verwendet. Beispiel:

• ECMAScript akzeptiert LS und PS als Zeilenumbrüche, berücksichtigt jedoch U + 0085-Leerzeichen (NEL) anstelle eines Zeilenumbruchs.
• Windows 10 behandelt NEL, LS oder PS in seinem Standardtexteditor Notepad nicht als Zeilenumbrüche.
• gedit, der Standardtexteditor der GNOME-Desktopumgebung , behandelt LS und PS als Zeilenumbrüche, jedoch nicht für NEL.
• JSON erlaubt LS- und PS-Zeichen in Zeichenfolgen, während ECMAScript vor ES2019 sie als Zeilenumbrüche und damit als illegale Syntax behandelte.
• YAML erkennt sie ab Version 1.2 nicht mehr als speziell, um mit JSON kompatibel zu sein.

Die Unicode-Zeichen U + 2424 (SYMBOL FÜR NEWLINE, ␤ ), U + 23CE (RÜCKGABESYMBOL, ⏎ ), U + 240D (SYMBOL FOR CARRIAGE RETURN, ␍ ) und U + 240A (SYMBOL FÜR LINE FEED, ␊ ) sind bestimmt, um dem Leser des Dokuments ein für den Benutzer sichtbares Zeichen zu präsentieren, und werden daher selbst nicht als Zeilenumbruch erkannt.

Escape-SequenzenEdit

Eine Escape-Sequenz ist eine Kombination von Zeichen, die stellt keinen Text dar; anstatt (als Text) angezeigt zu werden, soll es vom Programm abgefangen und eine spezielle Funktion ausgeführt werden. Escape-Sequenzen werden auch zum Behandeln (Setzen, Suchen, Ersetzen usw.) von Sonderzeichen verwendet.

In Programmiersprachen Bearbeiten

Um die Erstellung portabler Programme zu erleichtern, bieten Programmiersprachen einige Abstraktionen, um die verschiedenen Arten von Zeilenumbruchsequenzen zu behandeln, die in verschiedenen Umgebungen verwendet werden. P. >

Die Programmiersprache C bietet die Escape-Sequenzen „\ n“ (Zeilenumbruch) und „\ r“ (Wagenrücklauf). Diese müssen jedoch nicht den ASCII-LF- und CR-Steuerzeichen entsprechen. Der C-Standard garantiert nur zwei Dinge:

1. Jede dieser Escape-Sequenzen wird einer eindeutigen implementierungsdefinierten Nummer zugeordnet, die in einem einzelnen Zeichenwert gespeichert werden kann.
2. Beim Schreiben In eine Datei, einen Geräteknoten oder einen Socket / Fifo im Textmodus wird „\ n“ transparent in die vom System verwendete native Zeilenumbruchsequenz übersetzt, die länger als ein Zeichen sein kann. Beim Lesen im Textmodus wird die native Zeilenumbruchsequenz zurück in „\ n“ übersetzt. Im Binärmodus wird keine Übersetzung durchgeführt und die von „\ n“ erzeugte interne Darstellung wird direkt ausgegeben.

Auf Unix-Plattformen, von denen C stammt, lautet die native Newline-Sequenz ASCII LF ( 0x0A), also wurde „\ n“ einfach als dieser Wert definiert. Da die interne und externe Darstellung identisch sind, ist die im Textmodus durchgeführte Übersetzung ein No-Op, und Unix hat keine Vorstellung vom Textmodus oder Binärmodus. Dies hat dazu geführt, dass viele Programmierer, die ihre Software auf Unix-Systemen entwickelt haben, die Unterscheidung einfach vollständig ignorieren, was zu Code führt, der nicht auf verschiedene Plattformen portierbar ist.

Die C-Bibliotheksfunktion fgets () wird am besten im Binärmodus vermieden weil jede Datei, die nicht mit der Unix-Newline-Konvention geschrieben wurde, falsch gelesen wird. Im Textmodus wird auch jede Datei falsch gelesen, die nicht mit der nativen Zeilenumbruchsequenz des Systems geschrieben wurde (z. B. eine Datei, die auf einem Unix-System erstellt und dann auf ein Windows-System kopiert wurde).

Eine andere Ein häufiges Problem ist die Verwendung von „\ n“ bei der Kommunikation über ein Internetprotokoll, das die Verwendung von ASCII CR + LF zum Beenden von Zeilen vorschreibt. Das Schreiben von „\ n“ in einen Textmodus-Stream funktioniert auf Windows-Systemen ordnungsgemäß, erzeugt jedoch nur LF Unix und etwas völlig anderes auf exotischeren Systemen. Die Verwendung von „\ r \ n“ im Binärmodus ist etwas besser.

Die Java-E / A-Bibliotheken übersetzen diese nicht transparent in plattformabhängige Zeilenumbruchsequenzen Eingabe oder Ausgabe. Stattdessen bieten sie Funktionen zum Schreiben einer vollständigen Zeile, die automatisch die native Zeilenumbruchsequenz hinzufügen, und Funktionen zum Lesen von Zeilen, die CR, LF oder CR + LF als Zeilenabschluss akzeptieren (siehe BufferedReader.readLine (). ) Mit der Methode System.lineSeparator () kann das zugrunde liegende Zeilentrennzeichen abgerufen werden.

Beispiel:

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

Python erlaubt „Universal Newline Support“ beim Öffnen einer Datei zum Lesen, wenn Importieren von Modulen und Ausführen einer Datei.

Einige Sprachen haben spezielle Variablen, Konstanten und Unterprogramme erstellt, um Zeilenumbrüche während der Programmausführung zu erleichtern. In einigen Sprachen wie PHP und Perl sind doppelte Anführungszeichen erforderlich, um die Escape-Ersetzung für alle Escape-Sequenzen durchzuführen, einschließlich „\ n“ und „\ r“. In PHP sollten Zeilenumbruchsequenzen mit der Konstante PHP_EOL ausgegeben werden, um Portabilitätsprobleme zu vermeiden.

Beispiel in C #:

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

Probleme mit verschiedenen ZeilenumbruchformatenEdit

Obwohl die Steuerzeichen in der entsprechenden Zeichencodierungstabelle, die von einer Textdatei verwendet wird, eindeutig definiert sind Es gibt immer noch ein Problem: Es gibt verschiedene Konventionen zum Festlegen und Anzeigen eines Zeilenumbruchs.

Um einen einzelnen Zeilenumbruch zu kennzeichnen, verwenden Unix-Programme den Zeilenvorschub , dessen hexadezimaler Wert in ASCII 0a ist, während die meisten Programme, die MS-DOS und Microsoft Windows gemeinsam haben, Wagenrücklauf + Zeilenvorschub , dessen hexadezimaler Wert in ASCII 0d 0a . In ASCII ist der Wagenrücklauf ein eindeutiges Steuerzeichen.

Die verschiedenen Newline-Konventionen führen dazu, dass Textdateien, die zwischen Systemen unterschiedlichen Typs übertragen wurden, falsch angezeigt werden.

Text in erstellten Dateien Bei Programmen, die unter Unix-ähnlichem oder klassischem Mac OS üblich sind, wird bei den meisten Programmen, die unter MS-DOS und Microsoft Windows üblich sind, eine einzige lange Zeile angezeigt, da in diesen Programmen kein einziges angezeigt wird Zeilenvorschub oder ein einzelner Wagenrücklauf als Zeilenumbruch.

Umgekehrt beim Anzeigen einer Datei, die von einem Windows-Computer stammt Auf einem Unix-ähnlichen System kann der zusätzliche CR als zweiter Zeilenumbruch als ^ M oder als < cr > angezeigt werden am Ende jeder Zeile.

Außerdem akzeptieren andere Programme als Texteditoren möglicherweise keine Datei, z Einige Konfigurationsdateien, die unter Verwendung der Fremd-Newline-Konvention als gültige Datei codiert wurden.

Das Problem kann schwer zu erkennen sein, da einige Programme die Fremd-Newlines ordnungsgemäß verarbeiten, während andere dies nicht tun. Beispielsweise kann ein Compiler mit undurchsichtigen Syntaxfehlern fehlschlagen, obwohl die Quelldatei auf der Konsole oder in einem Editor korrekt aussieht. Auf einem Unix-ähnlichen System sendet der Befehl cat -v myfile.txt die Datei an stdout (normalerweise das Terminal) und macht das ^ M sichtbar, was beim Debuggen hilfreich sein kann. Moderne Texteditoren erkennen im Allgemeinen alle Varianten von CR + LF-Zeilenumbrüchen und ermöglichen Benutzern das Konvertieren zwischen den verschiedenen Standards. Webbrowser können normalerweise auch Textdateien und Websites anzeigen, die unterschiedliche Arten von Zeilenumbrüchen verwenden.

Selbst wenn ein Programm unterschiedliche Zeilenumbruchkonventionen unterstützt, sind diese Funktionen häufig nicht ausreichend gekennzeichnet, beschrieben oder dokumentiert. In der Regel wird Benutzern ein Menü oder ein Kombinationsfeld mit verschiedenen Zeilenumbruchkonventionen angezeigt, ohne dass angegeben wird, ob die Auswahl die Zeilenumbrüche neu interpretiert, vorübergehend konvertiert oder dauerhaft konvertiert. Einige Programme konvertieren implizit beim Öffnen, Kopieren, Einfügen oder Speichern – häufig inkonsistent.

Die meisten textuellen Internetprotokolle (einschließlich HTTP, SMTP, FTP, IRC und viele andere) schreiben die Verwendung von ASCII CR + vor LF („\ r \ n“, 0x0D 0x0A) auf Protokollebene, empfehlen jedoch, dass tolerante Anwendungen auch einzelne LF („\ n“, 0x0A) erkennen. Trotz des diktierten Standards verwenden viele Anwendungen fälschlicherweise die C-Newline-Escape-Sequenz „\ n“ (LF) anstelle der korrekten Kombination aus Wagenrücklauf-Escape und Newline-Escape-Sequenzen „\ r \ n“ (CR + LF) (siehe Abschnitt Newline in Programmiersprachen oben). Diese versehentliche Verwendung der falschen Escape-Sequenzen führt zu Problemen beim Versuch, mit Systemen zu kommunizieren, die sich an die strengere Interpretation der Standards anstelle der vorgeschlagenen toleranten Interpretation halten. Ein solches intolerantes System ist der qmail Mail Transfer Agent, der sich aktiv weigert, Nachrichten von Systemen zu akzeptieren, die nackte LF anstelle der erforderlichen CR + LF senden.

Das Standardformat für Internetnachrichten für E-Mails lautet: CR und LF MUSS treten nur zusammen als CRLF auf; Sie dürfen NICHT unabhängig im Hauptteil angezeigt werden.

Das Dateiübertragungsprotokoll kann Zeilenumbrüche in Dateien, die zwischen Systemen mit unterschiedlichen Zeilenumbruchdarstellungen übertragen werden, automatisch konvertieren, wenn die Übertragung im „ASCII-Modus“ erfolgt.Das Übertragen von Binärdateien in diesem Modus hat jedoch normalerweise katastrophale Folgen: Jedes Auftreten der Zeilenumbruchsequenz, die in diesem Zusammenhang keine Zeilenabschlusssemantik aufweist, sondern nur Teil einer normalen Bytesequenz ist, wird in eine beliebige Zeilenumbruchdarstellung übersetzt Das andere System verwendet die Datei und beschädigt sie effektiv. FTP-Clients verwenden häufig einige Heuristiken (z. B. Überprüfung von Dateinamenerweiterungen), um automatisch entweder den Binär- oder den ASCII-Modus auszuwählen. Letztendlich müssen die Benutzer jedoch sicherstellen, dass ihre Dateien im richtigen Modus übertragen werden. Wenn Zweifel am richtigen Modus bestehen, sollte der Binärmodus verwendet werden, da dann keine Dateien per FTP geändert werden, obwohl sie möglicherweise falsch angezeigt werden.

Konvertierung zwischen ZeilenumbruchformatenEdit

Texteditoren werden häufig zum Konvertieren einer Textdatei zwischen verschiedenen Zeilenumbruchformaten verwendet. Die meisten modernen Editoren können Dateien mit mindestens den verschiedenen ASCII CR / LF-Konventionen lesen und schreiben. Beispielsweise kann der Editor Vim eine Datei mit dem Windows Notepad-Texteditor kompatibel machen. Innerhalb von vim

 :set fileformat=dos :wq

können Editoren für die Konvertierung größerer Dateien oder die Massenkonvertierung vieler Dateien ungeeignet sein. Für größere Dateien (unter Windows NT / 2000 / XP) wird häufig der folgende Befehl verwendet:

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

Zu konvertierende Spezialprogramme Zu den Dateien zwischen verschiedenen Newline-Konventionen gehören unix2dos und dos2unix, mac2unix und unix2mac, mac2dos und dos2mac sowie flip. Der Befehl tr ist auf praktisch jedem Unix-ähnlichen System verfügbar und kann zum Ausführen beliebiger Ersetzungsvorgänge für einzelne Zeichen verwendet werden. Eine DOS / Windows-Textdatei kann in das Unix-Format konvertiert werden, indem einfach alle ASCII-CR-Zeichen mit

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

oder, wenn der Text nur CR-Zeilenumbrüche enthält, durch entfernt werden Konvertieren aller CR-Zeilenumbrüche in LF mit

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

Dieselben Aufgaben werden manchmal mit awk, sed oder in Perl ausgeführt, wenn die Plattform über einen Perl-Interpreter verfügt:

Der Befehl file kann den Typ der Zeilenenden identifizieren:

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

Der Befehl Unix egrep (erweiterter grep) kann zum Drucken von Dateinamen von Unix- oder DOS-Dateien verwendet werden (vorausgesetzt, nur Unix- und DOS-Dateien, kein 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)

Mit anderen Tools kann der Benutzer die EOL-Zeichen visualisieren:

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