Nova linha

Na computação, nova linha (quebra de linha ou também fim de linha, abreviada para EOL) é um caractere ou uma seqüência de caracteres que significam “fim de uma linha de texto”. O código que representa a nova linha varia de plataforma para plataforma de hardware e sistemas operacionais, o que pode ser problemático ao compartilhar dados entre diferentes plataformas.

Há certa confusão acerca de saber se uma quebra de linha termina ou separa linhas. Se admitirmos que ela é um separador, então não deve haver uma quebra de linha no fim do arquivo. A convenção geral é acrescentar uma quebra de linha mesmo após a última linha, ou seja, considerar a quebra de linha como um finalizador. Há programas que apresentam dificuldades em processar a última linha dum arquivo se ela não terminar com uma quebra de linha. Por outro lado, programa que interpretam a quebra de linha como um separador, interpretarão uma quebra de linha no final do arquivo como o começo duma nova linha (vazia). O resultado é a possível diferença na contagem de linhas de um arquivo, ainda que não haja outros problemas.

Representações

No Unix, um LF é frequentemente chamado de nova linha. Ele é interpretado como a instrução que tem o mesmo efeito que um CR-LF teria numa impressora.

Os programas e sistemas operacionais podem representar uma nova linha como um ou dois caracteres de controle:

• No ASCII e outros conjuntos de caracteres compatíveis usam um LF (0x0A) ou um CR (0x0D) individualmente, ou CR seguido por LF (CR+LF, 0x0D 0x0A); veja adiante a razão histórica da convenção CR+LF.
  • LF:    Unix, Linux, AIX, Xenix, Mac OS X, BeOS, Amiga, RISC OS e outros.
  • CR+LF: CP/M, MP/M, DOS, OS/2, Microsoft Windows
  • CR:    Commodore, Apple II e Mac OS até Mac OS 9.
• EBCDIC — principalmente computadores da IBM, inclusive z/OS (OS/390), i5/OS (OS/400) — usam NEL (0x15) como sendo o caractere para nova linha. Entretanto, o EBCDIC também possui caracteres chamados CR e LF, cujos valores numéricos diferem dos usados no ASCII.

Unicode

O padrão Unicode lida com este problema ao definir um grande número de caracteres que devem ser interpretados pelas aplicações como sendo fim de linha

•  LF:    Line Feed, U+000A
•  CR:    Carriage return, U+000D
•  CR+LF: CR seguido por LF, *U+000D seguido por U+000A
•  NEL:   Next Line, U+0085
•  FF:    Form Feed, U+000C
•  LS:    Line Separator, U+2028
•  PS:    Paragraph Separator, U+2029

Histórico

O padrão ASCII foi desenvolvido simultaneamente pela ISO e pela ASA. A seqüência CR+LF era de uso comum em vários computadores que usavam máquinas teletipo como console, uma vez que esta seqüência era necessária para posicionar a impressora no começo duma nova linha. Como o conceito do isolamento dos detalhes de hardware por um driver de software ainda não tinha surgido; os programas tinham de enviar diretamente tais caracteres. O uso de dois caracteres devia-se ao fato de que os teletipos não eram rápidos o suficiente para retornar do canto direito ao canto esquerdo no tempo disponível para apenas um caractere — assim o CR vinha em primeiro lugar. Na verdade, muitas vezes era necessário acrescentar ainda um terceiro caractere: CR+LF+NUL (onde NUL significa “não faça nada”) ou CR+CR+LF (enviando CR duas vezes) para esperar que a cabeça se estabilizasse. Tendo os teletipos se tornado obsoletos, os programas criados para eles fizeram com que esta seqüência de dois caracteres persistisse.

Linguagens de programação

Para tornar os programas portáveis, as linguagens de programação criam mecanismos para abstrair os diferentes tipos de seqüências de quebra de linha existentes.

A linguagem C define as seqüências de escape '\n' (newline) e '\r' (carriage return). Ao contrário do que muitos pensam, eles não são — em geral — equivalentes aos caracteres de controle ASCII LF e CR. O padrão C garante apenas duas coisas:

1. Estas seqüências de escape são armazenadas no computador como apenas um caractere char.
2. Ao criar um arquivo em “modo texto”, '\n' será convertido de maneira transparente para a seqüência de quebra de linha usada pelo sistema, que poderá ser mais longa do que um caractere.

A linguagem de programação Java também define as seqüências de escape '\n' e o '\r'. Ao contrário do C, elas são sempre representadas por 0x0A e 0x0D, respectivamente. Isto significa que um '\n' pode não ser interpretado corretamente por programas de todas as plataformas — se tais programas não forem escritos em Java. Porém, a biblioteca do Java fornece métodos capazes de lidar corretamente com a leitura e escrita de arquivos de maneira consistente em qualquer ambiente.

Problemas

As diferentes convenções para a quebra de linha muitas vezes fazem com que os arquivos de texto copiados duma plataforma para outra sejam mostrados de maneira incorreta. Por exemplo, arquivos criados no Unix ou Apple Macintosh serão vistos como uma longa e única linha no Windows. Analogamente, um arquivo do Windows visto no Unix terá seus CR mostrados como um ^M ao final de cada linha ou como um segundo pula linha.

O problema pode ser de difícil detecção. Por exemplo, um compilador poderá falhar com erros de sintaxe obscuros embora o arquivo fonte pareça normal. Os editores de textos mais recentes reconhecem todas as variações de quebra de linha do tipo CR e LF, permitindo ao usuário converter entre os diferentes padrões. Em geral, os navegadores também são capazes de fazê-lo.

O FTP converte automaticamente as quebras de linha de arquivos transferidos entre sistemas com diferentes representações quando a transferência é feita em modo ASCII. Porém, transferir arquivos binários neste formato pode ter resultados desastrosos: qualquer ocorrência dos caracteres que representam a quebra de linha — que neste contexto não representam realmente uma quebra de linha — será incorretamente convertida para a representação nativa dos sistemas, corrompendo o arquivo. Embora o cliente FTP possa tentar adivinhar o tipo do arquivo (por exemplo, a partir de sua extensão) cabe ao usuário decidir o modo de transferência: binário ou ASCII. Havendo dúvidas, use o modo binário, de maneira que o arquivo não seja alterado durante a FTP, embora possa ser apresentado incorretamente.

Utilitários para conversão

Em geral, é a maneira mais simples de converter um arquivo de texto entre diferentes formatos de quebra de linha; a maioria dos editores de texto modernos podem ler e escrever arquivos usando ao menos a convenção ASCII CR/LF. Infelizmente isto não vale para o editor padrão do Windows bloco de notas, mas vale para o Wordpad. No Unix, os comandos dos2unix e unix2dos podem ser usados para converter entre o ASCII CR+LF (DOS/Windows) e o LF (Unix) — embora a sintaxe deste comando possa variar.

Exemplos

Detectar e substituir caracteres de quebra de linha em C:

/* Para cada linha do arquivo indicado por FILE *fp: */
while ( fgets( buf, sizeof(buf), fp ) ) {
        /* Se houver um separador de linha ele deve estar no final */
        char * last = strchr(buf, '\0');
        /* Procure por LF e os substitua */
        if (last - 1 >= buf && *--last == '\n')
* last = '\0';
        /* Procure por CR e os substitua */
        if (last - 1 >= buf && *--last == '\r')
* last = '\0';
 
        /* Faça algo de útil com a string sem newline que está em buf */
}

Referências

• The Unicode Reference, parágrafo 5.8 do Capítulo 5 do Unicode 4.0
• The End-of-Line Story
• The [NEL] Newline Character
• How to convert a group of mixed text files to the preferred line ending all at once using vim