Conceptele de retur de transport (CR) și avans de linie (LF) sunt strâns asociate și pot fi considerate fie separat, fie împreună. În mediul fizic al mașinilor de scris și al imprimantelor, sunt necesare două axe de mișcare, „jos” și „transversal”, pentru a crea o nouă linie pe pagină. Deși proiectarea unei mașini (mașină de scris sau imprimantă) trebuie să le ia în considerare separat, logica abstractă a software-ului le poate combina împreună ca un singur eveniment. Acesta este motivul pentru care o linie nouă în codificarea caracterelor poate fi definită ca CR și LF combinate într-o singură (denumit în mod obișnuit CR + LF sau CRLF ).

Unele seturile de caractere oferă un cod de caractere newline separat. EBCDIC, de exemplu, oferă un cod de caractere NL în plus față de codurile CR și LF. Unicode, pe lângă furnizarea codurilor de control ASCII CR și LF, oferă și un cod de control „următoarea linie” (NEL), precum și coduri de control pentru markerii „separator de linie” și „separator de paragrafe”.

• Sistemele EBCDIC – în principal sistemele mainframe IBM, inclusiv z / OS (OS / 390) și i5 / OS (OS / 400) – folosesc NL (New Line, 0x15) ca caracter care combină funcțiile de alimentare de linie și transport întoarcere. Caracterul Unicode echivalent ( 0x85 ) se numește NEL (Linia următoare). EBCDIC are și caractere de control numite CR și LF, dar valoarea numerică a LF (0x25) diferă de cea utilizată de ASCII (0x0A). În plus, unele variante EBCDIC folosesc și NL, dar atribuie un cod numeric diferit caracterului. Cu toate acestea, aceste sisteme de operare utilizează un sistem de fișiere bazat pe înregistrări, care stochează fișierele text ca o înregistrare pe linie. În majoritatea formatelor de fișiere, niciun terminator de linie nu este stocat.
• Sistemele de operare pentru seria CDC 6000 au definit o linie nouă ca două sau mai multe caractere de șase biți cu valoare zero la sfârșitul unui cuvânt de 60 de biți. Unele configurații au definit, de asemenea, un caracter cu valoare zero ca un caracter de colon, cu rezultatul că mai multe puncte pot fi interpretate ca o linie nouă în funcție de poziție.
• RSX-11 și OpenVMS folosesc, de asemenea, un sistem de fișiere bazat pe înregistrări. , care stochează fișierele text ca o înregistrare pe linie. În majoritatea formatelor de fișiere, niciun terminator de linie nu este de fapt stocat, dar funcția de servicii de gestionare a înregistrărilor poate adăuga în mod transparent un terminator la fiecare linie atunci când este recuperat de o aplicație. Înregistrările în sine ar putea conține aceleași caractere terminator de linie, care ar putea fi considerate fie o caracteristică, fie o deranj în funcție de aplicație. RMS nu numai înregistrările stocate, ci și metadatele stocate despre separatorii de înregistrări în biți diferiți pentru ca fișierul să complice lucrurile și mai mult (deoarece fișierele ar putea avea înregistrări de lungime fixă, înregistrări care erau prefixate cu un număr sau înregistrări care au fost terminate de un anumit caracter ). Biții nu erau generici, așa că, deși puteau specifica că CRLF sau LF sau chiar CR era terminatorul de linie, acesta nu putea înlocui alt cod.
• Lungimea liniei fixe a fost utilizată de unii mainframe timpurii sisteme. Într-un astfel de sistem, un sfârșit de linie implicit a fost presupus la fiecare 72 sau 80 de caractere, de exemplu. Nu a fost stocat niciun caracter de linie nouă. Dacă un fișier a fost importat din lumea exterioară, liniile mai scurte decât lungimea liniei trebuiau umplute cu spații, în timp ce liniile mai lungi decât lungimea liniei trebuiau tăiate. Aceasta imita utilizarea cărților perforate, pe care fiecare linie era stocată pe o carte separată, de obicei cu 80 de coloane pe fiecare carte, adesea cu numere de ordine în coloanele 73-80. Multe dintre aceste sisteme au adăugat un caracter de control al căruciorului la începutul următoarei înregistrări; acest lucru ar putea indica dacă următoarea înregistrare a fost o continuare a liniei începute de înregistrarea anterioară sau o nouă linie sau dacă ar trebui să supraimprimeze linia anterioară (similar cu un CR). Adesea acesta era un caracter normal de tipărire, cum ar fi # , care astfel nu putea fi folosit ca primul caracter dintr-o linie. Unele imprimante de primă linie au interpretat aceste caractere direct în înregistrările trimise către acestea.

UnicodeEdit

Standardul Unicode definește un număr de caractere pe care aplicațiile conforme ar trebui să le recunoască ca terminatori de linie:

LF: Line Feed, U + 000A VT: filă verticală, U + 000B FF: alimentare formular, U + 000C CR: retur de transport, U + 000D CR + LF: CR (U + 000D) urmat de LF (U + 000A) NEL: Linia următoare, U + 0085 LS: Separator de linie, U + 2028 PS: Separator de paragraf, U + 2029

Acest lucru poate părea prea complicat în comparație cu o abordare precum convertirea tuturor terminatorilor de linie într-un singur caracter, de exemplu LF. Totuși, Unicode a fost conceput pentru a păstra toate informațiile la convertirea unui fișier text din orice codificare existentă în Unicode și înapoi. Prin urmare, Unicode ar trebui să conțină caractere incluse în codificările existente.NL este inclus în EBCDIC cu codul 0x15 și adesea mapat la NEL, care este un caracter de control în setul de control C1. Ca atare, este definit de ECMA 48 și recunoscut de codificări conforme ISO / IEC 2022 (care este echivalent cu ECMA 35). Setul de control C1 este, de asemenea, compatibil cu ISO-8859-1. Abordarea adoptată în standardul Unicode permite transformarea dus-întors să păstreze informațiile, permițând totuși aplicațiilor să recunoască toate tipurile posibile de terminatori de linie.

Recunoașterea și utilizarea codurilor de linie nouă mai mari de 0x7F (NEL, LS și PS) nu se face adesea. Acestea sunt mai mulți octeți în UTF-8, iar codul pentru NEL a fost folosit ca elipsă ( ... ) caracter în Windows-1252. De exemplu:

• ECMAScript acceptă LS și PS ca pauze de linie, dar consideră spațiul alb U + 0085 (NEL) în loc de o pauză de linie.
• Windows 10 nu tratează niciunul dintre NEL, LS sau PS ca pauze de linie în editorul de text implicit, Notepad.
• gedit, editorul de text implicit al mediului desktop GNOME , tratează LS și PS ca linii noi, dar nu pentru NEL.
• JSON permite caracterele LS și PS în șiruri, în timp ce ECMAScript anterior ES2019 le-a tratat ca linii noi și, prin urmare, sintaxa ilegală.
• YAML nu le mai recunoaște la fel de speciale ca versiunea 1.2, pentru a fi compatibil cu JSON.

Caracterele Unicode U + 2424 (SIMBOL PENTRU NEWLINE, ␤ ), U + 23CE (RETURN SIMBOL, ⏎ ), U + 240D (SIMBOL PENTRU Întoarcerea transportului, ␍ ) și U + 240A (SIMBOL PENTRU ALIMENTARE LINIE, ␊ ) destinate prezentării unui caracter vizibil utilizatorului către cititorul documentului și, prin urmare, nu sunt recunoscute ca o linie nouă.

Secvențe de evacuareEdit

O secvență de evadare este o combinație de caractere care nu reprezintă text; în loc să fie afișat (sub formă de text), se presupune că este interceptat de program și se presupune că trebuie îndeplinită o funcție specială. Secvențele de evacuare sunt, de asemenea, utilizate pentru a gestiona (seta, căuta, înlocui, etc.) caractere speciale.

În limbaje de programareEdit

Pentru a facilita crearea de programe portabile, limbajele de programare oferă unele abstractizări pentru a face față diferitelor tipuri de secvențe newline utilizate în diferite medii.

Limbajul de programare C oferă secvențele de evacuare „\ n” (linie nouă) și „\ r” (retur de transport). Cu toate acestea, acestea nu trebuie să fie echivalente cu caracterele de control ASCII LF și CR. Standardul C garantează doar două lucruri:

1. Fiecare dintre aceste secvențe de evadare mapează un număr unic definit de implementare care poate fi stocat într-o singură valoare de caracter.
2. Când scrieți într-un fișier, nod de dispozitiv sau socket / fifo în modul text, „\ n” este tradus în mod transparent în secvența de linie nouă folosită de sistem, care poate avea mai mult de un caracter. Când citiți în modul text, secvența de linie nouă nativă este tradusă înapoi la „\ n”. În modul binar, nu se efectuează nicio traducere, iar reprezentarea internă produsă de „\ n” este transmisă direct.

Pe platformele Unix, de unde a apărut C, secvența de linie nouă nativă este ASCII LF ( 0x0A), deci „\ n” a fost pur și simplu definit ca fiind acea valoare. Cu reprezentarea internă și externă identică, traducerea efectuată în modul text este fără opțiune, iar Unix nu are noțiunea de mod text sau mod binar. Acest lucru a făcut ca mulți programatori care și-au dezvoltat software-ul pe sisteme Unix să ignore pur și simplu distincția, rezultând un cod care nu este portabil pe diferite platforme. deoarece orice fișier care nu este scris cu convenția Unix newline va fi citit greșit. De asemenea, în modul text, orice fișier care nu este scris cu secvența de linie nouă a sistemului (cum ar fi un fișier creat pe un sistem Unix, apoi copiat pe un sistem Windows) va fi citit greșit.

o problemă obișnuită este utilizarea „\ n” atunci când comunicați utilizând un protocol de Internet care impune utilizarea ASCII CR + LF pentru linii de final. Scrierea „\ n” într-un flux în modul text funcționează corect pe sistemele Windows, dar produce doar LF pe Unix și ceva complet diferit pe sisteme mai exotice. Utilizarea „\ r \ n” în modul binar este puțin mai bună.

Bibliotecile Java I / O nu le traduc în mod transparent în secvențe de linie nouă dependente de platformă pe intrare sau ieșire. În schimb, oferă funcții pentru scrierea unei linii complete care adaugă automat secvența de linie nouă nativă și funcții pentru citirea liniilor care acceptă oricare dintre CR, LF sau CR + LF ca terminator de linie (consultați BufferedReader.readLine () Metoda System.lineSeparator () poate fi utilizată pentru a prelua separatorul de linie subiacent.

Exemplu:

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

Python permite „Universal Newline Support” la deschiderea unui fișier pentru citire, atunci când importând module și când executăm un fișier.

Unele limbi au creat variabile speciale, constante și subrutine pentru a facilita liniile noi în timpul executării programului. În unele limbi, cum ar fi PHP și Perl, sunt necesare ghilimele duble pentru a efectua substituirea de evacuare pentru toate secvențele de evacuare, inclusiv „\ n” și „\ r”. În PHP, pentru a evita problemele de portabilitate, secvențele de linie nouă ar trebui emise folosind constanta PHP_EOL.

Exemplu în C #:

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

Probleme cu diferite formate de linie nouăEdit

Chiar dacă caracterele de control sunt definite fără ambiguități în tabelul de codificare a caracterelor corespunzător utilizat de un fișier text , există încă o problemă: există diferite convenții pentru a seta și afișa o întrerupere de linie.

Pentru a indica o singură întrerupere de linie, programele Unix utilizează feed de linie , a cărui valoare hexazecimală în ASCII este 0a , în timp ce majoritatea programelor comune MS-DOS și Microsoft Windows utilizează retur de transport + flux de linie , a cărui valoare hexazecimală în ASCII este 0d 0a . În ASCII, returnarea transportului este un caracter de control distinct.

Diferitele convenții de linie nouă determină afișarea incorectă a fișierelor text care au fost transferate între sisteme de diferite tipuri.

Text în fișierele create cu programe care sunt obișnuite pe Mac OS de tip Unix sau clasic, apar ca o singură linie lungă pe majoritatea programelor comune MS-DOS și Microsoft Windows, deoarece acestea nu afișează un singur linie de alimentare sau o singură returnare de caros ca întrerupere de linie.

În schimb, când vizualizați un fișier provenit de pe un computer Windows pe un sistem asemănător Unix, CR suplimentar poate fi afișat ca o a doua linie, ca ^ M sau ca < cr > la sfârșitul fiecărei linii.

Mai mult, alte programe decât editorii de text pot să nu accepte un fișier, de ex unele fișiere de configurare, codificate folosind convenția de linie nouă străină, ca fișier valid.

Problema poate fi greu de identificat, deoarece unele programe gestionează corect linia nouă de linii străine, în timp ce altele nu. De exemplu, un compilator poate eșua cu erori de sintaxă obscure, chiar dacă fișierul sursă pare corect atunci când este afișat pe consolă sau într-un editor. Pe un sistem asemănător Unix, comanda cat -v myfile.txt va trimite fișierul către stdout (în mod normal terminalul) și va face vizibil ^ M, care poate fi util pentru depanare. Editorii de text moderni recunosc, în general, toate aromele noilor linii CR + LF și permit utilizatorilor să facă conversii între diferitele standarde. Browserele web sunt, de obicei, capabile să afișeze fișiere text și site-uri web care utilizează diferite tipuri de linii noi.

Chiar dacă un program acceptă convenții diferite de linie nouă, aceste caracteristici nu sunt adesea etichetate, descrise sau documentate suficient. De obicei, un meniu sau o casetă combinată care enumeră diferite convenții de linie nouă va fi afișată utilizatorilor fără o indicație dacă selecția va reinterpreta, converti temporar sau va converti definitiv noile linii. Unele programe se vor transforma implicit în deschidere, copiere, lipire sau salvare – adesea inconsecvent.

Majoritatea protocoalelor textuale de Internet (inclusiv HTTP, SMTP, FTP, IRC și multe altele) impun utilizarea ASCII CR + LF („\ r \ n”, 0x0D 0x0A) la nivel de protocol, dar recomandă ca aplicațiile tolerante să recunoască și LF singuratic („\ n”, 0x0A). În ciuda standardului dictat, multe aplicații folosesc în mod eronat secvența de evadare C linie nouă „\ n” (LF) în loc de combinația corectă de secvențe de evacuare a returului căruciorului și secvențe de evacuare linie nouă „\ r \ n” (CR + LF) (a se vedea secțiunea Newline în limbaje de programare de mai sus). Această utilizare accidentală a secvențelor de evacuare greșite duce la probleme atunci când se încearcă comunicarea cu sistemele care aderă la interpretarea mai strictă a standardelor în locul interpretării tolerante sugerate. Un astfel de sistem intolerant este agentul de transfer de e-mail qmail care refuză în mod activ să accepte mesaje de la sisteme care trimit LF gol în loc de CR + LF necesar.

Formatul standard de mesaje pe Internet pentru e-mail: CR și LF TREBUIE apar doar împreună ca CRLF; acestea NU TREBUIE să apară independent în corp.

Protocolul de transfer de fișiere poate converti automat linii noi în fișiere care sunt transferate între sisteme cu reprezentări diferite de linie nouă atunci când transferul se face în „modul ASCII”.Cu toate acestea, transferul fișierelor binare în acest mod are de obicei rezultate dezastruoase: orice apariție a secvenței de octeți de linie nouă – care nu are semantică terminator de linie în acest context, dar este doar o parte a unei secvențe normale de octeți – va fi tradusă la orice reprezentare a liniei noi celălalt sistem folosește, corupând efectiv fișierul. Clienții FTP folosesc adesea unele euristici (de exemplu, inspecția extensiilor de nume de fișier) pentru a selecta automat fie modul binar, fie modul ASCII, dar în cele din urmă revine utilizatorilor să se asigure că fișierele lor sunt transferate în modul corect. Dacă există vreo îndoială cu privire la modul corect, ar trebui să se utilizeze modul binar, deoarece atunci niciun fișier nu va fi modificat de FTP, deși acestea pot fi afișate incorect.

Conversia între formatele newline Editați

Editorii de text sunt adesea folosiți pentru conversia unui fișier text între diferite formate de linie nouă; majoritatea editorilor moderni pot citi și scrie fișiere folosind cel puțin diferitele convenții ASCII CR / LF. De exemplu, editorul Vim poate face un fișier compatibil cu editorul de text Windows Notepad. În cadrul vim

 :set fileformat=dos :wq

Editorii pot fi improprii pentru conversia fișierelor mai mari sau conversia în bloc a mai multor fișiere. Pentru fișiere mai mari (pe Windows NT / 2000 / XP) se folosește adesea următoarea comandă:

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

Programe cu scop special de convertit fișierele dintre diferite convenții de linie nouă includ unix2dos și dos2unix, mac2unix și unix2mac, mac2dos și dos2mac și flip. Comanda tr este disponibilă practic pe orice sistem asemănător Unix și poate fi utilizată pentru a efectua operații de înlocuire arbitrare pe caractere individuale. Un fișier text DOS / Windows poate fi convertit în format Unix prin simpla eliminare a tuturor caracterelor ASCII CR cu

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

sau, dacă textul are doar linii CR noi, prin conversia tuturor liniilor noi CR în LF cu

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

Aceleași sarcini sunt uneori efectuate cu awk, sed sau în Perl dacă platforma are un interpret Perl:

Comanda fișier poate identifica tipul de terminații de linie:

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

Comanda Unrep egrep (grep extins) poate fi utilizat pentru a imprima numele de fișiere ale fișierelor Unix sau DOS (presupunând doar fișiere în stil Unix și DOS, fără Mac OS):

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

Alte instrumente permit utilizatorului să vizualizeze caracterele EOL:

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