Nova línia
En informàtica, nova línia és un caràcter especial, o seqüència de caràcters, que indica el final d'una línia de text i el pas a la següent. Se li diu així perquè el caràcter a la dreta del nova línia apareixerà a la línia de sota dels caràcters que hi havia a l'esquerra, per tant en una línia nova.
La codificació del caràcter nova línia no és la mateixa en totes les arquitectures ni sistemes operatius, cosa que pot donar problemes quan s'intercanvien dades entre ordinadors.
Finalitzador o separador modifica
Encara es discuteix si el caràcter de nova línia hauria d'acabar o separar les línies.
Si s'usa com separador, un text amb les línies A, B, i C quedaria gravat així (representant el caràcter de nova línia amb \n):
- A \n B \n C
Llavors, l'última línia (C) no té el codi de nova línia al final. Aquest comportament està poc recomanat, i alguns programes tenen problemes processant l'última línia d'un fitxer si no acaba amb una nova línia, així que la convenció general és tractar \n com a finalitzador:
- A \n B \n C \n
Aquest canvi pot afectar en el recompte de línies d'un fitxer, però no dona problemes majors.
Representacions modifica
Les aplicacions i els sistemes operatius normalment representen el caràcter nova línia amb un o amb dos codis de control:
- Els sistemes basats en ASCII o en una codificació de caràcters compatible usen
LF(salt de línia),CR(retorn de carro), o CRLF (CR seguit de LF): - Els sistemes EBCDIC, principalment mainframes d'IBM incloent z/OS (OS/390), i5/OS (OS/400), usen
NEL( següent línia) com a caràcter per nova línia. EBCDIC també té caràcters anomenatsCRiLF, però el valor numèric delLFés diferent del que s'usa en ASCII. Altres variants d'EBCDIC també usenNELperò amb un altre valor numèric assignat al caràcter. - OpenVMS utilitza un sistema de fitxers basat en registres, i guarda els fitxers de text amb un registre per línia. Per tant, no s'emmagatzema cap finalitzador de línia, encara que el sistema pot afegir finalitzadors a cada línia de forma transparent quan una aplicació accedeix a les dades.
Els valors numèrics usats normalment són:
CR: decimal 13, hexadecimal 0DLF: decimal 10, hexadecimal 0ANEL: decimal 21, hexadecimal 15
El CRLF no és més que un darrere l'altre, per tant 0D 0A en hexadecimal.
Protocols de xarxa modifica
Molts protocols d'Internet són textuals, és a dir, que envien línies de text per fer les peticions (a més d'usar codi binari). Per això, han de controlar com s'ha de marcar el final de cada línia.
Per tradició, la majoria han funcionat usant el CRLF en el nivell de protocol. Per exemple, HTTP, SMTP, FTP i IRC, entre d'altres.
No obstant això, alguns recomanen que les aplicacions també reconeguin un LF .
A la pràctica, hi ha moltes aplicacions que acaben usant (incorrectament) el codi de nova línia del llenguatge de programació C, que és \n però té un valor que depèn de la plataforma (vegeu secció Nl en llenguatges de programació, més avall).
Això causa problemes en comunicar amb sistemes que segueixen més fermament l'estàndard. Per exemple, l'administrador de correu qmail no accepta missatges de sistemes que enviïn només LF en lloc del CRLF requerit. Detalls, en anglès.
Unicode modifica
L'estàndard Unicode tracta el problema definint un gran nombre de caràcters que les aplicacions han de reconèixer com a finalitzadors de línia. Segons l'estàndard Unicode:
LF : Salt de línia, u000A
CR : Retorn de carro, u000D
CR + LF : CR seguit per LF
NEL : Next Line, u0085
FF : Form Feed, u000C
LS : Line Separator, u2028
PS : Paragraph Separator, u2029
Sembla massa complicat enfront d'altres possibles solucions, com per exemple convertir tots els finalitzador a un sol caràcter com el LF , però s'ha fet així perquè la conversió pugui ser bidireccional. Si transformem un text EBCDIC canviant tots els NEL per LF , i després ho volem tornar a EBCDIC, no sabríem si els LF de la nostra codificació corresponen a NEL o al mateix LF de EBCDIC.
En Unicode, es pot fer la transformació sense perdre informació, de manera que els programes segueixen podent reconèixer tots els tipus possibles de finalitzadors de línia.
Història modifica
ASCII es va desenvolupar simultàniament per l'ISO i el ASA, l'organització predecessora de ANSI. Durant el període 1963-1968, els esborranys (pre estàndard) d'ISO permetien usar tant CRLF com LF per marcar una nova línia, mentre que els esborranys de ASA permetien només CRLF.
El sistema operatiu Multics va començar a desenvolupar-se en 1964 i usava només LF. Unix va seguir la pràctica de Multics, i sistemes posteriors van seguir a Unix.
La seqüència CR LF era comú en els primers ordinadors que tenien màquines de teletip (com el ASR33) com a dispositiu de terminal. Aquesta seqüència era necessària per posicionar el capçal de la impressora al principi d'una nova línia. Com aquesta operació no es podia fer en temps "1 caràcter", calia dividir-la en dos caràcters. De vegades era necessari enviar CR LF NUL (sent NUL el caràcter de control que li mana "no fer res"), per assegurar-se que el capçal d'impressió parés de moure. Després que aquests sistemes mecànics desapareguessin, la seqüència CR LF va deixar de tenir sentit, però tot i així s'ha seguit usant.
S'especula que QDOS (que Microsoft va comprar i renombró a MS-DOS) va adoptar CRLF per copiar la implementació usada per CP/M. També es diu que CP/M va triar CR + LF per introduir una clara incompatibilitat amb Unix, i així intentar evitar una possible denúncia de AT&T/ Bell, que deia que CP/M violava el copyright d'Unix perquè estava basat en Unix (segons aquesta teoria).
Altres creuen que CP/M s'assembla més als sistemes de DEC (com el RSTS/E) que a Unix. En qualsevol cas, aquesta convenció de QDOS va passar al següent sistema operatiu comercialitzat per Microsoft, el Windows, i segueix igual en l'actualitat (2006).
En llenguatges de programació modifica
Perquè sigui més fàcil crear programes portàtils, els llenguatges de programació ofereixen abstraccions per no haver de tractar amb les petites diferències entre sistemes.
El llenguatge de programació C permet usar les seqüències d'escapament \n (nova línia) i \r (retorn de carro).
No obstant això, aquestes no són equivalents a LF i CR en general.
L'estàndard C només garanteix dues coses:
- Cadascuna d'aquestes seqüències es tradueix a un nombre que cap en un sol valor char , i que depèn de la implementació.
- Quan s'escriu a un fitxer de tipus text (en contraposició a un arxiu binari), el
\nes tradueix de forma transparent al codi de nova línia natiu del sistema, que pot ser de més d'un caràcter. Quan es llegeix en manera text, la seqüència de nova línia nativa es torna a traduir a\n. En mode binari no es fan aquestes traduccions.
En les plataformes Unix, on va néixer C, la seqüència que indica nova línia és el codi ASCII LF ( 0x0A ), així que al principi es va fer que \n tingués aquest valor.
Llavors, com la representació interna i l'externa són idèntiques, la traducció que cal fer en mode text és nul·la, i manera text i binari es comporten de la mateixa manera.
Això ha fet que molts programadors ignorin per complet la distinció, cosa que afecta el programari desenvolupat, que deixa de ser portable.
Un altre problema comú és utilitzar \n en comunicar mitjançant un protocol de xarxa que requereix CRLF com a finalitzador. En Windows funcionarà, ja que \n es tradueix a la representació nativa, que és precisament CR + LF , però en Unix produeix només LF (la representació nativa del caràcter nova línia).
Utilitza \r \n en mode binari és una mica millor, però tampoc funciona en el cas general. El correcte és especificar els valors concrets, en mode, per exemple, \x0D \x0A
Perl i C++ ofereixen la mateixa interpretació de '\n' que C. C++ també té std :: endl, que és la representació d'una nova línia en el sistema subjacent i buida el stream després d'emetre. Perl té un 'binmode' per les traduccions literals a l'hora de llegir i escriure en fitxers.
Java també proporciona les seqüències d'escapament \n i \r , que sí que garanteixen que el seu valor serà 0x0A i 0x0D respectivament. Perquè un programa fet en Java es vegi correctament en el notepad, cal posar \r \n . Això cobra vital importància si es tracta de comunicar el nostre programa en Java amb un programa fet en C mitjançant un arxiu txt.
Les biblioteques d'entrada / sortida de Java no tradueixen aquestes seqüències automàticament, com en C. En canvi, ofereixen funcions per escriure una línia completa afegint el codi natiu de nova línia, i funcions per llegir línies que accepten qualsevol seqüència com a finalitzador ( CR, LF, CRLF).
Problemes comuns modifica
Les diferents representacions de la nova línia en els sistemes operatius de vegades causen que en transferir un fitxer entre dos ordinadors, es mostri incorrectament.
Per exemple, en condicions normals, els fitxers creats en sistemes Unix o Apple Macintosh es veuran com una línia llarga en Windows.
I al revés: els fitxers creats en un ordinador amb Windows es veuran estranys amb alguns editors, ja que el CR extra que Unix no necessita es mostrarà com un ^M al final de cada línia.
El problema pot ser difícil de detectar si alguns programes manegen bé els finalitzadors de línia aliens però altres no. Per exemple, un compilador pot fallar amb estranys missatges d'error encara que el fitxer font es mostra correcte en la línia d'ordres o editor de text.
Els navegadors web solen poder treballar amb pàgines codificades en qualsevol sistema, i els editors de text moderns permeten no només obrir fitxers de qualsevol codificació, sinó convertir entre elles (vegeu següent secció).
En transferir fitxers per FTP, el client pot convertir automàticament entre diferents codificacions si està activat el mode de text. No obstant això, si s'usa aquesta manera per transferir un arxiu binari, el fitxer arribarà corrupte. Els programes solen usar heurístics per detectar si un fitxer és binari o no, però poden equivocar.
Utilitats de conversió modifica
En general, un editor de text és el programa més convenient per treballar amb fitxers que usen diferents finalitzadors de línia. La majoria d'editors moderns permeten qualsevol combinació amb els codis de control ASCII CR i LF .
Malauradament, l'editor per defecte de Windows (Notepad) no ho permet, encara que Wordpad si.
El programa de MS-DOS anomenat EDIT també es pot utilitzar per convertir un fitxer que usi els finalitzadors de línia de tipus Unix. Només cal obrir l'arxiu i tornar-lo a gravar.
En molts sistemes Unix es troben les utilitats dos2unix i unix2dos , que transformen entre les codificacions CRLF (DOS/Windows) i LF (Unix). Hi ha diverses versions d'aquests programes, amb sintaxi una mica diferents.
Es pot utilitzar el programa tr , que sí que està en qualsevol sistema tipus Unix, i que permet fer qualsevol tipus de transformació de caràcters.
Per passar de DOS / Windows a Unix, eliminar tots els CR :
tr -d '\r' < fitxer_entrada > fitxer_sortida
I en l'altra direcció: es pot convertir d'Unix a DOS amb Sed:
sed -e 's/$/\r/' fitxer_entrada > fitxer_sortida
En sistemes Unix hi ha el comandament file , que permet identificar el tipus de finalitzadors de línia que utilitza una.