CRLF Tidak Lagi Digunakan dan Harus Dihapuskan

Definisi carriage return dan line feed

• Carriage return (CR): memindahkan kursor ke margin kiri pada baris yang sama
• Line feed (LF): memindahkan kursor satu baris ke bawah dan menggulir baris-baris sebelumnya ke atas
• Newline (NL): memindahkan kursor satu baris ke bawah dan ke margin kiri

Pengamatan

• CR dan NL adalah karakter kontrol yang berguna. NL adalah operasi yang paling umum, memulai baris teks baru dari margin kiri
• LF pada praktiknya tidak berguna. Tidak ada yang ingin turun ke baris berikutnya dari tengah baris lalu terus menulis pada kolom yang sama
• LF berasal dari era mesin teletype mekanis sekitar 70 tahun lalu

Latar belakang historis

• Teletype mencetak sekitar 5 karakter per detik
• Tradisi CRLF berasal dari keterbatasan mekanis teletype pada tahun 1950-an
• Pada era Multix dan Unix, makin luas disadari bahwa menggunakan CRLF untuk NL itu tidak efisien

Situasi modern

• Saat ini CR direpresentasikan sebagai U+000d, sedangkan LF dan NL sebagai U+000a
• Sebagian besar mesin modern hanya menggunakan U+000a sebagai NL
• Beberapa protokol masih mensyaratkan CRLF, tetapi sebagian besar perangkat lunak menerima NL tunggal

Seruan untuk bertindak

• Ubah nama code point U+000a dari "line feed" menjadi "newline"
• Hentikan pengiriman CR yang tidak perlu
• Untuk protokol yang mewajibkan CRLF, kirim hanya NL
• Perbaiki perangkat lunak yang memunculkan kesalahan saat menerima NL tanpa CR

Ringkasan dan penulis

• Akhir dari CRLF sudah lama diperlukan. Kita harus bekerja bersama untuk menyingkirkan peninggalan kuno ini
• Penulis: D. Richard Hipp, pendiri SQLite

# Ringkasan GN⁺

• Tulisan ini menjelaskan latar belakang historis dan ketidakefisienan CRLF di era modern, serta menyerukan agar praktik ini dihapuskan
• CRLF adalah tradisi yang berasal dari keterbatasan mekanis dan kini menimbulkan kompleksitas yang tidak perlu
• Topik ini dapat sangat berguna khususnya bagi programmer dan pengembang perangkat lunak, serta penting untuk efisiensi transmisi data
• Saat menggunakan protokol atau sistem lain dengan fungsi serupa, kebutuhan akan CRLF juga perlu dipertimbangkan ulang

[cosine20]

Saya kadang memakai line feed....

[doolayer]

Cukup ekstrem ya, ngeri banget

[savvykang]

Menurut revisi pada 14 Oktober, usulan perubahan tersebut akan ditarik.

Ini bukan sekadar mengubah satu sistem, melainkan pekerjaan yang mengharuskan protokol dan semua sistem yang terdampak diubah secara bertahap, jadi menurut saya penulisnya kurang berhati-hati.

[constexprif]

Apakah mereka menganggap manfaat yang didapat dengan menghapusnya lebih besar daripada biaya untuk menghapusnya?

[alstjr7375]

CR+LF punya sejarah yang panjang...

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

Oh.. jadi ini alasannya..

[bakyeono]

CRLF bukan spesifikasi yang didefinisikan secara keliru, melainkan mencerminkan lingkungan perangkat keras pada masanya...
Sepertinya orang melupakan kompatibilitas mundur dan hanya memikirkan saat ini.
Apakah kita harus merombak protokol setiap kali spesifikasi perangkat keras berubah?

[halfenif]

Saya tidak mendukung maupun menentang penghapusannya.

Kenapa ya ini malah mengingatkan saya pada bug milenium?

[GN⁺]

Komentar Hacker News

• Memperbarui protokol lama ke NL dapat menimbulkan bug potensial, dan HTTP/1.1 sudah digantikan oleh HTTP/2
  • Untuk protokol baru, masuk akal jika tidak mewajibkan CRLF, tetapi tidak perlu memperbarui protokol yang sudah ada
• Tidak mematuhi CRLF sama saja dengan sengaja memasukkan bug
  • Server HTTP SQLite diperbarui agar menggunakan \n alih-alih \r\n, tetapi ini merusak kompatibilitas dengan klien HTTP Zig
• Ada pendapat bahwa CRLF sebaiknya dibuat tidak perlu dipikirkan lagi oleh generasi mendatang
  • Mereka berpendapat bahwa kita harus mengajarkan cara memakai file .gitattribute dan mendidik orang agar membenci Byte Order Mark
• Pilihan Unix yang tidak standar untuk akhiran baris adalah sebuah kesalahan, dan ini telah menimbulkan masalah kompatibilitas selama puluhan tahun
  • CRLF adalah dua bagian berbeda dari API terminal, dan banyak program bergantung pada cara kerja CR dan LF yang benar
• CRLF adalah salah satu elemen yang paling tidak penting dalam standar
  • Merusak standar adalah upaya yang baru, dan secara pribadi terasa sebagai sikap yang asing
• SMTP dengan jelas menyatakan bahwa urutan akhir pesan adalah CR LF . CR LF, dan ada juga implementasi yang mengenali LF . LF
  • Mungkin aturan SMTP yang asli sudah tidak lagi penting
• CRLF dapat menimbulkan risiko bagi banyak perangkat, sehingga pengecualian harus dikurangi
• Tidak ada penyebutan tentang masalah yang muncul saat akhiran baris dicampur
  • Karakter bernama NL tidak ada, dan tombol "ENTER" pada semua keyboard mengirimkan CR
  • Cara yang sekarang sudah bekerja dengan baik