Os conceitos de retorno de carro (CR) e alimentação de linha (LF) estão intimamente associados e podem ser considerados separadamente ou em conjunto. Na mídia física de máquinas de escrever e impressoras, dois eixos de movimento, “para baixo” e “transversalmente”, são necessários para criar uma nova linha na página. Embora o design de uma máquina (máquina de escrever ou impressora) deva considerá-los separadamente, a lógica abstrata do software pode combiná-los como um evento. É por isso que uma nova linha na codificação de caracteres pode ser definida como CR e LF combinados em um (comumente chamado de CR + LF ou CRLF ).

Alguns os conjuntos de caracteres fornecem um código de caractere de nova linha separado. EBCDIC, por exemplo, fornece um código de caractere NL além dos códigos CR e LF. O Unicode, além de fornecer os códigos de controle ASCII CR e LF, também fornece um código de controle de “próxima linha” (NEL), bem como códigos de controle para marcadores de “separador de linha” e “separador de parágrafo”.

• Sistemas EBCDIC – principalmente sistemas de mainframe IBM, incluindo z / OS (OS / 390) e i5 / OS (OS / 400) – use NL (Nova Linha, 0x15) como o caractere que combina as funções de alimentação de linha e transporte Retorna. O caractere Unicode equivalente ( 0x85 ) é chamado de NEL (próxima linha). EBCDIC também possui caracteres de controle chamados CR e LF, mas o valor numérico de LF (0x25) difere daquele usado por ASCII (0x0A). Além disso, algumas variantes do EBCDIC também usam NL, mas atribuem um código numérico diferente ao caractere. No entanto, esses sistemas operacionais usam um sistema de arquivos baseado em registro, que armazena arquivos de texto como um registro por linha. Na maioria dos formatos de arquivo, nenhum terminador de linha é realmente armazenado.
• Os sistemas operacionais para a série CDC 6000 definiam uma nova linha como dois ou mais caracteres de seis bits com valor zero no final de uma palavra de 60 bits. Algumas configurações também definiram um caractere de valor zero como dois pontos, com o resultado de que vários dois pontos podem ser interpretados como uma nova linha dependendo da posição.
• RSX-11 e OpenVMS também usam um sistema de arquivos baseado em registro , que armazena arquivos de texto como um registro por linha. Na maioria dos formatos de arquivo, nenhum terminador de linha é realmente armazenado, mas o recurso Record Management Services pode adicionar um terminador de forma transparente a cada linha quando ela é recuperada por um aplicativo. Os próprios registros podem conter os mesmos caracteres de terminação de linha, o que pode ser considerado um recurso ou um incômodo, dependendo do aplicativo. O RMS não apenas armazenou registros, mas também armazenou metadados sobre os separadores de registro em diferentes bits para o arquivo para complicar ainda mais as coisas (já que os arquivos poderiam ter registros de comprimento fixo, registros que eram prefixados por uma contagem ou registros que foram encerrados por um caractere específico ) Os bits não eram genéricos, portanto, embora pudessem especificar que CRLF ou LF ou mesmo CR era o terminador de linha, não podiam substituir algum outro código.
• Comprimento fixo de linha foi usado por alguns dos primeiros mainframes operacionais sistemas. Em tal sistema, um fim de linha implícito foi assumido a cada 72 ou 80 caracteres, por exemplo. Nenhum caractere de nova linha foi armazenado. Se um arquivo foi importado do mundo externo, as linhas mais curtas que o comprimento da linha tiveram que ser preenchidas com espaços, enquanto as linhas mais longas que o comprimento da linha tiveram que ser truncadas. Isso imitou o uso de cartões perfurados, nos quais cada linha era armazenada em um cartão separado, geralmente com 80 colunas em cada cartão, geralmente com números de sequência nas colunas 73–80. Muitos desses sistemas adicionaram um caractere de controle de carro ao início do próximo registro; isso pode indicar se o próximo registro é uma continuação da linha iniciada pelo registro anterior, ou uma nova linha, ou deve sobrepor a linha anterior (semelhante a um CR). Freqüentemente, esse era um caractere de impressão normal como # que, portanto, não poderia ser usado como o primeiro caractere em uma linha. Algumas impressoras de linha anteriores interpretaram esses caracteres diretamente nos registros enviados a eles.

UnicodeEdit

O padrão Unicode define um número de caracteres que os aplicativos em conformidade devem reconhecer como terminadores de linha:

LF: Line Feed, U + 000A VT: Guia vertical, U + 000B FF: Alimentação de formulário, U + 000C CR: Retorno de carro, U + 000D CR + LF: CR (U + 000D) seguido por LF (U + 000A) NEL: Próxima linha, U + 0085 LS: Separador de linha, U + 2028 PS: Separador de parágrafo, U + 2029

Isso pode parecer excessivamente complicado em comparação com uma abordagem como converter todos os terminadores de linha em um único caractere, por exemplo LF. No entanto, o Unicode foi projetado para preservar todas as informações ao converter um arquivo de texto de qualquer codificação existente para Unicode e vice-versa. Portanto, o Unicode deve conter caracteres incluídos nas codificações existentes.O NL está incluído no EBCDIC com o código 0x15 e frequentemente mapeado para o NEL, que é um caractere de controle no conjunto de controle C1. Como tal, é definido pela ECMA 48 e reconhecido por codificações em conformidade com a ISO / IEC 2022 (que é equivalente a ECMA 35). O conjunto de controle C1 também é compatível com ISO-8859-1. A abordagem adotada no padrão Unicode permite a transformação de ida e volta para preservar as informações, ao mesmo tempo que permite que os aplicativos reconheçam todos os tipos possíveis de terminadores de linha.

Reconhecendo e usando os códigos de nova linha maiores que 0x7F (NEL, LS e PS) não é feito com frequência. Eles são bytes múltiplos em UTF-8, e o código para NEL foi usado como o caractere de reticências (… ) no Windows-1252. Por exemplo:

• ECMAScript aceita LS e PS como quebras de linha, mas considera U + 0085 (NEL) espaços em branco em vez de uma quebra de linha.
• O Windows 10 não trata nenhum dos NEL, LS ou PS como quebras de linha em seu editor de texto padrão, o Bloco de notas.
• gedit, o editor de texto padrão do ambiente de área de trabalho GNOME , trata LS e PS como novas linhas, mas não para NEL.
• JSON permite caracteres LS e PS dentro de strings, enquanto ECMAScript anterior a ES2019 os tratava como novas linhas e, portanto, sintaxe ilegal.
• YAML não os reconhece mais como especiais a partir da versão 1.2, para serem compatíveis com JSON.

Os caracteres Unicode U + 2424 (SÍMBOLO PARA NEWLINE, ␤ ), U + 23CE (SÍMBOLO DE RETORNO, ⏎ ), U + 240D (SÍMBOLO PARA CARRIAGE RETURN, ␍ ) e U + 240A (SÍMBOLO PARA ALIMENTAÇÃO DE LINHA, ␊ ) são destina-se a apresentar ao leitor do documento um caractere visível pelo usuário e, portanto, não são reconhecidos como uma nova linha.

Sequências de escapeEditar

Uma sequência de escape é uma combinação de caracteres que não representa nenhum texto; em vez de ser exibido (como texto), ele deve ser interceptado pelo programa e uma função especial deve ser executada. Sequências de escape também são usadas para manipular (definir, pesquisar, substituir, etc.) caracteres especiais.

Em linguagens de programação, Editar

Para facilitar a criação de programas portáveis, as linguagens de programação fornecem algumas abstrações para lidar com os diferentes tipos de sequências de nova linha usadas em ambientes diferentes.

A linguagem de programação C fornece as sequências de escape “\ n” (nova linha) e “\ r” (retorno de carro). No entanto, eles não precisam ser equivalentes aos caracteres de controle ASCII LF e CR. O padrão C garante apenas duas coisas:

1. Cada uma dessas sequências de escape mapeia para um número único definido pela implementação que pode ser armazenado em um único valor char.
2. Ao escrever para um arquivo, nó de dispositivo ou socket / fifo em modo de texto, “\ n” é traduzido de forma transparente para a sequência de nova linha nativa usada pelo sistema, que pode ser maior que um caractere. Ao ler em modo de texto, a sequência de nova linha nativa é traduzida de volta para “\ n”. No modo binário, nenhuma tradução é realizada, e a representação interna produzida por “\ n” é produzida diretamente.

Em plataformas Unix, onde C se originou, a sequência de nova linha nativa é ASCII LF ( 0x0A), então “\ n” foi simplesmente definido para ser esse valor. Com as representações interna e externa idênticas, a tradução realizada em modo texto é autônoma e o Unix não tem noção de modo texto ou modo binário. Isso fez com que muitos programadores que desenvolveram seu software em sistemas Unix simplesmente ignorassem a distinção completamente, resultando em um código que não é portável para plataformas diferentes.

A função de biblioteca C fgets () é melhor evitada no modo binário porque qualquer arquivo não escrito com a convenção de nova linha do Unix será mal lido. Além disso, no modo de texto, qualquer arquivo não escrito com a seqüência de nova linha nativa do sistema (como um arquivo criado em um sistema Unix e depois copiado para um sistema Windows) também será lido incorretamente.

Outro problema comum é o uso de “\ n” ao se comunicar usando um protocolo de Internet que exige o uso de ASCII CR + LF para linhas finais. Escrever “\ n” em um fluxo de modo de texto funciona corretamente em sistemas Windows, mas produz apenas LF em Unix, e algo completamente diferente em sistemas mais exóticos. Usar “\ r \ n” no modo binário é um pouco melhor.

As bibliotecas Java I / O não os traduzem de forma transparente em sequências de nova linha dependentes da plataforma no entrada ou saída. Em vez disso, eles fornecem funções para escrever uma linha completa que adiciona automaticamente a sequência de nova linha nativa e funções para ler linhas que aceitam qualquer um de CR, LF ou CR + LF como um terminador de linha (consulte BufferedReader.readLine () ). O método System.lineSeparator () pode ser usado para recuperar o separador de linha subjacente.

Exemplo:

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

Python permite “Suporte universal de nova linha” ao abrir um arquivo para leitura, quando importar módulos e ao executar um arquivo.

Algumas linguagens criaram variáveis, constantes e sub-rotinas especiais para facilitar as novas linhas durante a execução do programa. Em algumas linguagens como PHP e Perl, as aspas duplas são necessárias para realizar a substituição de escape para todas as sequências de escape, incluindo “\ n” e “\ r”. Em PHP, para evitar problemas de portabilidade, as sequências de nova linha devem ser emitidas usando a constante PHP_EOL.

Exemplo em C #:

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

Problemas com diferentes formatos de nova linha Editar

Mesmo que os caracteres de controle sejam definidos de forma inequívoca na tabela de codificação de caracteres correspondente usada por um arquivo de texto , ainda há um problema: existem diferentes convenções para definir e exibir uma quebra de linha.

Para denotar uma única quebra de linha, os programas Unix usam alimentação de linha , cujo valor hexadecimal em ASCII é 0a , enquanto a maioria dos programas comuns para MS-DOS e Microsoft Windows usam retorno de carro + alimentação de linha , cujo valor hexadecimal em ASCII é 0d 0a . Em ASCII, o retorno de carro é um caractere de controle distinto.

As diferentes convenções de nova linha fazem com que os arquivos de texto que foram transferidos entre sistemas de diferentes tipos sejam exibidos incorretamente.

Texto nos arquivos criados com programas que são comuns no tipo Unix ou Mac OS clássico, aparecem como uma única linha longa na maioria dos programas comuns ao MS-DOS e Microsoft Windows porque eles não exibem um único alimentação de linha ou um único retorno de carro como quebra de linha.

Por outro lado, ao visualizar um arquivo originado de um computador Windows em um sistema semelhante ao Unix, o CR extra pode ser exibido como uma segunda quebra de linha, como ^ M, ou como < cr > no final de cada linha.

Além disso, programas que não sejam editores de texto podem não aceitar um arquivo, por exemplo algum arquivo de configuração, codificado usando a convenção de nova linha estrangeira, como um arquivo válido.

O problema pode ser difícil de detectar porque alguns programas lidam com as novas linhas estrangeiras adequadamente, enquanto outros não. Por exemplo, um compilador pode falhar com erros de sintaxe obscuros, mesmo que o arquivo de origem pareça correto quando exibido no console ou em um editor. Em um sistema semelhante ao Unix, o comando cat -v myfile.txt enviará o arquivo para stdout (normalmente o terminal) e tornará o ^ M visível, o que pode ser útil para depuração. Os editores de texto modernos geralmente reconhecem todos os tipos de novas linhas CR + LF e permitem que os usuários convertam entre os diferentes padrões. Os navegadores da Web geralmente também são capazes de exibir arquivos de texto e sites que usam diferentes tipos de novas linhas.

Mesmo se um programa suportar diferentes convenções de novas linhas, esses recursos geralmente não são identificados, descritos ou documentados de maneira suficiente. Normalmente, um menu ou caixa de combinação enumerando diferentes convenções de nova linha será exibido para os usuários sem uma indicação se a seleção irá reinterpretar, converter temporariamente ou converter permanentemente as novas linhas. Alguns programas serão convertidos implicitamente ao abrir, copiar, colar ou salvar – muitas vezes de maneira inconsistente.

A maioria dos protocolos textuais da Internet (incluindo HTTP, SMTP, FTP, IRC e muitos outros) exige o uso de ASCII CR + LF (“\ r \ n”, 0x0D 0x0A) no nível do protocolo, mas recomendamos que os aplicativos tolerantes também reconheçam o LF (“\ n”, 0x0A) solitário. Apesar do padrão ditado, muitos aplicativos usam erroneamente a sequência de escape de nova linha C “\ n” (LF) em vez da combinação correta de escape de retorno de carro e sequências de escape de nova linha “\ r \ n” (CR + LF) (consulte a seção Nova linha em linguagens de programação acima). Este uso acidental de sequências de escape erradas leva a problemas ao tentar se comunicar com sistemas que aderem à interpretação mais rígida dos padrões em vez da interpretação tolerante sugerida. Um desses sistemas intolerantes é o agente de transferência de e-mail qmail, que se recusa ativamente a aceitar mensagens de sistemas que enviam LF puro em vez do CR + LF necessário.

O formato de mensagem padrão da Internet para e-mail declara: CR e LF DEVEM ocorrem apenas juntos como CRLF; eles NÃO DEVEM aparecer independentemente no corpo.

O protocolo de transferência de arquivos pode converter automaticamente novas linhas em arquivos sendo transferidos entre sistemas com diferentes representações de nova linha quando a transferência é feita no “modo ASCII”.No entanto, a transferência de arquivos binários neste modo geralmente tem resultados desastrosos: qualquer ocorrência da sequência de bytes de nova linha – que não tem semântica de terminador de linha neste contexto, mas é apenas parte de uma sequência normal de bytes – será traduzida para qualquer representação de nova linha o outro sistema usa, corrompendo efetivamente o arquivo. Os clientes FTP frequentemente empregam algumas heurísticas (por exemplo, inspeção de extensões de nome de arquivo) para selecionar automaticamente o modo binário ou ASCII, mas no final cabe aos usuários garantir que seus arquivos sejam transferidos no modo correto. Se houver alguma dúvida quanto ao modo correto, o modo binário deve ser usado, pois nenhum arquivo será alterado pelo FTP, embora possa ser exibido incorretamente.

Conversão entre formatos de nova linha Editar

Os editores de texto são freqüentemente usados para converter um arquivo de texto entre diferentes formatos de nova linha; a maioria dos editores modernos pode ler e gravar arquivos usando pelo menos as diferentes convenções ASCII CR / LF. Por exemplo, o editor Vim pode tornar um arquivo compatível com o editor de texto Bloco de notas do Windows. No vim

 :set fileformat=dos :wq

Os editores podem ser inadequados para a conversão de arquivos maiores ou conversão em massa de muitos arquivos. Para arquivos maiores (no Windows NT / 2000 / XP), o seguinte comando é freqüentemente usado:

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

Programas de propósito especial para converter arquivos entre diferentes convenções de nova linha incluem unix2dos e dos2unix, mac2unix e unix2mac, mac2dos e dos2mac e flip. O comando tr está disponível em praticamente todos os sistemas semelhantes ao Unix e pode ser usado para realizar operações de substituição arbitrárias em caracteres únicos. Um arquivo de texto DOS / Windows pode ser convertido para o formato Unix simplesmente removendo todos os caracteres ASCII CR com

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

ou, se o texto tiver apenas novas linhas CR, convertendo todas as novas linhas CR para LF com

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

As mesmas tarefas às vezes são realizadas com awk, sed ou em Perl se a plataforma tiver um interpretador Perl:

O comando de arquivo pode identificar o tipo de fim de linha:

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

O comando Unix egrep (grep estendido) pode ser usado para imprimir nomes de arquivos Unix ou DOS (assumindo somente arquivos estilo DOS e Unix, sem 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)

Outras ferramentas permitem ao usuário visualizar os caracteres EOL:

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