Quando uso a constante PHP "PHP_EOL"?


360

Quando é uma boa ideia usar PHP_EOL?

Às vezes, vejo isso em exemplos de código do PHP. Isso lida com problemas de linha de extremidade do DOS / Mac / Unix?


11
Eu acho que há muitos conselhos enganosos nas respostas votadas nesta página. Se você executar um script em duas plataformas diferentes, comparar a saída ou os dados gerados (arquivos de log, página html, registros do banco de dados etc.), o PHP_EOL resultará em uma incompatibilidade no diff. Na maioria dos casos, não é isso que você deseja.
Donquixote 15/0318

Respostas:


357

Sim, PHP_EOLé ostensivamente usado para encontrar o caractere de nova linha de maneira compatível com várias plataformas, para lidar com problemas de DOS / Unix.

Observe que PHP_EOL representa o caractere final do sistema atual . Por exemplo, ele não encontrará uma linha final do Windows quando executada em um sistema semelhante ao Unix.


9
Deve ser usado como o caractere da linha final ao escrever um script de linha de comando?
Thomas Owens

5
@ André: Que tal alguém que escreve aplicativos para serem instalados, usados ​​e implantados por outros? Você está sugerindo que todos eles deveriam limitar suas "plataformas suportadas" a * nix?
Cilíndrico

11
@Stann - O que os "grandes projetos" que você conhece fazem dificilmente são o fator decisivo nas melhores práticas, e muito menos o que é ou não útil. Eu mantenho um "grande projeto" que é implantado em parte em vários hosts, incluindo alguns servidores Windows. Não assuma - as constantes não prejudicam nada e são uma maneira perfeitamente válida de escrever código neutro em plataforma. Seus comentários em contrário são um tanto absurdos.
Chris Baker

5
Não, não acho que sua resposta esteja correta. Você gera código em um sistema, mas envia a saída para outro sistema. PHP_EOL, no entanto, informa o delimitador de final de linha SOMENTE para o sistema em que é usado. Não garante que o outro sistema use o mesmo delimitador. Veja minha resposta abaixo.
StanE 23/08/2015

11
mas não use PHP_EOLpara dados postados no formulário.
Nabi KAZ

88

Do main/php.hPHP versão 7.1.1 e versão 5.6.30:

#ifdef PHP_WIN32
#   include "tsrm_win32.h"
#   include "win95nt.h"
#   ifdef PHP_EXPORTS
#       define PHPAPI __declspec(dllexport)
#   else
#       define PHPAPI __declspec(dllimport)
#   endif
#   define PHP_DIR_SEPARATOR '\\'
#   define PHP_EOL "\r\n"
#else
#   if defined(__GNUC__) && __GNUC__ >= 4
#       define PHPAPI __attribute__ ((visibility("default")))
#   else
#       define PHPAPI
#   endif
#   define THREAD_LS
#   define PHP_DIR_SEPARATOR '/'
#   define PHP_EOL "\n"
#endif

Como você pode ver, PHP_EOLpode ser "\r\n"(nos servidores Windows) ou "\n"(em qualquer outra coisa). Nas versões PHP anteriores à 5.4.0RC8, havia um terceiro valor possível para PHP_EOL: "\r"(nos servidores MacOSX). Ele estava errado e foi corrigido em 01/03/2012 com o bug 61193 .

Como outros já disseram, você pode usar PHP_EOLem qualquer tipo de saída (onde qualquer um desses valores é válido - como: HTML, XML, logs ...) onde você deseja novas linhas unificadas . Lembre-se de que é o servidor que determina o valor, não o cliente. Os visitantes do Windows obterão o valor do servidor Unix, o que é inconveniente para eles algumas vezes.

Eu só queria mostrar os possíveis valores de PHP_EOLbackup pelas fontes PHP, uma vez que ainda não foi mostrado aqui ...


3
Uau. Os desenvolvedores do PHP estão errados sobre isso. Como o link da Wikipedia que você menciona, o Mac OS 9 e antes usava "\ r", mas não o OS X, que usa "\ n". Alguém deve registrar um relatório de erro ...
imgx64

27
@ imgx64 Sim, talvez, mas honestamente, você já viu um servidor MAC de produção?
precisa saber é

3
@ imgx64 Foi corrigido 33 dias após a sua postagem :) Atualizei minha resposta para refletir as fontes atuais.
AlexV #

2
Eu não acho que o argumento para usar PHP_EOL para saída (!) Seja válido. PHP_EOL é do lado do servidor, enquanto a saída é normalmente para o cliente (que usa delimitadores de final de linha diferentes). Exemplo: Se você criar uma saída de texto simples com várias linhas em um sistema Linux com PHP_EOL e enviá-la para um sistema Windows, não será um delimitador de final de linha válido - dependerá do software cliente que exibirá a saída. Navegadores e alguns editores de texto podem lidar com isso, mas se você visualizar o texto, por exemplo, no Bloco de Notas, tudo ficará em uma linha.
StanE 23/08/15

php -r "echo addcslashes(PHP_EOL, PHP_EOL), PHP_EOL;"descobrir.
Bob Stein

82

Você usa PHP_EOLquando deseja uma nova linha e deseja ser multiplataforma.

Pode ser quando você está gravando arquivos no sistema de arquivos (logs, exportações, outros).

Você pode usá-lo se quiser que o HTML gerado seja legível. Então você pode seguir o seu <br />com um PHP_EOL.

Você o usaria se estiver executando o php como um script do cron e precisar produzir algo e formatá-lo para uma tela.

Você pode usá-lo se estiver criando um email para enviar que necessite de alguma formatação.


25
Você não precisa usar novas linhas independentes de plataforma ao gerar HTML.
21420 Rob

6
@ Rob, se versões mais antigas do IE me dessem um visualizador de fonte de página melhor, então o bloco de notas do Windows poderia ter concordado com você.
precisa saber é o seguinte

14
@Zoredache - o HTML será gerado com novas linhas apropriadas para a plataforma em que o PHP está sendo executado, não necessariamente apropriado para a plataforma da qual você está acessando as páginas.
Dominic Rodger

2
1 para mencionar prédio e-mail $header = "From: $from" . PHP_EOL; $header .= "Reply-To: $from" . PHP_EOL; $header .= "Return-Path: $from" . PHP_EOL;
Jakob Cosoroaba

49
PHP_EOLnão deve ser usado para separar cabeçalhos de email. De acordo com o manual do PHP Mail , vários cabeçalhos extras devem ser separados com um CRLF (\ r \ n).
Halil Özgür

19

PHP_EOL (string) O símbolo 'End Of Line' correto para esta plataforma. Disponível desde PHP 4.3.10 e PHP 5.0.2

Você pode usar essa constante ao ler ou gravar arquivos de texto no sistema de arquivos do servidor.

As terminações de linha não importam na maioria dos casos, pois a maioria dos softwares é capaz de lidar com arquivos de texto, independentemente de sua origem. Você deve ser consistente com o seu código.

Se as terminações de linha importarem, especifique explicitamente as terminações de linha em vez de usar a constante. Por exemplo:

  • Cabeçalhos HTTP devem ser separados por\r\n
  • Arquivos CSV devem usar \r\ncomo separador de linhas

5
fonte para "cabeçalhos HTTP deve ser ...": ietf.org/rfc/rfc2616.txt capítulo 4 secção 1
Adrian Foder

2
SMTP linhas de mensagem deve ser denunciado por\r\n
Bob Stein

12

Eu gostaria de dar uma resposta que aborda "Quando não usá-lo", pois ainda não foi abordada e posso imaginar que ela seja usada às cegas e que ninguém perceba a existência de um problema até mais tarde. Parte disso contradiz algumas das respostas existentes.

Se estiver imprimindo em uma página da Web em HTML, principalmente em texto <textarea>, <pre>ou <code>você provavelmente sempre desejará usar \ne não PHP_EOL.

A razão para isso é que, embora o código funcione bem em um servidor - que é uma plataforma semelhante ao Unix - se implantado em um host do Windows (como a plataforma Windows Azure), isso pode alterar a maneira como as páginas são exibidas em alguns navegadores. (especificamente Internet Explorer - algumas versões exibem \ n e \ r).

Não tenho certeza se isso ainda é um problema desde o IE6 ou não, por isso pode ser bastante discutível, mas parece valer a pena mencionar se ajuda as pessoas a pensarem sobre o contexto. Pode haver outros casos (como XHTML estrito) em que a saída repentina de \ralgumas plataformas pode causar problemas com a saída, e tenho certeza de que existem outros casos extremos como esse.

Como já foi observado por alguém, você não gostaria de usá-lo ao retornar cabeçalhos HTTP - pois eles sempre devem seguir o RFC em qualquer plataforma.

Eu não o usaria para algo como delimitadores em arquivos CSV (como alguém sugeriu). A plataforma em que o servidor está executando não deve determinar as terminações da linha nos arquivos gerados ou consumidos.


10

Achei o PHP_EOL muito útil para manipulação de arquivos, especialmente se você estiver escrevendo várias linhas de conteúdo em um arquivo.

Por exemplo, você tem uma sequência longa que deseja quebrar nas várias linhas enquanto escreve em um arquivo simples. Usar \ r \ n pode não funcionar, basta colocar PHP_EOL no seu script e o resultado é incrível.

Confira este exemplo simples abaixo:

<?php

$output = 'This is line 1' . PHP_EOL .
          'This is line 2' . PHP_EOL .
          'This is line 3';

$file = "filename.txt";

if (is_writable($file)) {
    // In our example we're opening $file in append mode.
    // The file pointer is at the bottom of the file hence
    // that's where $output will go when we fwrite() it.
    if (!$handle = fopen($file, 'a')) {
         echo "Cannot open file ($file)";
         exit;
    }
    // Write $output to our opened file.
    if (fwrite($handle, $output) === FALSE) {
        echo "Cannot write to file ($file)";
        exit;
    }
    echo "Success, content ($output) wrote to file ($file)";
    fclose($handle);
} else {
    echo "The file $file is not writable";
}
?>

3
\ n \ r nunca vai funcionar como a seqüência é feito para ser \ r \ n </ pedantismo>
frak

10

Não, o PHP_EOL não lida com problemas de linha final, porque o sistema em que você usa essa constante não é o mesmo sistema para o qual você envia a saída.

Eu não recomendaria o uso do PHP_EOL. Uso do Unix / Linux \ n, MacOS / OS X alterado de \ r para \ n também e no Windows muitos aplicativos (especialmente navegadores) também podem exibi-lo corretamente. No Windows, também é fácil alterar o código existente do lado do cliente para usar apenas \ n e ainda manter a compatibilidade com versões anteriores: basta alterar o delimitador para o corte de linha de \ r \ n para \ n e envolvê-lo em uma função do tipo trim () .


3
Seria bom saber por que minha resposta foi negada ... Louca ... A resposta aceita está errada , enquanto a minha está correta. Geralmente não é correto dizer que o PHP_EOL lida com o problema. Pode (e deve) ser usado se estiver lendo ou escrevendo ÚNICO algo de / para o mesmo sistema. Mas na maioria das vezes o PHP é usado para enviar algo de volta ao cliente (o que é mais provável do que o questionador pensou). Novamente: PHP_EOL é uma constante pura do lado do servidor. NÃO (e não pode) lidar com quebras de linha do lado do cliente corretamente. Por favor, escreva um comentário e me diga, se você acha que escrevi algo errado.
StanE 10/07/16

3
+1 por fazer um bom argumento contra o grão. Acho que está perdido porque os navegadores não processam espaços em branco em html, então o uso comum seria para aplicativos de console. E, como você disse, nesse caso, o final da linha seria interpretado para o ambiente de execução, o que faz sentido para aplicativos de console, mas não para aplicativos da Web cliente-servidor.
22616 Jeff Puckett

Bem, a resposta realmente não se relaciona. Você menciona a compatibilidade do navegador e o envio de arquivos para outros sistemas. A nova linha é relevante na saída de texto, portanto, os navegadores não são relevantes. E, ao contrário do seu ponto principal, esses arquivos de texto geralmente são consumidos na mesma plataforma em que estão gravados.
Concessão #

6

A definição do PHP_EOL é que ele fornece o caractere de nova linha do sistema operacional em que você está trabalhando.

Na prática, você quase nunca precisa disso. Considere alguns casos:

  • Quando você está enviando para a web, não há realmente nenhuma convenção, exceto que você deve ser consistente. Como a maioria dos servidores é Unixy, você deseja usar um "\ n" de qualquer maneira.

  • Se você estiver produzindo para um arquivo, o PHP_EOL pode parecer uma boa ideia. No entanto, você pode obter um efeito semelhante ao ter uma nova linha literal dentro do seu arquivo, e isso o ajudará se você estiver tentando executar alguns arquivos formatados em CRLF no Unix sem prejudicar as novas linhas existentes (como alguém com um sistema de inicialização dupla) , Posso dizer que prefiro o último comportamento)

O PHP_EOL é tão ridiculamente longo que não vale a pena usá-lo.


33
-1 para "PHP_EOL é tão ridiculamente longo". Não é um argumento válido.
viam0Zah

11
Eu concordo completamente com você. Não há sentido algum em implantar o php em nada além do * nix. Assim - não faz sentido usar PHP_EOL ou DIRECTORY_SEPARATOR.
Stann

@Stann Você pode explicar seu ponto de vista sobre "Não há sentido algum em implantar php em nada além de * nix"?
Sajuuk

2
@ Sarauuk Eu acredito que seria chamado de "sarcasmo".
Félix Gagnon-Grenier

3

Há um lugar óbvio em que isso pode ser útil: quando você está escrevendo um código que usa predominantemente seqüências de aspas simples. É discutível se:

echo 'A $variable_literal that I have'.PHP_EOL.'looks better than'.PHP_EOL;  
echo 'this other $one'."\n";

A arte disso é ser consistente. O problema com mix e correspondência '' e "" é que, quando você obtém sequências longas, não precisa realmente procurar o tipo de citação que usou.

Como em todas as coisas da vida, depende do contexto.


3

A "nova linha" padrão do DOS / Windows é CRLF (= \ r \ n) e não LFCR (\ n \ r). Se colocarmos o último, é provável que produza alguns comportamentos inesperados (bem, de fato, meio que esperados!: D).

Atualmente, quase todos os programas (bem escritos) aceitam o LF padrão UNIX (\ n) para código de nova linha, até mesmo daemons de remetentes de correio (RFC define CRLF como nova linha para cabeçalhos e corpo da mensagem).


2

Prático com error_log () se você estiver produzindo várias linhas.

Eu descobri que muitas instruções de depuração parecem estranhas na minha instalação do Windows, já que os desenvolvedores assumiram finais unix ao dividir as strings.


2

Eu uso a constante PHP_EOL em alguns scripts de linha de comando que tive que escrever. Eu desenvolvo na minha máquina Windows local e testo em uma caixa de servidor Linux. Usar a constante significava que não precisava me preocupar em usar a linha correta para cada uma das plataformas.


2

Eu tenho um site onde um script de log grava uma nova linha de texto em um arquivo de texto após uma ação do usuário, que pode estar usando qualquer sistema operacional.

O uso do PHP_EOL não parece ideal neste caso. Se o usuário estiver no Mac OS e gravar no arquivo de texto, ele colocará \ n. Ao abrir o arquivo de texto em um computador Windows, ele não mostra uma quebra de linha. Por esse motivo, utilizo "\ r \ n", que funciona ao abrir o arquivo em qualquer sistema operacional.


1

Você está escrevendo um código que usa predominantemente seqüências de aspas simples.

echo 'A $variable_literal that I have'.PHP_EOL.'looks better than'.PHP_EOL;  
echo 'this other $one'."\n";

0

Estou usando o WebCalendar e constatei que o Mac iCal vomita na importação de um arquivo ics gerado porque o final de linha é codificado no xcal.php como "\ r \ n". Entrei e substituí todas as ocorrências por PHP_EOL e agora o iCal está feliz! Também testei no Vista e o Outlook também conseguiu importar o arquivo, mesmo que o caractere de fim de linha seja "\ n".


<late> Isso significa que seu aplicativo não funcionará corretamente quando for implantado em um servidor Windows. Se você quiser \n, use isso explicitamente.
duskwuff -inactive-

0

Quando o jumi (plugin do joomla para PHP) compila seu código por algum motivo, ele remove todas as barras invertidas do seu código. Tais que algo como $csv_output .= "\n";se torna$csv_output .= "n";

Bug muito chato!

Use PHP_EOL para obter o resultado desejado.


2
Eu realmente espero que este seja um problema de configuração que você ainda não encontrou. eu não usei o joomla, mas que comportamento horrível se é assim que funciona!
jon_darkstar

0

Em alguns sistemas, pode ser útil usar essa constante, porque se, por exemplo, você estiver enviando um email, poderá usar o PHP_EOL para que um script entre sistemas funcione em mais sistemas ... mas mesmo que seja útil em algum momento, você pode encontrar isso constante e indefinida, a hospedagem moderna com o mecanismo php mais recente não tem esse problema, mas acho que uma coisa boa é escrever um código de bit que salve essa situação:

<?php
  if (!defined('PHP_EOL')) {
    if (strtoupper(substr(PHP_OS,0,3) == 'WIN')) {
      define('PHP_EOL',"\r\n");
    } elseif (strtoupper(substr(PHP_OS,0,3) == 'MAC')) {
      define('PHP_EOL',"\r");
    } elseif (strtoupper(substr(PHP_OS,0,3) == 'DAR')) {
      define('PHP_EOL',"\n");
    } else {
      define('PHP_EOL',"\n");
    }
  }
?>

Então você pode usar o PHP_EOL sem problemas ... óbvio que o PHP_EOL deve ser usado em scripts que devem funcionar em mais sistemas ao mesmo tempo, caso contrário, você pode usar \ n ou \ r ou \ r \ n ...

Nota: PHP_EOL pode ser

1) on Unix    LN    == \n
2) on Mac     CR    == \r
3) on Windows CR+LN == \r\n

Espero que esta resposta ajude.


0

Acabei de experimentar esse problema ao enviar para um cliente Windows. Claro, o PHP_EOL é do lado do servidor, mas a maior parte do conteúdo do php é para clientes do Windows. Então eu tenho que colocar minhas descobertas aqui para a próxima pessoa.

A) ecoa 'Meu texto'. PHP_EOL; // Ruim, porque isso gera apenas \ n e a maioria das versões do bloco de notas do Windows exibe isso em uma única linha, e a maioria dos softwares de contabilidade do Windows não pode importar esse tipo de caractere de fim de linha.

B) eco 'Meu texto \ r \ n'; // Ruim, porque strings de aspas simples entre aspas não interpretam \ r \ n

C) echo "Meu texto \ r \ n"; // Sim, funciona! Parece correto no bloco de notas e funciona ao importar o arquivo para outros softwares do Windows, como o Windows Accounting e o Windows Manufacturing Software.


-2

Eu prefiro usar \ n \ r. Também estou em um sistema Windows e \ n funciona muito bem na minha experiência.

Como o PHP_EOL não funciona com expressões regulares, e essa é a maneira mais útil de lidar com texto, então eu realmente nunca o usei ou precisei.


12
Cuidado com a ordem de char da nova linha, ela deve ser \ r \ n (CR + LF): en.wikipedia.org/wiki/Newline #
azkotoki

Você não usá-lo, mas seu site pode ser aberto por qualquer um em qualquer PC por isso pode ser um problema
Owaiz Yusufi
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.