CRLF wird nicht mehr verwendet und sollte abgeschafft werden

Definition von Carriage Return und Line Feed

• Carriage Return (CR): Bewegt den Cursor an den linken Rand derselben Zeile
• Line Feed (LF): Bewegt den Cursor eine Zeile nach unten und scrollt die vorherigen Zeilen nach oben
• Newline (NL): Bewegt den Cursor eine Zeile nach unten und an den linken Rand

Beobachtungen

• CR und NL sind nützliche Steuerzeichen. NL ist die gebräuchlichste Operation, bei der eine neue Textzeile am linken Rand beginnt
• LF ist praktisch nutzlos. Niemand möchte mitten in einer Zeile in die nächste Zeile wechseln und in derselben Spalte weiterschreiben
• LF stammt aus der Ära mechanischer Fernschreiber vor etwa 70 Jahren

Historischer Hintergrund

• Fernschreiber druckten etwa 5 Zeichen pro Sekunde
• Die CRLF-Tradition entstand aus den mechanischen Beschränkungen von Fernschreibern in den 1950er Jahren
• In der Multix- und Unix-Ära setzte sich die Erkenntnis durch, dass es ineffizient ist, CRLF als NL zu verwenden

Die heutige Situation

• Heute wird CR als U+000d dargestellt, LF und NL als U+000a
• Die meisten modernen Maschinen verwenden U+000a nur als NL
• Einige Protokolle verlangen weiterhin CRLF, aber die meiste Software akzeptiert ein einzelnes NL

Aufruf zum Handeln

• Den Namen des Codepunkts U+000a von "Line Feed" in "Newline" ändern
• Die Übertragung unnötiger CR beenden
• Bei Protokollen, die CRLF verlangen, nur NL übertragen
• Software korrigieren, die einen Fehler auslöst, wenn sie NL ohne CR empfängt

Zusammenfassung und Autor

• Das Ende von CRLF ist seit Langem überfällig. Wir sollten gemeinsam daran arbeiten, dieses überholte Relikt zu beseitigen
• Autor: D. Richard Hipp, Gründer von SQLite

# GN⁺-Zusammenfassung

• Dieser Artikel erklärt den historischen Hintergrund und die heutige Ineffizienz von CRLF und fordert seine Abschaffung
• CRLF ist eine Tradition, die aus mechanischen Beschränkungen entstand und heute unnötige Komplexität verursacht
• Dieses Thema kann besonders für Programmierer und Softwareentwickler nützlich sein und ist für eine effiziente Datenübertragung wichtig
• Auch bei der Verwendung anderer Protokolle oder Systeme mit ähnlicher Funktionalität sollte die Notwendigkeit von CRLF überdacht werden

[cosine20]

Ich verwende manchmal Zeilenvorschub....

[doolayer]

Ganz schön radikal.

[savvykang]

Laut einer Korrektur vom 14. Oktober wird der Änderungsvorschlag zurückgezogen.

Es geht dabei nicht einfach darum, nur ein einzelnes System zu ändern, sondern darum, das Protokoll und alle betroffenen Systeme schrittweise umzustellen. Meiner Ansicht nach war der Autor dabei wohl nicht vorsichtig genug.

[constexprif]

Dachten sie wohl, dass der Nutzen der Abschaffung größer ist als die Kosten dafür?

[alstjr7375]

CR+LF hat eine lange Geschichte...

• https://www.revk.uk/2022/02/crlf-has-long-history.html

Oh … das ist also der Grund ..

[bakyeono]

CRLF ist keine falsch definierte Spezifikation, sondern spiegelt die damalige Hardwareumgebung wider...
Es wirkt, als würde man die Abwärtskompatibilität vergessen und nur an den Moment denken.
Sollen wir die Protokolle jedes Mal komplett umkrempeln, wenn sich die Hardware-Spezifikationen ändern?

[halfenif]

Ich bin weder dafür noch dagegen, es abzuschaffen.

Warum muss ich dabei nur an den Millennium-Bug denken?

[GN⁺]

Hacker-News-Kommentare

• Die Aktualisierung bestehender Protokolle auf NL kann potenzielle Bugs verursachen, und HTTP/1.1 wurde bereits durch HTTP/2 ersetzt
  • Bei neuen Protokollen ist es sinnvoll, kein CRLF zu verlangen, aber es wird argumentiert, dass bestehende Protokolle nicht aktualisiert werden müssen
• CRLF nicht einzuhalten, kommt dem absichtlichen Einführen von Bugs gleich
  • Der HTTP-Server von SQLite wurde so aktualisiert, dass er statt \r\n \n verwendet, was jedoch die Kompatibilität mit dem HTTP-Client von Zig beeinträchtigt
• Es gibt die Meinung, dass sich künftige Generationen nicht mehr um CRLF kümmern müssen sollten
  • Man solle den Umgang mit der .gitattribute-Datei lehren und dazu erziehen, das Byte Order Mark (BOM) abzulehnen
• Die nicht standardisierte Wahl von Unix für Zeilenenden war ein Fehler, der über Jahrzehnte zu Kompatibilitätsproblemen geführt hat
  • CRLF sind zwei verschiedene Teile der Terminal-API, und viele Programme sind auf das korrekte Funktionieren von CR und LF angewiesen
• CRLF ist eines der am wenigsten wichtigen Elemente in Standards
  • Standards zu brechen ist ein neuer Versuch und wirkt persönlich betrachtet befremdlich
• SMTP stellt klar, dass die Sequenz zum Nachrichtenende CR LF . CR LF ist, und es gibt auch Implementierungen, die LF . LF erkennen
  • Die ursprünglichen SMTP-Regeln sind möglicherweise nicht mehr wichtig
• CRLF kann für viele Geräte ein Risiko darstellen, und Ausnahmen sollten reduziert werden
• Es gibt keine Erwähnung der Probleme, die beim Mischen von Zeilenenden entstehen
  • Ein Zeichen namens NL existiert nicht, und die "ENTER"-Taste auf allen Tastaturen sendet CR
  • Die derzeitige Vorgehensweise funktioniert gut