it-swarm.dev

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

Evet evet, farkındayım '\n', Windows için iki karakter dizisi varken UNIX'te yeni bir satır yazar: '\r\n'. Bütün bunlar teoride çok güzel, ama sorum neden ? Windows'da satır başı karakteri neden fazla? UNIX bunu \n Bunu yapmak için neden Windows iki karakter gerekiyor?

David Beazley'in Python kitabını okuyorum ve diyor ki:

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

Neden ekstra çaba?

Dürüst olacağım. Farkı uzun zamandır biliyordum, ama NEDEN sormaya hiç uğraşmadım. Umarım bugün cevaplanır.

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

108
sukhbir

Geriye dönük uyumluluk.

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

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

Bu yüzden. Ve, evet, bu bir sıkıntı, ama MS-DOS CP/M üzerinden kazanmak için paket anlaşma ve Windows 95 DOS üstünde diğer tüm GUI kazanmak için izin ve Windows XP.

(Not: Modern lazer yazıcılar hala bu komutlara sahiptir çünkü bunlar önceki yazıcılarla geriye dönük olarak uyumludur - özellikle HP bunu iyi yapar)

Daktilolara aşina olmayanlar için, yazmanın nasıl yapıldığını gösteren bir video: http://www.youtube.com/watch?v=LJvGiU_UyEQ . Kağıdın önce yukarı kaldırıldığına ve sonra basit bir hareketle olsa bile taşıyıcının döndürüldüğüne dikkat edin. Ding daktiloya sonun yaklaştığını ve buna hazırlandığını bildirdi.

133
user1249

Bildiğim kadarıyla bu, daktilo günlerine dayanıyor.

\r, sayfa üzerinde sola (ya da kültürünüzse sağa) yazdığınız yere hareket eden satır başıdır

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

Bunlardan sadece birini daktiloda yapmak, 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 gerekli olmadığını fark etti ve bir karakter olarak tam bir yeni satırı kapsüle etti.

21
Matt Ellen

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

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

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

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

Tarihsel olarak satır besleme, yazdığınız silindir olan Merdanenin bir satır döndürdüğü ve metnin bir sonraki satırda görünmesine neden oldu ... ancak bir sonraki sütunda anlamına geliyordu.

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

Windows, CR-LF kullanır çünkü MS-DOS bunu yapar, çünkü CP/M, seri satırlar için mantıklıdır.

Unix, Multics yaptığı için\n kuralını kopyaladı.

Eğer yeterince geri kazarsanız, uygulayıcılar arasında politik bir anlaşmazlık bulacağınızdan şüpheleniyorum!

(Satırları ayırmak için CR'yi kullanmak için Mac konvansiyonunun (veya eskiden olduğu) ekstra eğlenceli parçayı bıraktınız. Ve şimdi Unicode'un kendi çizgi ayırıcısı U + 2028 var!)

7
Frank Shearar

Yeni Satır Karakterinin Tarihi (Wikipedia):

ASCII, ANSI'nin öncü kuruluşu olan ISO ve ASA tarafından aynı anda geliştirildi. 1963–1968 döneminde ISO taslak standartları, CR + LF veya LF yeni satır olarak tek başına kullanılmasını desteklerken ASA taslakları yalnızca CR + LF'yi destekledi.

CR + LF dizisi, teletype makinelerini, tipik olarak bir ASR33'ü konsol aygıtı olarak benimsemiş birçok erken bilgisayar sisteminde yaygın olarak kullanılıyordu, çünkü bu dizi bu yazıcıları yeni bir hattın başlangıcına yerleştirmek için gerekliydi. Bu sistemlerde, metin genellikle rutin olarak bu yazıcılarla uyumlu olacak şekilde oluşturulmuştur, çünkü bu tür donanım detaylarını uygulamadan gizleyen aygıt sürücüleri kavramı henüz iyi gelişmemiştir; uygulamalar doğrudan teletype makinesiyle konuşmak ve kurallarını takip etmek zorunda kaldı.

İki fonksiyonun ayrılması, baskı kafasının tek karakterli bir zamanda en sağdan bir sonraki satırın başlangıcına dönemediğini gizledi. Bu yüzden dizi her zaman önce CR ile gönderilmiştir. Aslında, yazdırma kafasına sol kenar boşluğuna hareket etmek için zaman vermek üzere genellikle ekstra karakterler (gereksiz CR'ler veya yok sayılan NUL'lar) göndermek gerekiyordu.

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

MS-DOS (1981) CP/M'nin CR + LF'sini kabul etti; CP/M'in CR + LF kullanımı, bilgisayar terminallerini seri hatlar üzerinden kullanmak için anlamlıydı. Bu kural Microsoft'un sonraki Windows işletim sistemi tarafından devralınmıştır.

Multics işletim sistemi 1964'te geliştirilmeye başlandı ve yeni satırı olarak LF kullanıldı. Unix, Multics uygulamasını izledi ve daha sonra Unix'i takip etti.

6
Craige

"Unix neden Windows değil \n yapabilir" sorusunu soran nedir? Çok garip bir soru.

  1. İşletim sisteminin neredeyse hiçbir ilgisi yok. Daha çok uygulamaların, kütüphanelerin, protokollerin ve dosya formatlarının şeylerle nasıl başa çıktığıyla ilgilidir. İşletim sisteminin metin tabanlı yapılandırma veya komut satırı komutlarını okuması/yazması dışında, işletim sistemini arızalı yapmak mantıklı değildir.
  2. Çoğu Windows uygulaması hem \n hem de \r\n okuyabilir. Ayrıca herkes mutlu olmak için \r\n çıktılar. Bir program \n veya \r\n 'i basitçe "yapmaz" - bunu kabul eder birini, diğerini veya her ikisini ve biri, diğeri veya her ikisini çıktılar.
  3. Bir programcı olarak bu gerçekten sizi asla rahatsız etmemelidir . Pratik olarak her dil/platform, doğru son satırı yazmak ve en sağlam şekilde okumak için olanaklara sahiptir. Sorunla başa çıkmak zorunda kaldığım tek zaman, bir HTTP sunucusu - yazdığım ve belirli bir tarayıcının (ipucu: IE'den sonraki en popüler tarayıcı) yaptığı şeydi. doğru\n yerine \r\n.
  4. Daha ilgili bir soru, neden bu kadar çok modern Unix uygulaması sadece \n, onu sevmeyen bazı protokoller ve programlar olduğunu tam olarak bilerek veriyor?
5
Rei Miyasaka

Sözleşmelerin çeşitli sistemlerinde (unix tip sistemlerde\n, Windows'ta\r\n, vb.) Tutulmasının nedeni, bir kongre seçtikten sonra bir grup insan dosyasını bozmadan değiştiremezsiniz. Ve bu genellikle kaşlarını çattı.

Unix tipi sistemler çeşitli teletip modelleri kullanılarak geliştirildi (çok erken günler) ve bir noktada bir kişi, ekipmanın bir hat beslemesi yaptığında 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ı? Ben DOS bazı kökleri vardır CP/M ile ilgili bir şey olduğunu tahmin ediyorum. Yine, belirli teletip modelleri bir rol oynamış olabilir.

4
Michael Kohne

İşte en iyi kaynaktan bir yanıt - Microsoft. Çizgi sonlandırıcı neden CR + LF?

Bu protokol teletypewriters gün dayanmaktadır. CR, "satır başı" anlamına gelir - CR kontrol karakteri, kağıdı ilerletmeden yazdırma kafasını ("satır başı") 0 sütununa döndürür. LF "satır besleme" anlamına gelir - LF kontrol karakteri yazdırma kafasını hareket ettirmeden kağıdı bir satır ilerletmiştir. sütun sıfır (sonraki satırı yazdırmaya hazır) ve kağıdı ilerletir (böylece yeni kağıda yazdırılı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 internet protokol belgelerine giderseniz, hepsinin CR + LF'yi satır sonlandırma sırası. Yani asıl soru "CP/M, MS-DOS ve Win32 neden satır sonlandırıcı olarak CR + LF kullanıyor?" daha ziyade "Neden diğer insanlar bu standart belgelerden farklı olmayı ve başka bir hat sonlandırıcı kullanmayı tercih ettiler?"

Unix, düz LF satır sonlandırma sırası olarak kabul etti. Stty seçeneklerine bakarsanız, onlcr seçeneğinin a LF Bu ayarı yanlış yaparsanız merdiven boşluğu metni alırsınız, burada

each
    line
        begins

önceki satır kalmıştır. Bu nedenle, unix bile ham modda bırakıldığında, satırları sonlandırmak için CR + LF gerektirir. LF) öncesi örtük CR, her satırda bir bayt kaydettiği için, muhtemelen bir ekonomi olarak unix bir buluştur.

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

C dili "jenerik hat sonlandırıcı" kavramını ifade etmek için "yeni satır" terimini de tanıttı. Bana ASCII komitesinin 1996 yılında 0x0A karakterinin adını "newline" olarak değiştirdiği söylendi, bu yüzden karışıklık seviyesi daha da yükseldi.

2
Ondra Žižka