Yeni hat - Newline

"Merhaba" ve "dünya" kelimeleri arasına eklenen yeni satır

Yeni satır (sık aranan bitiş çizgisi , satır sonu ( EOL ), bir sonraki hat ( NEL ) ya da satır sonu ) a, kontrol karakteri bir ya da kontrol karakter dizisi karakter kodlamasını tarifnamede (örneğin, ASCII , EBCDIC ) kullanılır belirtmek için bir metin satırının sonu ve yeni bir satırın başlangıcı, örneğin Unix'te Satır Besleme ( LF ) . Bazı metin düzenleyiciler, tuşa basıldığında bu özel karakteri ayarlar . ↵ Enter

Bir metin dosyasını görüntülerken (veya yazdırırken) , bu kontrol karakteri veya karakter dizisi, metin düzenleyicinin onu takip eden karakterleri yeni bir satırda göstermesine neden olur.

Tarih

1800'lerin ortalarında, teleyazıcıların ve teletype makinelerinin ortaya çıkmasından çok önce , Mors kodu operatörleri veya telgrafçılar , resmi yazılı metin mesajlarında beyaz boşluk metin formatını kodlamak için Mors kodu prosign'larını icat etti ve kullandı . Özellikle Morse PROSIGN BT (anımsatıcı b reak t ait birleştirme ile temsil edilen dahili) hazır metinsel mors kodları, "B" ve normal karakterler arası boşluk olmadan gönderilen "T" karakter kodlamak Morse kodu kullanılır ve bir işaret olan yeni bir satır veya resmi bir metin mesajındaki yeni bölüm .

Daha sonra, modern teleprinterlar çağında, beyaz boşluk metin biçimlendirmesine yardımcı olmak için standartlaştırılmış karakter seti kontrol kodları geliştirildi. ASCII, Uluslararası Standardizasyon Örgütü (ISO) ve Amerikan Standartlar Birliği (ASA) tarafından eş zamanlı olarak geliştirilmiştir , ikincisi Amerikan Ulusal Standartlar Enstitüsü'nün (ANSI) öncülüdür . 1968 1963 döneminde, ISO taslak standartları ya kullanımını desteklenen CR + LF veya LF ASA yalnızca desteklenen taslaklar ise, yalnız bir yeni satır olarak CR + LF .

CR + LF dizisi , Teletype makinelerini (tipik olarak Teletype Model 33 ASR) bir konsol cihazı olarak benimseyen birçok erken bilgisayar sisteminde yaygın olarak kullanıldı , çünkü bu dizilim, bu yazıcıları yeni bir hattın başlangıcında konumlandırmak için gerekliydi. Yeni satırın iki işleve ayrılması, yazıcı kafasının bir sonraki karakteri yazdırmak için zaman içinde en sağdan sonraki satırın başına dönemeyeceği gerçeğini gizledi. Bir sonra basılmış herhangi bir karakter CR baskı kafası hala ilk pozisyona taşıma geri hareket ederken genellikle sayfanın ortasında bir leke olarak yazdırmak istiyorum. "Çözüm yeni satırı iki karakter yapmaktı: Taşıyıcıyı birinci sütuna taşımak için CR ve kağıdı yukarı taşımak için LF ." Aslında, genellikle göz ardı edilen ancak yazıcı kafasının sol kenar boşluğuna gitmesi için zaman tanıyan fazladan karakterler (harici CR'ler veya NUL'ler) göndermek gerekliydi. Birçok erken video gösterimi , ekranı kaydırmak için birden fazla karakter zamanı gerektiriyordu .

Bu tür sistemlerde, uygulamaların bu tür donanım ayrıntılarını uygulamadan gizleyen aygıt sürücüleri kavramı henüz yeterince geliştirilmediği için, uygulamaların doğrudan Teletype makinesiyle konuşması ve onun kurallarını izlemesi gerekiyordu . Bu nedenle, Teletype makinelerinin ihtiyaçlarını karşılamak için metin rutin olarak oluşturulmuştur. Dan Çoğu mini bilgisayar sistemleri DEC bu kuralı kullanılır. CP/M , mini bilgisayarların kullandığı aynı terminallere yazdırmak için de kullandı. Orada itibaren MS-DOS (1981) kabul edilen CP / M 'nin CR + LF uyumlu olması için, ve bu kongre Microsoft'un sonradan miras kaldı , Windows işletim sistemi.

Multics işletim sistemi 1964 yılında gelişmeye başlayan ve ikinci el LF onun yeni satır olarak tek başına. Multics, bu karakteri bir yazıcının ihtiyaç duyduğu sıraya (ekstra dolgu karakterleri dahil) çevirmek için bir aygıt sürücüsü kullandı ve tek bayt programlama için daha uygundu. Daha açık bir seçim gibi görünen CR kullanılmadı, çünkü CR , kalın ve üstü çizili efektler oluşturmak için bir satırı diğeriyle üst üste basmanın yararlı işlevini sağladı . Belki daha da önemlisi, hat sonlandırıcı olarak tek başına LF kullanımı , nihai ISO/IEC 646 standardının taslaklarına zaten dahil edilmişti . Unix , Multics uygulamasını izledi ve daha sonra Unix benzeri sistemler Unix'i izledi. Bu, Windows ve Unix benzeri işletim sistemleri arasında , bir işletim sisteminde oluşturulan dosyaların başka bir işletim sistemi tarafından uygun şekilde biçimlendirilemeyeceği veya yorumlanamayacağı (örneğin, Notepad gibi bir Windows metin düzenleyicisinde yazılmış bir UNIX kabuk komut dosyası) çelişkiler yarattı .

temsil

Kavramları satır başı (CR) ve hat besleme (LF) yakın ilişkilidir ve ayrı ayrı ya da birlikte düşünülebilir. Daktilo ve yazıcıların fiziksel ortamında , sayfada yeni bir satır oluşturmak için "aşağı" ve "karşı" olmak üzere iki hareket eksenine ihtiyaç vardır . Bir makinenin tasarımı (daktilo veya yazıcı) bunları ayrı ayrı ele almak zorunda olsa da, yazılımın soyut mantığı bunları tek bir olay olarak birleştirebilir. Bu nedenle karakter kodlamasında yeni satır olarak tanımlanabilir ve tek bir satırda birleştirilebilir (genellikle veya olarak adlandırılır ). CRLFCR+LFCRLF

Bazı karakter kümeleri ayrı bir yeni satır karakter kodu sağlar. EBCDIC , örneğin, CR ve LF kodlarına ek olarak bir NL karakter kodu sağlar . Unicode , ASCII CR ve LF kontrol kodlarını sağlamanın yanı sıra , bir "sonraki satır" ( NEL ) kontrol kodunun yanı sıra "satır ayırıcı" ve "paragraf ayırıcı" işaretçileri için kontrol kodları da sağlar.

• EBCDIC sistemleri—özellikle z/OS ( OS/390 ) ve IBM i ( OS/400 ) dahil olmak üzere IBM anabilgisayar sistemleri— satır besleme ve satırbaşı işlevlerini birleştiren karakter olarak NL (New Line, 0x15 ) kullanır. Eşdeğer Unicode karakterine ( ) NEL (Sonraki Satır) adı verilir . EBCDIC ayrıca CR ve LF adlı kontrol karakterlerine sahiptir , ancak LF'nin ( 0x25 ) sayısal değeri ASCII ( 0x0A ) tarafından kullanılandan farklıdır . Ek olarak, bazı EBCDIC türevleri de NL kullanır ancak karaktere farklı bir sayısal kod atar. Ancak, bu işletim sistemleri , metin dosyalarını satır başına bir kayıt olarak depolayan kayıt tabanlı bir dosya sistemi kullanır . Çoğu dosya biçiminde, gerçekte hiçbir satır sonlandırıcı depolanmaz.0x85
• CDC 6000 serisinin işletim sistemleri, yeni satırı 60 bitlik bir kelimenin sonundaki iki veya daha fazla sıfır değerli altı bitlik karakter olarak tanımladı. Bazı konfigürasyonlar ayrıca sıfır değerli bir karakteri iki nokta üst üste karakteri olarak tanımladı ve bunun sonucunda, konuma bağlı olarak birden çok iki nokta üst üste işareti yeni satır olarak yorumlanabilir.
• RSX-11 ve OpenVMS ayrıca metin dosyalarını satır başına bir kayıt olarak depolayan kayıt tabanlı bir dosya sistemi kullanır. Çoğu dosya biçiminde, hiçbir satır sonlandırıcı gerçekte depolanmaz, ancak Kayıt Yönetim Hizmetleri tesisi, bir uygulama tarafından alındığında her satıra şeffaf bir şekilde bir sonlandırıcı ekleyebilir. Kayıtların kendileri, uygulamaya bağlı olarak bir özellik veya sıkıntı olarak kabul edilebilecek aynı satır sonlandırıcı karakterlerini içerebilir. RMS, yalnızca kayıtları saklamakla kalmaz, aynı zamanda dosyanın işleri daha da karmaşık hale getirmesi için kayıt ayırıcılarla ilgili meta verileri farklı bitlerde depolar (çünkü dosyalar sabit uzunlukta kayıtlara, bir sayı ile ön eklenmiş kayıtlara veya belirli bir karakterle sonlandırılan kayıtlara sahip olabilir). ). Bitler genel değildi, bu nedenle CR LF veya LF veya hatta CR'nin satır sonlandırıcı olduğunu belirtebilseler de , başka bir kodun yerine geçemezdi.
• Sabit hat uzunluğu , bazı erken anabilgisayar işletim sistemleri tarafından kullanılmıştır . Böyle bir sistemde, örneğin, her 72 veya 80 karakterde bir örtülü satır sonu olduğu varsayılır. Yeni satır karakteri kaydedilmedi. Bir dosya dış dünyadan içe aktarılmışsa, satır uzunluğundan daha kısa satırlar boşluklarla doldurulmalı, satır uzunluğundan daha uzun satırlar ise kesilmeliydi. Bu , her satırın ayrı bir kartta depolandığı delikli kartların kullanımını taklit etti , genellikle her kartta 80 sütun, genellikle 73-80 sütunlarında sıra numaraları vardı. Bu sistemlerin birçoğu bir katma vagonu kontrol karakteri başlamasından sonraki rekor; bu, sonraki kaydın önceki kayıt tarafından başlatılan satırın devamı mı yoksa yeni bir satır mı olduğunu veya önceki satırın üzerine yazdırılması gerektiğini ( CR'ye benzer ) gösterebilir . Genellikle bu normal bir baskı karakteriydi, #bu nedenle bir satırdaki ilk karakter olarak kullanılamazdı. Bazı erken satır yazıcıları, bu karakterleri doğrudan kendilerine gönderilen kayıtlarda yorumladı.

tek kod

Unicode standardı uygun uygulamalar satır sonlandırıcı olarak tanıması gerektiğini karakterlerin sayısını tanımlar:

  LF :   Satır Besleme, U+000A

 VT : Dikey Sekme , U+000B   

 FF : Form Besleme , U+000C   

 CR : Satır Başı , U+000D   

 CR + LF : CR ( U+000D ) ardından LF ( U+000A )

 NEL :  Sonraki Satır, U+0085

 LS :   Hat Ayırıcı, U+2028

 Not :   Paragraf Ayırıcı, U+2029

Bu, tüm satır sonlandırıcıları tek bir karaktere dönüştürmek gibi bir yaklaşımla karşılaştırıldığında aşırı karmaşık görünebilir, örneğin LF . Ancak Unicode, bir metin dosyasını mevcut herhangi bir kodlamadan Unicode'a ve geriye dönüştürürken tüm bilgileri korumak için tasarlanmıştır. Bu nedenle, Unicode, mevcut kodlamalarda bulunan karakterleri içermelidir.

Örneğin: NL parçası olan EBCDIC kodu kullanır 0x15 ; normalde C1 kontrol setinde bir kontrol karakteri olan Unicode NEL , 0x85 ile eşlenir . Bu nedenle, ECMA 48 tarafından tanımlanır ve ISO/IEC 2022 (ECMA 35'e eşdeğerdir) ile uyumlu kodlamalarla tanınır . C1 kontrol seti ayrıca ISO-8859-1 ile uyumludur . Unicode standardında benimsenen yaklaşım, uygulamaların olası tüm hat sonlandırıcı türlerini tanımasını sağlarken, gidiş-dönüş dönüşümünün bilgi koruyucu olmasına izin verir.

0x7F'den ( NEL , LS ve PS ) büyük yeni satır kodlarını tanımak ve kullanmak genellikle yapılmaz. UTF-8'de birden çok bayttırlar ve NEL kodu Windows-1252'de üç nokta ( …) karakteri olarak kullanılmıştır . Örneğin:

• ECMAScript kabul LS ve PS hattı kırılmalarının olarak, ancak dikkate U +, 0085 ( NEL ) boşluk yerine satır kesintisi.
• Windows 10 , varsayılan metin düzenleyicisi Notepad'de NEL , LS veya PS öğelerinin hiçbirini satır sonları olarak değerlendirmez .
• gedit , varsayılan metin editörü ait GNOME masaüstü ortamının , ikramlar LS ve PS yenisatırlar olarak değil için yaptığı NEL .
• JSON , dizeler içinde LS ve PS karakterlerine izin verirken, ES2019'dan önceki ECMAScript bunları yeni satırlar ve dolayısıyla geçersiz sözdizimi olarak değerlendirdi.
• YAML , JSON ile uyumlu olmaları için artık bunları 1.2 sürümünden itibaren özel olarak tanımıyor .

Not Unicode özel karakterler de bu U +, 2424 ( bir sembol için NEWLINE , ␤), U +, 23CE ( GERİ SEMBOLÜ , ⏎), U +, 240D ( bir sembol için satır başı , ␍) ve U +, 240A ( sembol için BESLEME , ␊) olan kabartmalar amaçlanan belgenin okuyucusuna kullanıcı tarafından görülebilen bir karakter sunmak için kullanılır ve bu nedenle kendilerini yeni satır olarak tanımazlar.

Kaçış dizileri

Bir kaçış dizisi , hiçbir metni temsil etmeyen karakterlerin birleşimidir; (metin olarak) görüntülenmek yerine program tarafından durdurulması ve özel bir işlevin gerçekleştirilmesi gerekiyor. Kaçış dizileri ayrıca özel karakterleri işlemek (ayarlamak, aramak, değiştirmek, vb.) için de kullanılır.

programlama dillerinde

Taşınabilir programların oluşturulmasını kolaylaştırmak için programlama dilleri, farklı ortamlarda kullanılan farklı satırsonu dizileriyle başa çıkmak için bazı soyutlamalar sağlar.

C programlama dili içerir çıkış sırasını '\ n' (satır) ve '\ r' (satır başı). Ancak bunların ASCII LF ve CR kontrol karakterlerine eşdeğer olması gerekmez . C standardı yalnızca iki şeyi garanti eder:

1. Bu kaçış dizilerinin her biri, tek bir karakter değerinde saklanabilen, uygulama tanımlı benzersiz bir sayıya eşlenir .
2. Metin modunda bir dosyaya, aygıt düğümüne veya sokete/fifo'ya yazarken , '\n' şeffaf bir şekilde sistem tarafından kullanılan ve bir karakterden uzun olabilen yerel yeni satır dizisine çevrilir. Metin modunda okurken, yerel yeni satır dizisi '\n' biçimine geri çevrilir . Olarak ikili modda , bir çeviri gerçekleştirilir ve üretilen iç temsil '\ n' , doğrudan verilir.

C'nin kaynaklandığı Unix platformlarında, yerel yeni satır dizisi ASCII LF'dir ( 0x0A ), dolayısıyla '\n' basitçe bu değer olarak tanımlanmıştır. Dahili ve harici gösterim aynı olduğundan, metin modunda gerçekleştirilen çeviri işlemsizdir ve Unix'in metin modu veya ikili mod kavramı yoktur. Bu, yazılımlarını Unix sistemlerinde geliştiren birçok programcının bu ayrımı tamamen görmezden gelmesine neden oldu ve bu da kodun farklı platformlara taşınabilir olmamasına neden oldu.

Unix yeni satır kuralıyla yazılmayan herhangi bir dosya yanlış okunacağından, C kitaplığı işlevi fgets () ikili modda en iyi şekilde önlenir. Ayrıca, metin modunda, sistemin yerel satırsonu dizisiyle yazılmayan herhangi bir dosya (örneğin, bir Unix sisteminde oluşturulan ve ardından bir Windows sistemine kopyalanan bir dosya gibi) de yanlış okunacaktır.

Diğer bir yaygın sorun, bitiş hatları için ASCII CR + LF kullanımını zorunlu kılan bir İnternet protokolü kullanarak iletişim kurarken '\n' kullanılmasıdır . Bir metin modu akışına '\n' yazmak Windows sistemlerinde düzgün çalışır, ancak Unix'te yalnızca LF üretir ve daha egzotik sistemlerde tamamen farklı bir şey üretir . Kullanılması "\ r \ n" ikili modda biraz daha iyidir.

C++ , Perl ve Haskell gibi birçok dil, '\n'nin C ile aynı yorumunu sağlar . C++, std::endl manipülatörünün yeni bir satır çıkarmak (ve akışı boşaltmak) için kullanılabileceği alternatif bir G/Ç modeline sahiptir. tampon).

Java , PHP , ve Python sağlayan '\ r \ n' (ASCII için diziyi CR + LF ). C'nin aksine, bunların sırasıyla U+000D ve U+000A değerlerini temsil etmesi garanti edilir .

Java G/Ç kitaplıkları bunları şeffaf bir şekilde giriş veya çıkışta platforma bağlı satırsonu dizilerine çevirmez. Bunun yerine, yerel yeni satır dizisini otomatik olarak ekleyen tam bir satır yazmak için işlevler ve satır sonlandırıcı olarak CR , LF veya CR + LF'den herhangi birini kabul eden satırları okumak için işlevler sağlarlar (bkz. BufferedReader.readLine() ). System.lineSeparator () metodu, arka plandaki hat ayırıcı almak için kullanılabilir.

Örnek:

   String eol = System.lineSeparator();
   String lineColor = "Color: Red" + eol;

Python, bir dosyayı okumak için açarken, modülleri içe aktarırken ve bir dosyayı yürütürken "Evrensel Yeni Hat Desteğine" izin verir.

Bazı diller, programın yürütülmesi sırasında yeni satırları kolaylaştırmak için özel değişkenler , sabitler ve alt rutinler oluşturmuştur. Gibi bazı dillerde PHP ve Perl , çift tırnak dahil tüm kaçış dizileri için kaçış ikame gerçekleştirmek için gerekli olan '\ n' ve '\ r' . PHP'de taşınabilirlik sorunlarından kaçınmak için yeni satır dizileri PHP_EOL sabiti kullanılarak verilmelidir.

C#' daki örnek :

   string eol = Environment.NewLine;
   string lineColor = "Color: Red" + eol;
   
   string eol2 = "\n";
   string lineColor2 = "Color: Blue" + eol2;

Farklı yeni satır biçimleriyle ilgili sorunlar

Bir metin dosyası ile oluşturulan gedit ve izlenebilir hex editörü . Metin nesnelerinin yanı sıra, yalnızca onaltılık değeri 0A olan EOL işaretleri vardır .

Kontrol karakterleri, bir metin dosyası tarafından kullanılan ilgili karakter kodlama tablosunda açık bir şekilde tanımlanmış olsa da, yine de bir sorun vardır: Bir satır sonu ayarlamak ve görüntülemek için farklı kurallar vardır.

Tek satır sonunu belirtmek için Unix programları line feed, ASCII'deki onaltılık değeri olan 'yi kullanırken , MS-DOS ve Microsoft Windows'ta0a ortak olan çoğu program , ASCII'deki onaltılık değeri olan +' yı kullanır . ASCII'de satır başı ayrı bir kontrol karakteridir. carriage returnline feed0d 0a

Farklı yeni satır kuralları, farklı türdeki sistemler arasında aktarılan metin dosyalarının yanlış görüntülenmesine neden olur.

Unix benzeri veya klasik Mac OS'de yaygın olan programlarla oluşturulan dosyalardaki metinler , MS-DOS ve Microsoft Windows'ta ortak olan programların çoğunda tek bir uzun satır olarak görünür çünkü bunlar satır sonu olarak tek line feedveya tek bir görüntü göstermez carriage return.

Bunun tersine, Unix benzeri bir sistemdeki bir Windows bilgisayarından kaynaklanan bir dosyayı görüntülerken, fazladan CR , ikinci satır sonu olarak, ^M olarak veya her satırın sonunda <cr> olarak görüntülenebilir.

Ayrıca, metin düzenleyiciler dışındaki programlar, örneğin, yabancı yeni satır kuralı kullanılarak kodlanmış bazı yapılandırma dosyaları gibi bir dosyayı geçerli bir dosya olarak kabul etmeyebilir.

Sorunu tespit etmek zor olabilir, çünkü bazı programlar yabancı yeni satırları düzgün bir şekilde işlerken diğerleri işlemez. Örneğin, bir derleyici , konsolda veya bir düzenleyicide görüntülendiğinde kaynak dosya doğru görünse bile, belirsiz sözdizimi hatalarıyla başarısız olabilir . Unix benzeri bir sistemde, cat -v myfile.txt komutu dosyayı stdout'a (normalde terminal) gönderir ve hata ayıklama için yararlı olabilecek ^M'yi görünür kılar . Modern metin editörleri genellikle CR + LF yeni satırlarının tüm çeşitlerini tanır ve kullanıcıların farklı standartlar arasında dönüştürme yapmasına olanak tanır. Web tarayıcıları genellikle metin dosyalarını ve farklı yeni satır türlerini kullanan web sitelerini de görüntüleyebilir.

Bir program farklı satırsonu kurallarını desteklese bile, bu özellikler genellikle yeterince etiketlenmez, tanımlanmaz veya belgelenmez. Tipik olarak, farklı satırsonu kurallarını sıralayan bir menü veya birleşik giriş kutusu, seçimin yeni satırları yeniden yorumlayıp yorumlamayacağını, geçici olarak dönüştüreceğini veya kalıcı olarak dönüştüreceğini belirtmeden kullanıcılara gösterilecektir. Bazı programlar, açma, kopyalama, yapıştırma veya kaydetme sırasında, genellikle tutarsız bir şekilde örtük olarak dönüştürülür.

Çoğu metinsel İnternet protokolü ( HTTP , SMTP , FTP , IRC ve diğerleri dahil) , protokol düzeyinde ASCII CR + LF ( '\r\n' , 0x0D 0x0A ) kullanımını zorunlu kılar , ancak toleranslı uygulamaların yalnız LF'yi tanımasını önerir. ( '\n' , 0x0A ) de. Dikte edilen standarda rağmen, birçok uygulama, satır başı kaçış ve yeni satır kaçış dizilerinin '\r\n' ( CR + LF ) doğru kombinasyonu yerine hatalı olarak C yeni satır kaçış dizisini '\n' ( LF ) kullanır (bkz . Yukarıdaki programlama dilleri ). Yanlış kaçış dizilerinin bu kazara kullanımı, önerilen toleranslı yorum yerine standartların daha katı yorumuna bağlı kalan sistemlerle iletişim kurmaya çalışırken sorunlara yol açar. Böyle bir hoşgörüsüz sistem, gerekli CR + LF yerine çıplak LF gönderen sistemlerden gelen mesajları kabul etmeyi aktif olarak reddeden qmail posta aktarım aracısıdır .

E-posta için standart İnternet Mesaj Formatı şu şekildedir: "CR ve LF, yalnızca CRLF olarak birlikte OLMALIDIR; gövdede bağımsız olarak GÖRÜNMEMEKTEDİR".

Protokol Dosya Transferi dosyalarında otomatik yeni satır dönüştürebilirsiniz arasında aktarılmakta olan sistemlerde transferi "ASCII modunda" yapıldığında farklı satır temsilleri ile. Bununla birlikte, ikili dosyaları bu modda aktarmak genellikle feci sonuçlara yol açar: yeni satır bayt dizisinin herhangi bir oluşumu - bu bağlamda satır sonlandırıcı semantiğine sahip değildir, ancak normal bir bayt dizisinin yalnızca bir parçasıdır - yeni satır temsili ne olursa olsun çevrilecektir. diğer sistem kullanır, dosyayı etkili bir şekilde bozar . FTP istemcileri , ikili veya ASCII modunu otomatik olarak seçmek için genellikle bazı buluşsal yöntemler kullanır (örneğin, dosya adı uzantılarının incelenmesi ), ancak sonunda, dosyalarının doğru modda aktarıldığından emin olmak kullanıcılara kalmıştır. Doğru modla ilgili herhangi bir şüphe varsa, ikili mod kullanılmalıdır, çünkü o zaman FTP tarafından hiçbir dosya değiştirilmez, ancak yanlış görüntülenebilirler.

Yeni satır biçimleri arasında dönüştürme

Metin düzenleyiciler genellikle bir metin dosyasını farklı yeni satır biçimleri arasında dönüştürmek için kullanılır; çoğu modern editör, en azından farklı ASCII CR / LF kurallarını kullanarak dosyaları okuyabilir ve yazabilir .

Örneğin, Vim düzenleyicisi , bir dosyayı Windows Not Defteri metin düzenleyicisiyle uyumlu hale getirebilir. vim içinde

 :set fileformat=dos
 :wq

Düzenleyiciler, daha büyük dosyaları dönüştürmek veya birçok dosyanın toplu olarak dönüştürülmesi için uygun olmayabilir. Daha büyük dosyalar için (Windows NT/2000/XP'de) genellikle aşağıdaki komut kullanılır:

D:\>TYPE unix_file | FIND /V "" > dos_file

Dosyaları farklı satırsonu kuralları arasında dönüştürmek için özel amaçlı programlar arasında unix2dos ve dos2unix , mac2unix ve unix2mac , mac2dos ve dos2mac ve flip bulunur . Tr komutu hemen hemen her geçerli Unix benzeri sistem ve tek karakterler keyfi yedek işlemleri gerçekleştirmek için de kullanılabilir. Bir DOS/Windows metin dosyası, tüm ASCII CR karakterlerini aşağıdaki komutlarla kaldırarak Unix biçimine dönüştürülebilir:

$ tr -d '\r' < inputfile > outputfile

ya da, sadece metin varsa CR tüm dönüştürerek yeni satır, CR için yeni satır LF ile

$ tr '\r' '\n' < inputfile > outputfile

Aynı görevler bazen ile gerçekleştirilmektedir awk , sed , ya da Perl platformu, bir Perl yorumlayıcısı varsa:

$ awk '{sub("$","\r\n"); printf("%s",$0);}' inputfile > outputfile  # UNIX to DOS  (adding CRs on Linux and BSD based OS that haven't GNU extensions)
$ awk '{gsub("\r",""); print;}' inputfile > outputfile              # DOS to UNIX  (removing CRs on Linux and BSD based OS that haven't GNU extensions)
$ sed -e 's/$/\r/' inputfile > outputfile              # UNIX to DOS  (adding CRs on Linux based OS that use GNU extensions)
$ sed -e 's/\r$//' inputfile > outputfile              # DOS  to UNIX (removing CRs on Linux based OS that use GNU extensions)
$ perl -pe 's/\r?\n|\r/\r\n/g' inputfile > outputfile  # Convert to DOS
$ perl -pe 's/\r?\n|\r/\n/g'   inputfile > outputfile  # Convert to UNIX
$ perl -pe 's/\r?\n|\r/\r/g'   inputfile > outputfile  # Convert to old Mac

Dosya komut satırı sonları türünü belirleyebilir:

 $ file myfile.txt
 myfile.txt: ASCII English text, with CRLF line terminators

Unix egrep (genişletilmiş grep) komutu, Unix veya DOS dosyalarının dosya adlarını yazdırmak için kullanılabilir (yalnızca Unix ve DOS tarzı dosyaların Mac OS olmadığı varsayılarak):

$ egrep -L '\r\n' myfile.txt # show UNIX style file (LF terminated)
$ egrep -l '\r\n' myfile.txt # show DOS style file (CRLF terminated)

Diğer araçlar, kullanıcının EOL karakterlerini görselleştirmesine izin verir:

$ od -a myfile.txt
$ cat -e myfile.txt
$ hexdump -c myfile.txt

Tercüme

Her ikisi de kendi içinde tutarlı olan yeni satırları görüntülemenin iki yolu , yeni satırların satırları ayırması veya satırları sonlandırmasıdır . Yeni satır ayırıcı olarak kabul edilirse, dosyanın son satırından sonra yeni satır olmaz. Bazı programlar, dosya yeni bir satırla sonlandırılmamışsa, dosyanın son satırını işlemede sorun yaşar. Öte yandan, yeni satırın ayırıcı olarak kullanılmasını bekleyen programlar, son satırı yeni (boş) bir satıra başlamak olarak yorumlayacaktır. Tersine, bir satırsonu sonlandırıcı olarak kabul edilirse, son satır dahil tüm metin satırlarının yeni satırla sonlandırılması beklenir. Bir metin dosyasındaki son karakter dizisi yeni bir satır değilse, dosyanın son satırı uygunsuz veya eksik bir metin satırı olarak kabul edilebilir veya dosyanın hatalı bir şekilde kesildiği kabul edilebilir.

Sözcük kaydırma özelliğini uygulayan yazılımı kullanan insanlar tarafından öncelikli olarak okunması amaçlanan metinde , bir satırsonu karakterinin tipik olarak, paragraflar arasında olduğu gibi, sonraki sözcüğün aynı satıra sığıp sığmayacağından bağımsız olarak bir satır sonu gerekliyse saklanması gerekir. ve dikey listelerde. Bu nedenle, sözcük işleme mantığında ve çoğu metin düzenleyicide yeni satır, bir paragraf sonu olarak kullanılır ve sözcük kaydırmayı uygulamak için dinamik olarak oluşturulan ve her biri ile değiştirilebilir olan "yumuşak dönüşler"in aksine, "kesin dönüş" olarak bilinir. örneğini göster. Birçok uygulamada , tek bir paragraf içinde satır sonlarını zorlamak için "el ile satır sonu" adı verilen ayrı bir kontrol karakteri mevcuttur. Glif sabit bir dönüş için kontrol karakteri için genellikle bir olan Pilcrow (¶) ve el ile satır arası bir satır başı ok (↵) genellikle.

Ters ve kısmi satır beslemeleri

RI , ( U +008D TERS HAT BESLEME, ISO/IEC 6429 8D, ondalık 141) yazdırma konumunu bir satır geriye taşımak için kullanılır (kağıdı ters besleyerek veya bir ekran imlecini bir satır yukarı hareket ettirerek) böylece diğer karakterler mevcut metin üzerine yazdırılabilir. Bu, onları daha kalın yapmak veya alt çizgiler, üstü çizili karakterler veya aksan işaretleri gibi başka karakterler eklemek için yapılabilir .

Benzer şekilde, PLD ( U +008B KISMİ SATIR İLERİ, ondalık 139) ve PLU ( U +008C KISMİ SATIR GERİ, ondalık 140), metin yazdırma konumunu dikey satır aralığının bir kısmı kadar (tipik olarak yarım satır) ilerletmek veya tersine çevirmek için kullanılabilir. ). Bunlar, alt simgeler (ilerleyip sonra tersine çevirerek) ve üst simgeler (ters çevirerek ve sonra ilerleterek) için kombinasyon halinde kullanılabilir ve ayrıca aksanları yazdırmak için de yararlı olabilir.

Ayrıca bakınız

• ASA taşıma kontrol karakterleri
• C0 ve C1 kontrol kodları
• Dosyanın sonu
• çizgi açlıktan
• Sayfa sonu
• Satırbaşı
• Giriş anahtarı

Referanslar

Dış bağlantılar

• Unicode referansı, Unicode 4.0 standardının 5. Bölümündeki 5.8 paragrafına bakın (PDF)
• [NEL] Yeni Satır Karakteri
• Çizginin Sonu Bulmacası
• Newlines at the Wayback Machine'i Anlamak (20 Ağustos 2006'da arşivlendi)
• "Hat Sonu Hikayesi"