Revisão das 23h22min de 22 de agosto de 2013 editar Lord Mota (discussão \| contribs) Autorrevisores 48 280 edições Conforme PE ← Ver a alteração anterior		Revisão das 17h25min de 3 de setembro de 2013 editar desfazer Albmont (discussão \| contribs) 59 781 edições Para facilitar quem for fazer a fusão: removendo tudo que não tem fontes Ver a alteração posterior →
Linha 1: {{apagar4\|20 de agosto}} {{fusão de\|Line Feed}} A linguagem de programação [[Java (linguagem de programação)\|Java]] ~~também~~ define as seqüências de escape <tt>'\n'</tt> e o <tt>'\r'</tt>. ~~Ao contrário do C, elas~~Elas são sempre representadas por <tt>0x0A</tt> e <tt>0x0D</tt>, respectivamente. Isto significa que um <tt>'\n'</tt> 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.<ref>veja [http://java.sun.com/j2se/1.5.0/docs/api/java/io/BufferedReader.html#readLine() BufferedReader.readLine()]</ref>▼ 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 (informática)\|plataforma]] para plataforma de hardware e [[sistema operacional\|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 (computador)\|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á [[programa de computador\|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 [[line feed\|LF]] é frequentemente chamado de nova linha. Ele é interpretado como a instrução que tem o mesmo efeito que um [[Carriage return\|CR]]-LF teria numa [[impressora]].~~ ~~Os programas e [[sistema operacional\|sistemas operacionais]] podem representar uma nova linha como um ou dois [[caractere de controle\|caracteres de controle]]:~~ * No [[ASCII]] e outros conjuntos de caracteres compatíveis usam um <tt>LF</tt> (<tt>[[hexadecimal\|0x]]0A</tt>) ou um <tt>CR</tt> (<tt>0x0D</tt>) individualmente, ou <tt>CR</tt> seguido por <tt>LF</tt> (<tt>CR</tt>+<tt>LF</tt>, <tt>0x0D 0x0A</tt>); veja adiante a razão histórica da convenção <tt>CR</tt>+<tt>LF</tt>. <tt>LF</tt>:<tt>   </tt> [[Unix]], [[Linux]], [[AIX]], [[Xenix]], [[Mac OS X]], [[BeOS]], [[Amiga]], [[RISC OS]] e outros. <tt>CR</tt>+<tt>LF</tt>: [[CP/M]], [[MP/M]], [[DOS]], [[OS/2]], [[Microsoft Windows]] ** <tt>CR</tt>:<tt>   </tt> 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 <tt>[[next line\|NEL]]</tt> (<tt>0x15</tt>) como sendo o caractere para nova linha. Entretanto, o EBCDIC também possui caracteres chamados <tt>CR</tt> e <tt>LF</tt>, 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 <!-- Veja http://www.unicode.org/versions/Unicode4.0.0/ch05.pdf --> * <tt> LF</tt>:<tt>   </tt> [[Line Feed]], <tt>U+000A</tt> * <tt> CR</tt>:<tt>   </tt> [[Carriage return]], <tt>U+000D</tt> * <tt> CR</tt>+<tt>LF</tt>: <tt>CR</tt> seguido por <tt>LF</tt>, <tt>U+000D</tt> seguido por <tt>U+000A</tt> <tt> NEL</tt>:<tt>  </tt> Next Line, <tt>U+0085</tt> * <tt> FF</tt>:<tt>   </tt> Form Feed, <tt>U+000C</tt> * <tt> LS</tt>:<tt>   </tt> Line Separator, <tt>U+2028</tt> * <tt> PS</tt>:<tt>   </tt> Paragraph Separator, <tt>U+2029</tt> ~~== Histórico ==~~ O padrão [[ASCII]] foi desenvolvido simultaneamente pela [[International Organization for Standardization\|ISO]] e pela [[American Standards Association\|ASA]]. A seqüência <tt>CR</tt>+<tt>LF</tt> 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 sidpositivo\|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 <tt>CR</tt> vinha em primeiro lugar. Na verdade, muitas vezes era necessário acrescentar ainda um terceiro caractere: <tt>CR</tt>+<tt>LF</tt>+<tt>NUL</tt> (onde NUL significa “não faça nada”) ou <tt>CR</tt>+<tt>CR</tt>+<tt>LF</tt> (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 [[portabilidade\|portáveis]], as [[linguagem de programação\|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üência de escape\|seqüências de escape]] <tt>'\n'</tt> (''newline'') e <tt>'\r'</tt> (''carriage return''). Ao contrário do que muitos pensam, eles não são — em geral — equivalentes aos caracteres de controle ASCII <tt>LF</tt> e <tt>CR</tt>. O padrão C garante apenas duas coisas: ~~# Estas seqüências de escape são armazenadas no computador como apenas um caractere <tt>char</tt>.~~ # Ao criar um arquivo em “modo texto”, <tt>'\n'</tt> 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 (linguagem de programação)\|Java]] também define as seqüências de escape <tt>'\n'</tt> e o <tt>'\r'</tt>. Ao contrário do C, elas são sempre representadas por <tt>0x0A</tt> e <tt>0x0D</tt>, respectivamente. Isto significa que um <tt>'\n'</tt> 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.<ref>veja [http://java.sun.com/j2se/1.5.0/docs/api/java/io/BufferedReader.html#readLine() BufferedReader.readLine()]</ref> ~~== 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 [[Microsoft Windows\|Windows]]. Analogamente, um arquivo do Windows visto no Unix terá seus <tt>CR</tt> mostrados como um <tt>^M</tt> 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 <tt>CR</tt> e <tt>LF</tt>, permitindo ao usuário converter entre os diferentes padrões. Em geral, os [[navegador]]es também são capazes de fazê-lo. O [[File Transfer Protocol\|FTP]] converte automaticamente as quebras de linha de arquivos transferidos entre [[Sistema operacional\|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 <tt>CR</tt>/<tt>LF</tt>. Infelizmente isto não vale para o editor padrão do [[Microsoft Windows\|Windows]] [[bloco de notas]], mas vale para o [[Wordpad]]. No [[Unix]], os comandos <tt>dos2unix</tt> e <tt>unix2dos</tt> podem ser usados para converter entre o ASCII <tt>CR</tt>+<tt>LF</tt> (DOS/Windows) e o <tt>LF</tt> (Unix) — embora a sintaxe deste comando possa variar. ~~== Exemplos ==~~ ~~Detectar e substituir caracteres de quebra de linha em C:~~ ~~<source lang="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 /~~ } ~~</source>~~ {{Referências\|Notas}} == ~~Referências~~Ligações externas == The Unicode Reference, parágrafo 5.8 do [http://www.unicode.org/versions/Unicode4.0.0/ch05.pdf Capítulo 5] do Unicode 4.0 * {{Link\|\|2=http://www.rfc-editor.org/EOLstory.txt \|3=The End-of-Line Story}}

Nova linha: diferenças entre revisões