A kocsi visszaadása (CR) és a sor előtolás (LF) fogalma szorosan összefügg, és külön-külön vagy együttesen is figyelembe vehető. Az írógépek és nyomtatók fizikai adathordozóiban két mozgástengelyre van szükség, “lefelé” és “keresztbe”, egy új vonal létrehozásához az oldalon. Bár egy gép (írógép vagy nyomtató) tervezésénél külön-külön kell figyelembe venni őket, a szoftver elvont logikája ezeket egyetlen eseményként egyesítheti. Ezért definiálható egy új sor a karakterkódolásban: CR és LF egyesítve (általában CR + LF vagy CRLF ).

Néhány a karakterkészletek külön új vonalas karakterkódot adnak meg. Az EBCDIC például NL karakterkódot biztosít a CR és LF kódok mellett. Az Unicode az ASCII CR és LF vezérlőkódok megadásán kívül egy “következő sor” (NEL) vezérlőkódot, valamint a “sorelválasztó” és “bekezdéselválasztó” jelölők vezérlőkódjait is biztosítja.

• EBCDIC rendszerek – főleg az IBM nagyszámítógépes rendszerei, beleértve a z / OS (OS / 390) és az i5 / OS (OS / 400) – az NL (New Line, 0x15) karaktert használják, amely kombinálja a sor előtolás és a szállítás funkcióit Visszatérés. Az egyenértékű Unicode karaktert ( 0x85 ) NEL-nek (Következő sor) hívják. Az EBCDIC rendelkezik CR és LF nevű vezérlő karakterekkel is, de az LF (0x25) számértéke eltér az ASCII által használt értéktől (0x0A). Ezenkívül egyes EBCDIC változatok NL-t is használnak, de más numerikus kódot rendelnek a karakterhez. Ezek az operációs rendszerek azonban rekordalapú fájlrendszert használnak, amely a szöveges fájlokat soronként egy rekordként tárolja. A legtöbb fájlformátumban nincsenek sorvégződések tárolva.
• A CDC 6000 sorozat operációs rendszerei egy új sort két vagy több nulla értékű hat bites karakterként határoztak meg egy 60 bites szó végén. Néhány konfiguráció egy nulla értékű karaktert is kettőspont karakterként definiált, aminek eredményeként több kettőspont új pozícióként értelmezhető a pozíciótól függően.
• Az RSX-11 és az OpenVMS rekordalapú fájlrendszert is használ , amely a szöveges fájlokat soronként egy rekordként tárolja. A legtöbb fájlformátumban nincsenek sorvégződések tárolva, de a Rekordkezelő szolgáltatások lehetősége átláthatóan hozzáad egy terminátort minden sorhoz, amikor egy alkalmazás lekéri. Maguk a rekordok ugyanazokat a sorvégző karaktereket tartalmazhatják, amelyek az alkalmazástól függően vagy jellemzőnek, vagy kellemetlenségnek tekinthetők. Az RMS nemcsak rekordokat tárolt, hanem metaadatokat is tárolt a rekordelválasztókról különböző bitekben, hogy a fájl még bonyolultabb legyen (mivel a fájlok rögzített hosszúságú rekordokkal rendelkezhetnek, a számlálással előtagokkal ellátott rekordok vagy egy adott karakter által lezárt rekordok ). A bitek nem voltak általánosak, így bár meg tudták határozni, hogy a CRLF vagy az LF, vagy akár a CR a vonalterminátor, ez nem helyettesíthet más kódokat.
• A rögzített vonalhosszat néhány korai nagygép használta. rendszerek. Egy ilyen rendszerben implicit sorvéget feltételeztek például 72 vagy 80 karakterenként. Nem tárolt újsoros karaktert. Ha egy fájlt a külvilágból importáltak, akkor a vonalhossznál rövidebb sorokat szóközökkel kellett kitölteni, míg a vonalhossznál hosszabbakat csonkolni kellett. Ez lyukasztott kártyák használatát utánozta, amelyeken az egyes sorokat külön kártyán tárolták, általában 80 oszloppal minden kártyán, gyakran a sorszámokkal a 73–80. Ezen rendszerek közül sokan kocsivezérlő karaktert adtak a következő rekord elejéhez; ez azt jelezheti, hogy a következő rekord az előző rekord által kezdett sor folytatása volt-e, vagy egy új sor, vagy felül kell-e nyomtatnia az előző sort (hasonlóan a CR-hez). Gyakran ez egy normál nyomtatási karakter volt, például # , amely így nem használható a sor első karaktereként. Néhány korai sornyomtató ezeket a karaktereket közvetlenül a nekik küldött rekordokban értelmezte.

UnicodeEdit

Az Unicode szabvány számos olyan karaktert definiál, amelyet a megfelelő alkalmazásoknak vonalvégzőként kell felismerniük:

LF: Line Feed, U + 000A VT: Függőleges fül, U + 000B FF: Űrlapbetöltés, U + 000C CR: Szállítás vissza, U + 000D CR + LF: CR (U + 000D), majd LF (U + 000A) NEL: Következő sor, U + 0085 LS: Vonalelválasztó, U + 2028 PS: Bekezdéselválasztó, U + 2029

Ez túlságosan bonyolultnak tűnhet egy olyan megközelítéshez képest, mint például az összes sorterminátor egyetlen karakterré alakítása, például LF. Az Unicode-ot azonban úgy tervezték, hogy minden információt megőrizzen, amikor egy szövegfájlt bármilyen létező kódolásból Unicode-ba és vissza konvertál. Ezért az Unicode-nak tartalmaznia kell a meglévő kódolásokban szereplő karaktereket.Az NL szerepel az EBCDIC-ben 0x15 kóddal, és gyakran hozzárendelve az NEL-hez, amely a C1 vezérlő készlet vezérlő karaktere. Mint ilyen, ezt az ECMA 48 határozza meg, és az ISO / IEC 2022 szabványnak megfelelő kódolással ismeri el (ami egyenértékű az ECMA 35-tel). A C1 vezérlőkészlet kompatibilis az ISO-8859-1 szabvánnyal is. Az Unicode szabványban alkalmazott megközelítés lehetővé teszi az oda-vissza transzformáció információmegőrzését, ugyanakkor lehetővé teszi az alkalmazások számára az összes lehetséges típusú vonalterminátorok felismerését.

A 0x7F-nél nagyobb új vonalkódok felismerése és használata (NEL, LS és PS) nem gyakran történik. Több bájt az UTF-8-ban, és a NEL kódját használták ellipszis (… ) karakterként a Windows-1252-ben. Például:

• Az ECMAScript az LS-t és a PS-t sortörésként fogadja el, az U + 0085 (NEL) szóközt azonban a sortörés helyett tekinti.
• A Windows 10 az NEL, LS vagy PS egyikét sem tekinti sortörésnek az alapértelmezett szövegszerkesztőjében, a Jegyzettömbben.
• gedit, a GNOME asztali környezet alapértelmezett szövegszerkesztője , az LS-t és a PS-t új vonalakként kezeli, de a NEL esetében nem.
• A JSON az LS és a PS karaktereket megengedi a karakterláncokon belül, míg az ES2019 előtti ECMAScript új vonalakként kezelte őket, és ezért illegális szintaxist.
• A YAML már nem ismeri el őket különlegesnek az 1.2-es verziótól kezdve annak érdekében, hogy kompatibilisek legyenek a JSON-nal.

Az Unicode karakterek U + 2424 (SYMBOL FOR NEWLINE, ␤ ), U + 23CE (VISSZATÉRÉSI JEL, ⏎ ), U + 240D (SZIMBÓLUM FOR SZÁLLÍTÁSI VISSZATÉRÉS, ␍ ) és U + 240A (VONALTÁPOLÁS JELE, ␊ ) a felhasználó számára látható karakter bemutatására szolgál a dokumentum olvasója számára, ezért nem ismerik fel őket új vonallal.

Escape sequencesEdit

A menekülési szekvencia olyan karakterek kombinációja, amelyek nem képvisel szöveget; ahelyett, hogy megjelenítenék (szövegként), azt feltételezhetően a program elfogja, és egy speciális funkciót kell végrehajtani. A menekülési szekvenciákat speciális karakterek kezelésére (beállítás, keresés, csere stb.) Is használják.

A programozási nyelvekbenEdit

A hordozható programok létrehozásának megkönnyítése érdekében a programozási nyelvek tartalmaznak néhány absztrakciót a különböző környezetekben használt különféle újsoros szekvenciák kezelésére.

A C programozási nyelv biztosítja a “\ n” (új sor) és a “\ r” (kocsi vissza) menekülési szekvenciákat. Ezeknek azonban nem kell egyenértékűnek lenniük az ASCII LF és CR vezérlő karakterekkel. A C szabvány csak két dolgot garantál:

1. Ezek a menekülési szekvenciák mindegyike egyedi megvalósítás által definiált számhoz kapcsolódik, amely egyetlen char értékben tárolható.
2. Íráskor fájlba, eszközcsomópontba vagy socket / fifo-ba szöveges módban, a “\ n” szót átlátszóan lefordítják a rendszer által használt natív újsor-szekvenciára, amely hosszabb lehet, mint egy karakter. Szöveges módban történő olvasáskor a natív újsoros szekvenciát visszafordítják “\ n” -re. Bináris módban nem hajtanak végre fordítást, és a “\ n” által létrehozott belső reprezentáció közvetlenül kimenetre kerül.

Unix platformokon, ahol C keletkezett, a natív újsoros szekvencia ASCII LF ( 0x0A), ezért a “\ n” értéket egyszerűen definiálták. Mivel a belső és külső ábrázolás megegyezik, a szöveges módban végrehajtott fordítás nem engedélyezett, és a Unix nem rendelkezik szöveges vagy bináris mód fogalmával. Ez sok programozót, aki szoftverét Unix rendszereken fejlesztette ki, egyszerűen figyelmen kívül hagyta a megkülönböztetést, ami olyan kódot eredményezett, amely nem hordozható különböző platformokon.

A C könyvtár funkció futtatóit () bináris módban a legjobb elkerülni. mert minden olyan fájl, amelyet nem a Unix newline konvencióval írtak, rosszul lesz olvasva. Szintén szöveges módban minden olyan fájl, amelyet nem a rendszer natív újsoros sorrendjével írtak (például egy Unix rendszeren létrehozott, majd Windows rendszerre másolt fájl), szintén rosszul lesz olvasva.

Egy másik Gyakori probléma a “\ n” használata az Internet protokoll használatával folytatott kommunikáció során, amely az ASCII CR + LF használatát írja elő a sorok befejezésére. A “\ n” szöveges üzemmódba történő írása helyesen működik Windows rendszereken, de csak LF Unix, és valami egészen más egzotikusabb rendszereken. A “\ r \ n” használata bináris módban valamivel jobb.

A Java I / O könyvtárak ezeket nem transzparensen fordítják platformfüggő újsoros szekvenciákra a bemenet vagy kimenet. Ehelyett egy teljes sor írására szolgálnak funkciók, amelyek automatikusan hozzáadják a natív új sor szekvenciát, valamint olyan sorok olvasásához, amelyek elfogadják a CR, LF vagy CR + LF bármelyikét vonalvezetõként (lásd: BufferedReader.readLine ( A System.lineSeparator () metódus használható az alatta levő vonalválasztó lekérésére.

Példa:

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

A Python engedélyezi az „Universal Newline Support” funkciót, amikor megnyit egy fájlt olvasásra, amikor modulok importálásakor és egy fájl futtatásakor.

Egyes nyelvek speciális változókat, konstansokat és alprogramokat hoztak létre, hogy megkönnyítsék az új sorokat a program futtatása során. Egyes nyelvekben, például a PHP-ben és a Perl-ben dupla idézőjelek szükségesek az összes menekülési szekvencia menekülési helyettesítéséhez, beleértve a “\ n” és “\ r” szót is. A PHP-ben a hordozhatósági problémák elkerülése érdekében új soros szekvenciákat kell kiadni a PHP_EOL konstans használatával.

Példa a C # -ba:

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

Különböző újsoros formátumokkal kapcsolatos problémákSzerkesztés

Annak ellenére, hogy a vezérlő karaktereket egyértelműen definiálják a szövegfájl által használt megfelelő karakterkódolási táblázatban , még mindig van egy probléma: különböző konvenciók vannak a sortörés beállítására és megjelenítésére.

Egyetlen sortörés jelölésére a Unix programok a sortáblát használják , amelynek hexadecimális értéke az ASCII-ben 0a , míg az MS-DOS és a Microsoft Windows számára közös programok többsége carriage return + sor feed , amelynek hexadecimális értéke az ASCII-ben 0d 0a kód>. Az ASCII-ben a kocsivissza egy különálló vezérlő karakter.

A különböző újsoros konvenciók miatt a különböző típusú rendszerek között átvitt szövegfájlok helytelenül jelennek meg.

A létrehozott fájlok szövege a Unix-szerű vagy a klasszikus Mac OS rendszeren elterjedt programokkal egyetlen hosszú sorként jelennek meg az MS-DOS és a Microsoft Windows közös programjain, mivel ezek nem mutatnak egyetlen sorcsatorna vagy egyetlen sor visszatérése mint sortörés.

Ezzel szemben, ha egy Windows számítógépről származó fájlt néz meg Unix-szerű rendszeren az extra CR megjelenhet második sortörésként, ^ M vagy < cr > minden sor végén.

Továbbá előfordulhat, hogy a szövegszerkesztőkön kívüli programok nem fogadnak el fájlt, pl néhány konfigurációs fájl, amelyet a külföldi újsor konvencióval kódoltak, érvényes fájlként.

A problémát nehéz felismerni, mert egyes programok megfelelően kezelik a külföldi új vonalakat, míg mások nem. Például egy fordító elbukhat homályos szintaktikai hibákkal, annak ellenére, hogy a forrásfájl megfelelőnek tűnik, amikor megjelenik a konzolon vagy egy szerkesztőben. Unix-szerű rendszeren a cat -v myfile.txt parancs elküldi a fájlt az stdout-nak (általában a terminálnak), és láthatóvá teszi a ^ M-et, ami hasznos lehet a hibakereséshez. A modern szövegszerkesztők általában felismerik a CR + LF újsorok minden ízét, és lehetővé teszik a felhasználók számára, hogy a különböző szabványok között váltsanak. A webböngészők általában képesek olyan szöveges fájlok és webhelyek megjelenítésére is, amelyek különböző típusú újsorokat használnak.

Még akkor is, ha egy program különböző újsoros konvenciókat támogat, ezek a szolgáltatások gyakran nincsenek megfelelően címkézve, leírva vagy dokumentálva. Jellemzően egy menü vagy egy kombinációs mező, amely felsorolja a különböző újsor-konvenciókat, megjelennek a felhasználók számára, anélkül, hogy jeleznék, ha a kijelölés újraértelmezi, ideiglenesen vagy véglegesen átalakítja az új sorokat. Egyes programok implicit módon konvertálnak megnyitásra, másolásra, beillesztésre vagy mentésre – gyakran következetlenül.

A legtöbb szöveges internetes protokoll (beleértve a HTTP-t, az SMTP-t, az FTP-t, az IRC-t és még sokan mások) előírják az ASCII CR + használatát. LF (“\ r \ n”, 0x0D 0x0A) protokoll szinten, de javasoljuk, hogy a toleráns alkalmazások ismerjék el a magányos LF-t (“\ n”, 0x0A) is. A diktált szabvány ellenére sok alkalmazás hibásan használja a “C” új sor menekülési szekvenciáját “\ n” (LF) a kocsi visszatérési menekülési és az új vonali menekülési szekvenciák helyes kombinációja helyett “\ r \ n” (CR + LF) (lásd: Új sor programozási nyelvek). A helytelen menekülési szekvenciák véletlenszerű használata problémákat okoz, amikor megpróbál kommunikálni olyan rendszerekkel, amelyek a javasolt toleráns értelmezés helyett a szabványok szigorúbb értelmezéséhez tartják magukat. Az egyik ilyen intoleráns rendszer a qmail levélátviteli ügynök, amely aktívan nem hajlandó fogadni olyan rendszerek üzeneteit, amelyek csupasz LF-t küldenek a szükséges CR + LF helyett.

Az e-mail szabványos internetes üzenetformátuma: CR és LF KELL csak együtt fordulnak elő CRLF-ként; NEM szabad önállóan megjelenniük a törzsben.

A File Transfer Protocol automatikusan átalakíthatja az új sorokat a fájlok között, amelyeket különböző újsor-reprezentációval rendelkező rendszerek között továbbítanak, amikor az átvitel “ASCII módban” történik.A bináris fájlok átvitele ebben a módban azonban általában katasztrofális eredménnyel jár: az újsoros bájtsorozat bármilyen előfordulása – amely ebben a kontextusban nem rendelkezik vonalvégződő szemantikával, de csak egy normál bájtsorozat része – minden újsoros reprezentációra lefordul. a másik rendszer használja, hatékonyan megrongálva a fájlt. Az FTP kliensek gyakran alkalmaznak bizonyos heurisztikákat (például a fájlnévkiterjesztések ellenőrzése), hogy automatikusan választják a bináris vagy az ASCII módot, de végül a felhasználók feladata, hogy megbizonyosodjanak arról, hogy fájljaikat a megfelelő módban továbbítják-e. Ha kétség merül fel a helyes móddal kapcsolatban, akkor bináris módot kell használni, mivel akkor az FTP nem módosít egyetlen fájlt sem, bár előfordulhat, hogy helytelenül jelenítenek meg.

Konvertálás újsoros formátumok közöttEdit

A szövegszerkesztőket gyakran használják szöveges fájlok konvertálására különböző újsoros formátumok között; a legmodernebb szerkesztők legalább a különböző ASCII CR / LF konvenciók használatával tudnak fájlokat olvasni és írni. Például a Vim szerkesztő kompatibilisvé teheti a Windows Jegyzettömb szövegszerkesztőjét. A vim-en belül

 :set fileformat=dos :wq

A szerkesztők alkalmatlanok nagyobb fájlok konvertálására vagy sok fájl tömeges átalakítására. Nagyobb fájlok (Windows NT / 2000 / XP esetén) gyakran a következő parancsot használják:

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

Konvertálandó speciális programok A különféle újsoros konvenciók közötti fájlok közé tartozik az unix2dos és dos2unix, mac2unix és unix2mac, mac2dos és dos2mac és a flip. A tr parancs gyakorlatilag minden Unix-szerű rendszeren elérhető, és tetszőleges csereműveletek végrehajtására használható egyetlen karakteren. A DOS / Windows szövegfájl konvertálható Unix formátumba azáltal, hogy egyszerűen eltávolítja az összes ASCII CR karaktert

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

, vagy ha a szöveg csak CR új sorokkal rendelkezik, az összes CR új vonal konvertálása LF-be

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

Ugyanazokat a feladatokat néha az awk, sed vagy a Perl programban hajtják végre, ha a platformon van Perl tolmács:

A fájl parancs azonosíthatja a sorvégződések típusát:

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

A Unix egrep (kibővített grep) parancs használható Unix vagy DOS fájlok fájlneveinek kinyomtatására (csak Unix és DOS stílusú fájlokat feltételezve, Mac OS nélkül):

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

Más eszközök lehetővé teszik a felhasználó számára az EOL-karakterek megjelenítését:

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