'\ N' ve '\ r \ n' arasındaki fark

Evet, '\n'Windows için iki karakter sırası varken UNIX'te yeni bir satır yazdığını biliyorum '\r\n'. Bütün bunlar teoride çok hoş, ama benim sorum neden ? Neden satır başı karakteri Windows’da fazladır? UNIX bunu yapabiliyorsa \nneden bunu yapmak için Windows iki karakter gerekiyor?

David Beazley'in Python kitabını okuyorum ve şöyle diyor:

Örneğin, Windows'ta '\ n' karakterini yazmak aslında '\ r \ n' iki karakter dizisini çıkarır (ve dosyayı geri okurken, '\ r \ n' tek bir '\ n' haline çevrilir. karakter).

Neden ekstra çaba?

Dürüst olacağım. Aradaki farkı uzun zamandır biliyordum, ancak WHY'ye sormak için canınızı sıkmadım. Umarım bugün cevaplanır.

Zaman ayırdığınız için teşekkürler.

Geriye dönük uyumluluk.

Windows geriye dönük olarak MS-DOS ile uyumludur (agresif şekilde, hatta) ve MS-DOS, CR-LF kuralını kullanmıştır, çünkü MS-DOS, CR-LF kuralını kullanan CP / M-80 (bir şekilde yanlışlıkla) ile uyumludur. Bir yazıcıyı nasıl sürdüğünüzdü (çünkü yazıcılar aslında bilgisayar kontrollü daktilolardı).

Yazıcılarda kağıdı bir satır yukarıdan yeni bir satıra taşımak için ayrı bir komut ve taşıyıcıyı (kağıdın yerleştirildiği yer) tekrar sol kenar boşluğuna döndürmek için ayrı bir komut bulunur.

Bu yüzden. Ve, evet, bu bir sıkıntıdır, ancak MS-DOS'un CP / M ve Windows 95’in DOS’un diğer tüm GUI’lerini ve Windows XP’nin de üstlenmesini sağlayan paket anlaşmasının bir parçasıdır Windows 98'den.

(Not: Modern lazer yazıcılarda hala bu komutlar vardır, çünkü bunlar daha önceki yazıcılarla da geriye dönük uyumludur - özellikle HP bunu yapar)

Daktilo ile aşina olmayanlar için, burada yazmanın nasıl yapıldığını gösteren bir video var: http://www.youtube.com/watch?v=LJvGiU_UyEQ . Kağıdın önce yukarı kaldırıldığına ve sonra basit bir hareket olsa bile taşıyıcıya geri döndüğüne dikkat edin. Ölüm, daktiloya sonun yakın olduğunu ve bunun için hazırlandığını bildirdi.

Bildiğim kadarıyla bu daktilo günlerine geri dönüyor.

\r satır başıdır; bu, sayfada yazdığınız yere sola geri döner (ya da kültürünüz buysa sağ)

\n Bu, kağıdınızı bir satır yukarı taşıyan yeni satırdır.

Bir daktiloda bunlardan sadece birini yapmak sizi yeni bir metin satırı yazmaya başlamak için yanlış yere koyar.

Bilgisayarlar ortaya çıktığında, bazı insanlar eski modeli korudular, ancak diğerleri bunun gerekmediğini fark etti ve yepyeni bir karakteri bir karakter olarak kapsıyordu.

Bunun ortak bir bilgi olup olmadığını bilmiyorum, ancak CR'nin hala modern terminal emülatörleri tarafından anlaşıldığı unutulmamalıdır:

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

İlerleme göstergeleri için kullanışlıdır, örneğin

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

Tarihsel olarak, satır besleme, merdanenin - üzerine yazdığınız silindirin - bir satır döndürdüğü, metnin bir sonraki satırda görünmesine neden olduğu anlamına gelir ... bir sonraki sütunda.

Satır başı, "satırın başına yazdığınız bit değerini döndür" anlamına geliyordu.

Windows CR + LF kullanır çünkü MS-DOS, CP / M kullandığı için seri hatlar için anlamlıdır.

Unix, \ n kuralını kopyaladı çünkü Multics bunu yaptı.

Yeterince geri kazarsan, uygulayıcılar arasında siyasi bir anlaşmazlık bulacaksın diye düşünüyorum.

(Mac konvansiyonunun sadece CR'yi satırları ayırmak için kullandığı (veya eskiden olduğu) ekstra eğlenceli bit bıraktınız. Ve şimdi Unicode'un ayrıca U + 2028!

Newline Karakterinin Tarihi (Wikipedia):

ASCII, ISO ve ASA tarafından eşzamanlı olarak ANSI'ye bağlı bir organizasyon olarak geliştirildi. 1963–1968 döneminde, ISO taslak standartları yeni bir satır olarak sadece CR + LF veya LF kullanımını desteklerken, ASA taslakları sadece CR + LF'yi destekledi.

CR + LF sekansı, teletip makinelerini, tipik olarak bir ASR33'ü konsol aygıtı olarak benimseyen birçok erken bilgisayar sisteminde ortak kullanımdaydı, çünkü bu sekans, bu yazıcıları yeni bir hattın başında konumlandırmak için gerekliydi. Bu sistemlerde, metin genellikle rutin olarak bu yazıcılarla uyumlu olacak şekilde oluşturulmuştur, çünkü uygulamadan bu tür donanım ayrıntılarını gizleyen aygıt sürücüleri kavramı henüz iyi gelişmemiştir; uygulamaların doğrudan teletype makinesiyle konuşması ve kurallarına uyması gerekiyordu.

İki fonksiyonun ayrılması, baskı kafasının bir karakterlik sürede en sağdan bir sonraki satırın başına dönemediği gerçeğini gizliyordu. Bu yüzden dizisi daima ilk önce CR ile birlikte gönderildi. Aslında, baskı kafasının sol kenar boşluğuna geçmesi için zaman vermek için fazladan karakterler (yabancı CR'ler veya NUL'lar göz ardı edilir) göndermek genellikle gerekliydi.

Teletipler, yüksek baud oranlarına sahip bilgisayar terminalleri ile değiştirildikten sonra bile, birçok işletim sistemi, ekranı kaydırmak için birden çok karakter süresi gerektiren daha ucuz terminallerle uyumluluk için, bu doldurma karakterlerinin otomatik olarak gönderilmesini destekledi.

MS-DOS (1981) CP / M'in CR + LF'yi; CP / M'nin CR + LF kullanımı, bilgisayar terminallerini seri hatlarla kullanmak için anlamlıydı. Bu sözleşme Microsoft'un sonraki Windows işletim sistemi tarafından miras alınmıştır.

Multics işletim sistemi 1964'te gelişmeye başladı ve LF'yi yeni hattı olarak tek başına kullandı. Unix Multics uygulamasını takip etti ve daha sonra sistemler Unix'i takip etti.

İnsanların "Unix neden \nWindows'la yapıp yapamayacağını" soranlarla ilgili sorunu nedir? Bu çok garip bir soru.

1. İşletim sisteminin bununla hiçbir ilgisi yok. Uygulamaların, kütüphanelerin, protokollerin ve dosya formatlarının işlerle nasıl başa çıktığı meselesidir. İşletim sisteminin metin tabanlı konfigürasyon veya komut satırı komutlarını okuduğu / yazdığı yer dışında, işletim sistemi hatasında bir şey ifade etmez.
2. Çoğu Windows uygulamaları olabilir hem okumak \nve \r\ngayet güzel. Ayrıca \r\nherkesin mutlu olması için çıktılar . Bir program basitçe "do" ya gelmez \nya \r\n- bu kabul birini diğeri ya da her ikisi, ve çıkışları , diğeri veya her ikisi.
3. Bir programcı olarak bu gerçekten sizi asla rahatsız etmemelidir. Pratik olarak her dilin / platformun doğru bitiş çizgisini yazma ve en güçlü şekilde okuma olanakları vardır. Sorunla uğraşmam gereken tek zaman bir HTTP sunucusu yazdığım zamandı - ve bunun kesin bir tarayıcı (ipucu: IE’den sonraki en popüler tarayıcı) doğru\n yerine yapmasıydı \r\n .
4. Çok daha önemli bir soru, neden bu kadar çok sayıda modern Unix uygulamasının \nbeğenmediğini sadece bazı protokoller ve programlar olduğunu bilerek çıkarıyor?

Sözleşmelerin çeşitli sistemlerinde (unix tipi sistemlerde \ n, Windows'da \ r \ n, vb.) Geçerli olmasının nedeni, bir sözleşmeyi seçtiğinizde, bir grup insanı dosyalarına ayırmadan değiştiremeyeceğinizdir. Ve bu genellikle üzerine kaşlarını çattı.

Unix tipi sistemler, çeşitli teletip modelleri kullanılarak (çok erken günlerde) geliştirildi ve bir noktada birisi, bir hat beslemesi yaptığında ekipmanın geri dönmesi gerektiğine karar verdi.

Windows DOS'tan geldi, bu yüzden Windows için soru gerçekten: DOS neden bu cr / lf dizisini kullandı? DOS'un bazı köklerinin olduğu CP / M ile bir ilgisi olduğunu tahmin ediyorum. Yine, belirli teletype modelleri bir rol oynamış olabilir.

İşte en iyi kaynaktan bir cevap - Microsoft. Satır sonlandırıcı neden CR + LF?

Bu protokol teletipewriters günlerine dayanıyor. CR "satır başı" anlamına gelir - CR kontrol karakteri, kağıdı ilerletmeden yazıcı kafasını ("satır başı") 0 sütununa döndürdü. LF "satır besleme" anlamına gelir - LF kontrol karakteri, yazdırma kafasını hareket ettirmeden kağıdı bir satır ilerletir. Bu nedenle, baskı kafasını sıfır sütununa (bir sonraki satırı yazdırmaya hazır) iade etmek ve kağıdı ilerletmek istiyorsanız (böylece yeni kağıda yazdırır), hem CR hem de LF'ye ihtiyacınız vardır.

RFC 0821 (SMTP), RFC 1939 (POP), RFC 2060 (IMAP) veya RFC 2616 (HTTP) gibi çeşitli İnternet protokolü belgelerine giderseniz, hepsinin CR + LF olarak belirtildiğini göreceksiniz. hat sonlandırma sırası. Bu nedenle asıl soru "Neden CP / M, MS-DOS ve Win32 satır sonlandırıcı olarak CR + LF kullanıyor?" bunun yerine "Neden diğer insanlar bu standart belgelerden farklı olmayı seçtiler ve başka bir satır sonlandırıcı kullandılar?"

Unix, hat sonlandırma dizisi olarak düz LF'yi benimsemiştir. Stty seçeneklerine bakarsanız, onlcr seçeneğinin bir LF'nin CR + LF olarak değiştirilip değiştirilmeyeceğini belirttiğini göreceksiniz. Bu ayarı yanlış yaparsanız, merdiven basamağı metni alırsınız, nerede

each
    line
        begins

önceki satırın kaldığı yerden. Bu nedenle, unix, ham modda bırakıldığında, satırları sonlandırmak için CR + LF gerektirir. LF'den önce gelen CR, satır başına bir bayt tasarruf ettiğinden, muhtemelen bir ekonomi olarak unix bir buluştur.

C dilinin unix atağı, bu sözleşmeyi satırları sonlandırmak için yalnızca "\ n" (LF'yi kodlayan) gerektiren ve böylece ham dosya verilerini mantıksal satırlara dönüştürmek için çalışma zamanı kitaplıkları üzerindeki yükü yükleyen C dili standardına taşıdı.

C dili aynı zamanda "jenerik hat sonlandırıcı" kavramını ifade etmek için "newline" terimini de kullandı. ASCII komitesine 1996 yılında 0x0A karakterinin adını "newline" olarak değiştirdim, böylece karışıklık seviyesi daha da yükseldi.