Nova linha - Newline

Nova linha inserida entre as palavras "Hello" e "world"

Nova linha (frequentemente chamado de fim de linha , de fim de linha ( EOL ), próxima linha ( NEL ) ou quebra de linha ) é um caracter de controlo ou sequência de caracteres de controlo em uma codificação de caracteres especificação (por exemplo, ASCII , EBCDIC ) que é usado para significar o fim de uma linha de texto e o início de uma nova, por exemplo, Line Feed ( LF ) no Unix . Alguns editores de texto definem este caractere especial ao pressionar a tecla. Enter

Ao exibir (ou imprimir) um arquivo de texto , este caractere de controle ou seqüência de caracteres faz com que o editor de texto mostre os caracteres seguintes em uma nova linha.

História

Em meados de 1800, muito antes do advento das teleimpressoras e máquinas de teletipo, os operadores de código Morse ou telegrafistas inventaram e usaram prosigns em código Morse para codificar a formatação de texto em espaço em branco em mensagens de texto escritas formais. Em particular o Morse prosign BT (mnemonic b reak t ext) representado pela concatenação de caracteres textuais de códigos Morse literais "B" e "T" enviados sem o espaçamento normal entre caracteres é usado em código Morse para codificar e indicar uma nova linha ou nova seção em uma mensagem de texto formal.

Mais tarde, na era das teleimpressoras modernas , códigos de controle de conjunto de caracteres padronizados foram desenvolvidos para auxiliar na formatação de texto em espaço em branco. O ASCII foi desenvolvido simultaneamente pela International Organization for Standardization (ISO) e pela American Standards Association (ASA), sendo esta última a organização predecessora do American National Standards Institute (ANSI). Durante o período de 1963 a 1968, os rascunhos de padrões ISO apoiavam o uso de CR + LF ou LF sozinho como uma nova linha, enquanto os rascunhos ASA suportavam apenas CR + LF .

A sequência CR + LF era comumente usada em muitos dos primeiros sistemas de computador que adotaram máquinas Teletype - normalmente um Teletype Model 33 ASR - como um dispositivo de console, porque essa sequência era necessária para posicionar essas impressoras no início de uma nova linha. A separação de nova linha em duas funções ocultava o fato de que a cabeça de impressão não podia retornar da extrema direita para o início da próxima linha a tempo de imprimir o próximo caractere. Qualquer caractere impresso após um CR geralmente seria impresso como uma mancha no meio da página, enquanto a cabeça de impressão ainda estava movendo o carro de volta para a primeira posição. "A solução foi transformar a nova linha em dois caracteres: CR para mover o carro para a coluna um e LF para mover o papel para cima." Na verdade, muitas vezes era necessário enviar caracteres extras - CRs ou NULs estranhos - que eram ignorados, mas davam ao cabeçote de impressão tempo para se mover para a margem esquerda. Muitas exibições de vídeo anteriores também exigiam várias vezes de caracteres para rolar a exibição.

Nesses sistemas, os aplicativos precisavam se comunicar diretamente com a máquina do teletipo e seguir suas convenções, uma vez que o conceito de drivers de dispositivo ocultando esses detalhes de hardware do aplicativo ainda não estava bem desenvolvido. Portanto, o texto era rotineiramente composto para satisfazer as necessidades das máquinas teletipo. A maioria dos sistemas de minicomputador da DEC usava essa convenção. CP / M também o utilizou para imprimir nos mesmos terminais que os minicomputadores usavam. A partir daí, o MS-DOS (1981) adotou o CR + LF da CP / M para ser compatível, e essa convenção foi herdada pelo sistema operacional Windows posterior da Microsoft .

O sistema operacional Multics começou a ser desenvolvido em 1964 e usou o LF sozinho como sua nova linha. Multics usava um driver de dispositivo para traduzir esse caractere para qualquer sequência necessária para uma impressora (incluindo caracteres de preenchimento extras), e o byte único era mais conveniente para programação. O que parece ser uma escolha mais óbvia - CR - não foi usada, pois CR fornecia a função útil de sobrepor uma linha com outra para criar efeitos de negrito e tachado . Talvez mais importante, o uso de LF sozinho como um terminador de linha já havia sido incorporado aos rascunhos do eventual padrão ISO / IEC 646 . O Unix seguiu a prática do Multics e, mais tarde, sistemas semelhantes ao Unix seguiram o Unix. Isso criou conflitos entre o Windows e os sistemas operacionais semelhantes ao Unix , por meio dos quais os arquivos compostos em um sistema operacional não podem ser formatados ou interpretados adequadamente por outro sistema operacional (por exemplo, um script de shell do UNIX escrito em um editor de texto do Windows como o Bloco de Notas ).

Representação

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 projeto 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 CRe LFcombinada em uma (comumente chamada de CR+LFou CRLF).

Alguns 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".

Aplicativos de software e representação do sistema operacional de uma nova linha com um ou dois caracteres de controle
Sistema operacional Codificação de caracteres Abreviação valor hexadecimal valor dec Sequência de fuga
Unix e sistemas semelhantes ao Unix ( Linux , macOS , FreeBSD , AIX , Xenix , etc.), Multics , BeOS , Amiga , RISC OS e outros ASCII LF 0A 10 \ n
Microsoft Windows , DOS ( MS-DOS , PC DOS , etc.), Atari TOS , DEC TOPS-10 , RT-11 , CP / M , MP / M , OS / 2 , Symbian OS , Palm OS , Amstrad CPC e a maioria dos outros primeiros sistemas operacionais não Unix e não IBM CR LF 0D 0A 13 10 \ r \ n
Máquinas Commodore de 8 bits ( C64 , C128 ), Acorn BBC , ZX Spectrum , TRS-80 , série Apple II , Oberon , o clássico Mac OS , MIT Lisp Machine e OS-9 CR 0D 13 \ r
Implementação QNX pré-POSIX (versão <4) RS 1E 30 \ 036
Saída de texto em spool Acorn BBC e RISC OS LF CR 0A 0D 10 13 \ n \ r
Máquinas Atari 8 bits ATASCII 9B 155
Sistemas de mainframe IBM , incluindo z / OS ( OS / 390 ) e IBM i ( OS / 400 ) EBCDIC NL 15 21 \ 025
ZX80 e ZX81 (computadores domésticos da Sinclair Research Ltd ) usou um conjunto de caracteres não ASCII específico NOVA LINHA 76 118
  • Sistemas EBCDIC - principalmente sistemas de mainframe IBM , incluindo z / OS ( OS / 390 ) e IBM i ( OS / 400 ) - usam NL (Nova Linha, 0x15 ) como o caractere que combina as funções de avanço de linha e retorno de carro. 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 de 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 da 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 poderiam 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 (uma vez 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 CR LF ou LF ou mesmo CR era o terminador de linha, não podiam substituir algum outro código.
  • O comprimento fixo da linha era usado por alguns dos primeiros sistemas operacionais de mainframe . 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, #portanto, não podia ser usado como o primeiro caractere em uma linha. Algumas impressoras antigas interpretavam esses caracteres diretamente nos registros enviados a elas.

Unicode

O padrão Unicode define vários caracteres que os aplicativos em conformidade devem reconhecer como terminadores de linha:

  LF :   Alimentação de linha, U + 000A
 VT : Guia vertical , U + 000B   
 FF : Form Feed , 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 muito 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.

Por exemplo: NL faz parte do EBCDIC , que usa o código 0x15 ; ele é normalmente mapeado para Unicode NEL , 0x85 , 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 que a transformação de ida e volta preservem informações, ao mesmo tempo em que permite que os aplicativos reconheçam todos os tipos possíveis de terminadores de linha.

Reconhecer e usar 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 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 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 .

Observe bem que os caracteres especiais Unicode U + 2424 ( SÍMBOLO PARA NEWLINE , ), U + 23CE ( SÍMBOLO DE RETORNO , ), U + 240D ( SÍMBOLO PARA RETORNO DE CARRO , ) e U + 240A ( SÍMBOLO PARA ALIMENTAÇÃO DE LINHA , ) são glifos pretendidos por apresentar um caractere visível pelo usuário ao leitor do documento e, portanto, não são reconhecidos como uma nova linha.

Sequências de escape

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

Sequências de escape
Caractere especial Sequência de fuga Usado por ... Exemplos
line feed \ n Perl , Vim , ... Vim: :%s/}/}\r\t/g= substitua cada caractere '}' por '} tabulador de nova linha' em todo o arquivo
carriage return \ r
tabulator \ t

Em linguagens de programação

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

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 gravar em 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 do 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 é executada e a representação interna produzida por '\ n' é emitida 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 seus softwares em sistemas Unix simplesmente ignorassem a distinção completamente, resultando em código que não é portátil para plataformas diferentes.

A função de biblioteca C fgets () deve ser evitada no modo binário porque qualquer arquivo não escrito com a convenção de nova linha do Unix será mal interpretado. Além disso, no modo de texto, qualquer arquivo não escrito com a sequê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. Gravar '\ n' em um fluxo de modo de texto funciona corretamente em sistemas Windows, mas produz apenas LF no Unix, e algo completamente diferente em sistemas mais exóticos. Usar "\ r \ n" no modo binário é um pouco melhor.

Muitas linguagens, como C ++ , Perl e Haskell fornecem a mesma interpretação de '\ n' que C. C ++ tem um modelo de E / S alternativo onde o manipulador std :: endl pode ser usado para produzir uma nova linha (e liberar o fluxo amortecedor).

Java , PHP e Python fornecem a sequência '\ r \ n' (para ASCII CR + LF ). Em contraste com C, eles representam os valores U + 000D e U + 000A , respectivamente.

As bibliotecas de E / S Java não as traduzem de forma transparente em sequências de nova linha dependentes da plataforma na 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, ao 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 , 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

Um arquivo de texto criado com gedit e visualizado com um editor hexadecimal . Além dos objetos de texto, existem apenas marcadores EOL com o valor hexadecimal 0A.

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 line feed, cujo valor hexadecimal em ASCII é 0a, enquanto a maioria dos programas comuns em MS-DOS e Microsoft Windows usam carriage return+ line feed, 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.

O texto em arquivos criados com programas que são comuns no sistema operacional Unix ou Mac OS clássico , aparecem como uma única linha longa na maioria dos programas comuns no MS-DOS e no Microsoft Windows porque eles não exibem uma única linha line feedou uma única carriage returnquebra 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, outros programas que não 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 que um programa suporte convenções de nova linha diferentes, 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 - geralmente 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 recomenda que aplicativos tolerantes reconheçam LF solitário ( '\ n' , 0x0A ) também. 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 correio qmail , que se recusa ativamente a aceitar mensagens de sistemas que enviam LF vazio em vez do CR + LF necessário .

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

O File Transfer Protocol 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 geralmente 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, deve-se usar o modo binário, pois nenhum arquivo será alterado pelo FTP, embora possa ser exibido incorretamente.

Conversão entre formatos de nova linha

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 do Windows Notepad. Dentro do vim

 :set fileformat=dos
 :wq

Os editores podem ser inadequados para a conversão de arquivos maiores ou para a 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

Os 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 do tipo 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 em 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:

$ awk '{sub("$","\r\n"); printf("%s",$0);}' inputfile > outputfile  # UNIX to DOS  (adding CRs on Linux and BSD based OS that haven't GNU extensions)
$ awk '{gsub("\r",""); print;}' inputfile > outputfile              # DOS to UNIX  (removing CRs on Linux and BSD based OS that haven't GNU extensions)
$ sed -e 's/$/\r/' inputfile > outputfile              # UNIX to DOS  (adding CRs on Linux based OS that use GNU extensions)
$ sed -e 's/\r$//' inputfile > outputfile              # DOS  to UNIX (removing CRs on Linux based OS that use GNU extensions)
$ perl -pe 's/\r?\n|\r/\r\n/g' inputfile > outputfile  # Convert to DOS
$ perl -pe 's/\r?\n|\r/\n/g'   inputfile > outputfile  # Convert to UNIX
$ perl -pe 's/\r?\n|\r/\r/g'   inputfile > outputfile  # Convert to old Mac

O comando file pode identificar o tipo de terminações de linha:

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

O comando Unix egrep (extended grep) pode ser usado para imprimir nomes de arquivos Unix ou DOS (assumindo somente arquivos no 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

Interpretação

Duas maneiras de visualizar novas linhas, ambas autoconsistentes , são que as novas linhas separam as linhas ou terminam as linhas. Se uma nova linha for considerada um separador, não haverá nenhuma nova linha após a última linha de um arquivo. Alguns programas têm problemas para processar a última linha de um arquivo se ele não for encerrado por uma nova linha. Por outro lado, os programas que esperam que uma nova linha seja usada como separador interpretarão uma nova linha final como o início de uma nova linha (vazia). Por outro lado, se uma nova linha é considerada um terminador, espera-se que todas as linhas de texto, incluindo a última, sejam encerradas por uma nova linha. Se a sequência de caracteres final em um arquivo de texto não for uma nova linha, a linha final do arquivo pode ser considerada uma linha de texto imprópria ou incompleta, ou o arquivo pode ser considerado truncado incorretamente.

Em textos destinados principalmente a serem lidos por humanos usando um software que implementa o recurso de quebra de linha, um caractere de nova linha normalmente só precisa ser armazenado se uma quebra de linha for necessária, independentemente de a próxima palavra caber na mesma linha, como entre parágrafos e em listas verticais. Portanto, na lógica do processamento de texto e da maioria dos editores de texto , a nova linha é usada como uma quebra de parágrafo e é conhecida como "hard return", em contraste com "soft return" que são criados dinamicamente para implementar a quebra de linha e são alteráveis ​​com cada instância de exibição. Em muitos aplicativos, existe um caractere de controle separado denominado "quebra de linha manual" para forçar quebras de linha dentro de um único parágrafo. O glifo para o caractere de controle para um retorno rígido geralmente é um pilcrow (¶), e para a quebra de linha manual geralmente é uma seta de retorno de carro (↵).

Avanços de linha reversos e parciais

RI , ( U + 008D REVERSE LINE FEED, ISO / IEC 6429 8D, decimal 141) é usado para mover a posição de impressão para trás uma linha (invertendo a alimentação do papel ou movendo um cursor de exibição uma linha para cima) para que outros caracteres pode ser impresso sobre o texto existente. Isso pode ser feito para torná-los mais ousados ​​ou para adicionar sublinhados, tachados ou outros caracteres, como sinais diacríticos .

Da mesma forma, PLD ( U + 008B PARTIAL LINE FORWARD, decimal 139) e PLU ( U + 008C PARTIAL LINE BACKWARD, decimal 140) podem ser usados ​​para avançar ou reverter a posição de impressão de texto por alguma fração do espaçamento de linha vertical (normalmente, metade ) Eles podem ser usados ​​em combinação para subscritos (avançando e revertendo) e sobrescritos (revertendo e avançando) e também podem ser úteis para imprimir diacríticos.

Veja também

Referências

links externos