Perbedaan antara '\ n' dan '\ r \ n'

Ya ya, saya sadar bahwa '\n'menulis baris baru di UNIX sedangkan untuk Windows ada urutan dua karakter: '\r\n'. Semua ini sangat bagus secara teori, tetapi pertanyaan saya adalah mengapa ? Mengapa karakter carriage return ekstra di Windows? Jika UNIX dapat melakukannya di \nmengapa dibutuhkan Windows dua karakter untuk melakukan ini?

Saya membaca buku Python David Beazley dan dia berkata:

Sebagai contoh, pada Windows, menulis karakter '\ n' sebenarnya menghasilkan urutan dua karakter '\ r \ n' (dan ketika membaca file kembali, '\ r \ n' diterjemahkan kembali menjadi satu '' n ' karakter).

Mengapa perlu upaya ekstra?

Saya akan jujur. Saya sudah tahu perbedaannya sejak lama tetapi tidak pernah repot untuk bertanya MENGAPA. Saya harap itu dijawab hari ini.

Terima kasih atas waktunya.

Kompatibilitas terbalik.

Windows kompatibel dengan MS-DOS (agresif bahkan, bahkan) dan MS-DOS menggunakan konvensi CR-LF karena MS-DOS kompatibel dengan CP / M-80 (agak tidak sengaja) yang menggunakan konvensi CR-LF karena itu adalah cara Anda mengendarai printer (karena printer pada awalnya adalah mesin tik yang dikendalikan komputer).

Printer memiliki perintah terpisah untuk memindahkan kertas ke atas satu baris ke baris baru, dan perintah terpisah untuk mengembalikan media (tempat kertas dipasang) kembali ke margin kiri.

Itu sebabnya. Dan, ya, itu menjengkelkan, tetapi itu adalah bagian dari paket yang memungkinkan MS-DOS untuk menang atas CP / M, dan Windows 95 untuk memenangkan semua GUI lain di atas DOS, dan Windows XP untuk mengambil alih dari Windows 98.

(Catatan: Printer laser modern masih memiliki perintah ini karena mereka juga kompatibel dengan printer sebelumnya - HP khususnya melakukan ini dengan baik)

Bagi mereka yang tidak terbiasa dengan mesin tik, di sini adalah video yang menunjukkan bagaimana pengetikan dilakukan: http://www.youtube.com/watch?v=LJvGiU_UyEQ . Perhatikan bahwa kertas pertama kali dipindahkan ke atas, dan kemudian carriage dikembalikan, bahkan jika itu terjadi dalam gerakan sederhana. Sang ding memberi tahu juru ketik bahwa akhir sudah dekat, dan untuk mempersiapkannya.

Sejauh yang saya tahu ini mengingatkan kembali ke zaman mesin tik.

\r adalah carriage return, yang bergerak di mana Anda mengetik halaman kembali ke kiri (atau kanan jika itu budaya Anda)

\n adalah baris baru, yang memindahkan kertas Anda ke atas.

Melakukan hanya satu ini pada mesin tik akan menempatkan Anda di tempat yang salah untuk mulai menulis baris teks baru.

Ketika komputer muncul saya kira beberapa orang menyimpan model lama, tetapi yang lain menyadari bahwa itu tidak perlu dan merangkum baris baru penuh sebagai satu karakter.

Saya tidak tahu apakah ini pengetahuan umum, tetapi perlu dicatat bahwa CR masih dipahami oleh emulator terminal modern:

$ printf "hey world\rsup\n"
sup world

Ini berguna untuk indikator kemajuan, misalnya

for i in {1..100}
do
    printf "\rLoading... %d%%" $i
    sleep 0.01
done
echo

Secara historis, umpan baris berarti bahwa pelat - roller tempat Anda mengetik - memutar satu baris, menyebabkan teks muncul di baris berikutnya ... tetapi di kolom berikutnya.

Pengembalian kereta berarti "mengembalikan bit yang Anda ketikkan ke awal baris".

Windows menggunakan CR + LF karena MS-DOS melakukannya, karena CP / M melakukannya, karena masuk akal untuk jalur serial.

Unix menyalin konvensi \ nnya karena Multics melakukannya.

Saya menduga jika Anda menggali cukup jauh ke belakang, Anda akan menemukan ketidaksepakatan politik antara pelaksana!

(Anda meninggalkan sedikit kesenangan ekstra, di mana konvensi Mac (atau dulu) hanya menggunakan CR untuk memisahkan baris. Dan sekarang Unicode juga memiliki pemisah baris sendiri, U + 2028!)

Sejarah Karakter Newline (Wikipedia):

ASCII dikembangkan secara bersamaan oleh ISO dan ASA, organisasi pendahulu untuk ANSI. Selama periode 1963-1968, standar rancangan ISO mendukung penggunaan CR + LF atau LF saja sebagai baris baru, sementara draft ASA hanya mendukung CR + LF.

Urutan CR + LF umum digunakan pada banyak sistem komputer awal yang telah mengadopsi mesin teletype, biasanya ASR33, sebagai perangkat konsol, karena urutan ini diperlukan untuk memposisikan printer-printer tersebut pada awal baris baru. Pada sistem ini, teks sering disusun secara rutin agar kompatibel dengan printer ini, karena konsep driver perangkat menyembunyikan detail perangkat keras dari aplikasi belum dikembangkan dengan baik; aplikasi harus berbicara langsung ke mesin teletype dan mengikuti konvensi.

Pemisahan kedua fungsi ini menyembunyikan fakta bahwa print head tidak dapat kembali dari ujung kanan ke awal baris berikutnya dalam waktu satu karakter. Itu sebabnya urutan selalu dikirim dengan CR terlebih dahulu. Bahkan, seringkali perlu untuk mengirim karakter tambahan (CR asing atau NUL, yang diabaikan) untuk memberikan waktu kepala cetak untuk pindah ke margin kiri.

Bahkan setelah teletype digantikan oleh terminal komputer dengan kecepatan baud yang lebih tinggi, banyak sistem operasi masih mendukung pengiriman otomatis karakter pengisi ini, untuk kompatibilitas dengan terminal yang lebih murah yang membutuhkan waktu beberapa karakter untuk menggulir layar.

MS-DOS (1981) mengadopsi CP / M CR + LF; Penggunaan CP + M CR + LF masuk akal untuk menggunakan terminal komputer melalui jalur serial. Konvensi ini diwarisi oleh sistem operasi Windows Microsoft yang lebih baru.

Sistem operasi Multics mulai dikembangkan pada tahun 1964 dan menggunakan LF sendiri sebagai baris baru. Unix mengikuti praktik Multics, dan sistem kemudian mengikuti Unix.

Ada apa dengan orang-orang yang bertanya "mengapa Unix dapat melakukan \ndan bukan Windows"? Ini pertanyaan yang aneh.

1. OS hampir tidak ada hubungannya dengan itu. Ini lebih merupakan masalah bagaimana aplikasi, perpustakaan, protokol, dan format file menangani hal-hal. Selain tempat OS membaca / menulis konfigurasi berbasis teks atau perintah baris perintah, tidak masuk akal untuk menyalahkan OS.
2. Sebagian besar aplikasi Windows dapat membaca keduanya \ndan \r\nbaik-baik saja. Mereka juga menampilkan \r\nsehingga semua orang senang. Suatu program tidak hanya "melakukan" salah satu \natau \r\n- ia menerima satu, yang lain, atau keduanya, dan menghasilkan satu, yang lain, atau keduanya.
3. Sebagai seorang programmer ini seharusnya hampir tidak pernah mengganggu Anda. Praktis setiap bahasa / platform memiliki fasilitas untuk menulis garis akhir yang benar dan membaca paling kuat. Satu-satunya waktu saya harus berurusan dengan masalah adalah ketika saya menulis server HTTP - dan itu karena browser tertentu (petunjuk: browser paling populer berikutnya setelah IE) melakukan \nalih - alih yang benar \r\n .
4. Pertanyaan yang jauh lebih relevan adalah, mengapa begitu banyak aplikasi Unix modern hanya menghasilkan \nsepenuhnya mengetahui bahwa ada beberapa protokol dan program yang tidak menyukainya?

Alasan konvensi bertahan pada berbagai sistem mereka (\ n pada sistem tipe unix, \ r \ n pada Windows, dll) adalah bahwa setelah Anda memilih konvensi, Anda TIDAK dapat mengubahnya tanpa merusak banyak file orang. Dan itu umumnya disukai.

Sistem tipe unix dikembangkan (sangat awal) menggunakan berbagai model teletype, dan pada beberapa titik seseorang memutuskan peralatan harus membawa kembali ketika melakukan feed line.

Windows berasal dari DOS, jadi untuk Windows pertanyaannya adalah: Mengapa DOS menggunakan urutan cr / lf ini? Saya menduga itu ada hubungannya dengan CP / M, di mana DOS memiliki beberapa root itu. Sekali lagi, model teletype tertentu mungkin memainkan peran.

Ini jawaban dari sumber terbaik - Microsoft. Mengapa terminator garis CR + LF?

Protokol ini berasal dari zaman teletypewriter. CR singkatan dari "carriage return" - karakter kontrol CR mengembalikan print head ("carriage") ke kolom 0 tanpa memajukan kertas. LF adalah singkatan dari "linefeed" - karakter kontrol LF memajukan satu baris kertas tanpa menggerakkan print head. Jadi jika Anda ingin mengembalikan print head ke kolom nol (siap untuk mencetak baris berikutnya) dan memajukan kertas (sehingga tercetak di atas kertas baru), Anda membutuhkan CR dan LF.

Jika Anda pergi ke berbagai dokumen protokol internet, seperti RFC 0821 (SMTP), RFC 1939 (POP), RFC 2060 (IMAP), atau RFC 2616 (HTTP), Anda akan melihat bahwa mereka semua menentukan CR + LF sebagai urutan pemutusan garis. Jadi pertanyaan sebenarnya bukan "Mengapa CP / M, MS-DOS, dan Win32 menggunakan CR + LF sebagai terminator garis?" melainkan "Mengapa orang lain memilih untuk berbeda dari dokumen standar ini dan menggunakan beberapa terminator garis lain?"

Unix mengadopsi LF biasa sebagai urutan pemutusan garis. Jika Anda melihat opsi stty, Anda akan melihat bahwa opsi onlcr menentukan apakah LF harus diubah menjadi CR + LF. Jika Anda mendapatkan pengaturan ini salah, Anda mendapatkan teks tangga, di mana

each
    line
        begins

di mana baris sebelumnya tinggalkan. Jadi bahkan unix, ketika dibiarkan dalam mode mentah, membutuhkan CR + LF untuk mengakhiri garis. CR implisit sebelum LF adalah penemuan tunggal, mungkin sebagai ekonomi, karena menghemat satu byte per baris.

Nenek moyang unix bahasa C membawa konvensi ini ke dalam standar bahasa C, yang hanya membutuhkan "\ n" (yang mengkodekan LF) untuk mengakhiri baris, menempatkan beban pada pustaka runtime untuk mengubah data file mentah menjadi baris logis.

Bahasa C juga memperkenalkan istilah "baris baru" untuk mengekspresikan konsep "terminator garis generik". Saya diberitahu bahwa komite ASCII mengubah nama karakter 0x0A menjadi "baris baru" sekitar tahun 1996, sehingga tingkat kebingungan telah dinaikkan lebih tinggi lagi.