CRLF não é mais usado e deve ser descontinuado

Definição de carriage return e line feed

• Carriage return (CR): move o cursor para a margem esquerda da mesma linha
• Line feed (LF): move o cursor uma linha para baixo e faz as linhas anteriores rolarem para cima
• Newline (NL): move o cursor uma linha para baixo e para a margem esquerda

Observações

• CR e NL são caracteres de controle úteis. NL é a operação mais comum, iniciando uma nova linha de texto na margem esquerda
• LF é, na prática, inútil. Ninguém quer descer para a próxima linha no meio da linha atual e continuar escrevendo na mesma coluna
• LF tem origem na era dos teletipos mecânicos de cerca de 70 anos atrás

Contexto histórico

• Teletipos imprimiam cerca de 5 caracteres por segundo
• A tradição de CRLF surgiu das limitações mecânicas dos teletipos nos anos 1950
• Na era do Multix e Unix, espalhou-se a percepção de que usar CRLF para NL era ineficiente

Situação moderna

• Hoje, CR é representado como U+000d, e LF e NL como U+000a
• A maioria das máquinas modernas usa U+000a apenas como NL
• Alguns protocolos ainda exigem CRLF, mas a maior parte do software aceita um único NL

Chamada à ação

• Renomear o code point U+000a de "line feed" para "newline"
• Parar de transmitir CR desnecessariamente
• Enviar apenas NL para protocolos que exigem CRLF
• Corrigir softwares que geram erro ao receber NL sem CR

Resumo e autor

• O fim do CRLF já é necessário há muito tempo. Devemos trabalhar juntos para eliminar essa relíquia ultrapassada
• Autor: D. Richard Hipp, criador do SQLite

# Resumo do GN⁺

• Este texto explica o contexto histórico do CRLF e sua ineficiência moderna, defendendo sua descontinuação
• CRLF é uma tradição originada em limitações mecânicas que hoje causa complexidade desnecessária
• Este tema pode ser especialmente útil para programadores e desenvolvedores de software, sendo importante para uma transmissão de dados eficiente
• Mesmo ao usar outros protocolos ou sistemas com funções semelhantes, é preciso reconsiderar a necessidade do CRLF

[cosine20]

Às vezes eu uso feed de linha....

[doolayer]

Bem radical, hein rs

[savvykang]

Segundo a atualização de 14 de outubro, dizem que a proposta de mudança será retirada.

Não é algo que se resolva simplesmente mudando um único sistema; é um trabalho que exige alterar gradualmente o protocolo e todos os sistemas afetados, então, na minha visão, o autor parece não ter sido cauteloso o suficiente.

[constexprif]

Será que acharam que o benefício de acabar com isso é maior do que o custo de eliminá-lo?

[alstjr7375]

CR+LF tem uma longa história...

• https://www.revk.uk/2022/02/crlf-has-long-history.html

Ah.. então é por isso..

[bakyeono]

O CRLF não é uma especificação mal definida, e sim algo que refletia o ambiente de hardware da época...
Parece que estão esquecendo a retrocompatibilidade e pensando apenas neste momento.
Será que precisamos refazer os protocolos sempre que as especificações de hardware mudarem?

[halfenif]

Não sou nem a favor nem contra acabar com isso.

Por que será que isso me fez lembrar do bug do milênio?

[GN⁺]

Comentário no Hacker News

• Atualizar protocolos existentes para usar NL pode introduzir bugs em potencial, e o HTTP/1.1 já foi substituído pelo HTTP/2
  • Argumenta-se que faz sentido não exigir CRLF em protocolos novos, mas que não há necessidade de atualizar os protocolos existentes
• Não seguir o CRLF é como introduzir bugs de propósito
  • O servidor HTTP do SQLite foi atualizado para usar \n em vez de \r\n, mas isso quebrou a compatibilidade com o cliente HTTP do Zig
• Há quem defenda que o CRLF deve ser eliminado para que as gerações futuras não precisem se preocupar com isso
  • Afirma-se que devemos ensinar a usar o arquivo .gitattribute e educar as pessoas a não gostarem do Byte Order Mark
• A escolha não padronizada de final de linha do Unix foi um erro, e isso causou décadas de problemas de compatibilidade
  • CRLF são duas partes diferentes da API de terminal, e muitos programas dependem do funcionamento correto de CR e LF
• CRLF é um dos elementos menos importantes do padrão
  • Quebrar o padrão é uma tentativa nova e, pessoalmente, uma postura estranha
• O SMTP deixa claro que a sequência de término da mensagem é CR LF . CR LF, e também existem implementações que reconhecem LF . LF
  • As regras originais do SMTP talvez não sejam mais importantes hoje
• O CRLF pode representar riscos para muitos dispositivos, e as exceções deveriam ser reduzidas
• Não há menção aos problemas que surgem quando finais de linha são misturados
  • O caractere NL não existe, e a tecla "ENTER" de todos os teclados envia CR
  • A forma atual está funcionando bem