¿Cuándo uso la constante PHP "PHP_EOL"?


360

¿Cuándo es una buena idea usar PHP_EOL?

A veces veo esto en ejemplos de código de PHP. ¿Esto maneja problemas de línea final de DOS / Mac / Unix?


1
Creo que hay muchos consejos engañosos en las respuestas votadas en esta página. Si ejecuta un script en dos plataformas diferentes, luego compara la salida o los datos generados (archivos de registro, página html, registros de la base de datos, etc.), entonces PHP_EOL generará una discrepancia en la diferencia. En la mayoría de los casos, esto no es lo que quieres.
donquixote

Respuestas:


357

Sí, PHP_EOLaparentemente se usa para encontrar el carácter de nueva línea de una manera compatible con múltiples plataformas, por lo que maneja problemas de DOS / Unix.

Tenga en cuenta que PHP_EOL representa el carácter de línea final para el sistema actual . Por ejemplo, no encontrará una línea final de Windows cuando se ejecute en un sistema similar a Unix.


99
¿Debería usarse como carácter de línea final al escribir un script de línea de comandos?
Thomas Owens

55
@Andre: ¿Qué tal alguien que escribe aplicaciones para ser instaladas, usadas e implementadas por otros? ¿Está sugiriendo que todo esto debería limitar sus "plataformas compatibles" a * nix?
Cilíndrico

1
@Stann: lo que los "grandes proyectos" que conoces no es el factor decisivo sobre las mejores prácticas, y mucho menos lo que es útil o no. Mantengo un "gran proyecto" que se implementa en parte en varios hosts, incluidos algunos servidores de Windows. No asuma: las constantes no hacen daño a nada y son una forma perfectamente válida de escribir código neutral para la plataforma. Sus comentarios en sentido contrario son algo absurdos.
Chris Baker,

55
No, no creo que tu respuesta sea correcta. Genera código en un sistema pero envía la salida a otro sistema. PHP_EOL, sin embargo, le dice el delimitador de final de línea SOLO para el sistema donde se usa. No le garantiza que el otro sistema use el mismo delimitador. Vea mi respuesta a continuación.
StanE

1
pero no lo use PHP_EOLpara datos publicados desde el formulario.
Nabi KAZ

88

Desde main/php.hPHP versión 7.1.1 y versión 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 puede ver PHP_EOLpuede ser "\r\n"(en servidores Windows) o "\n"(en cualquier otra cosa). En las versiones de PHP anteriores a 5.4.0RC8, había un tercer valor posible para PHP_EOL: "\r"(en servidores MacOSX). Estaba mal y se ha solucionado el 01-03-2012 con el error 61193 .

Como otros ya le dijeron, puede usar PHP_EOLen cualquier tipo de salida (donde cualquiera de estos valores sean válidos, como: HTML, XML, registros ...) donde desee nuevas líneas unificadas . Tenga en cuenta que es el servidor el que determina el valor, no el cliente. Sus visitantes de Windows obtendrán el valor de su servidor Unix que a veces es inconveniente para ellos.

Solo quería mostrar los valores posibles de PHP_EOLrespaldado por las fuentes PHP ya que aún no se ha mostrado aquí ...


3
Guau. Los desarrolladores de PHP están equivocados sobre esto. Como se menciona en el enlace de Wikipedia, Mac OS 9 y antes usaban "\ r", pero no OS X, que usa "\ n". Alguien debería presentar un informe de error ...
imgx64

27
@ imgx64 Sí, tal vez, pero sinceramente, ¿alguna vez viste un servidor MAC de producción?
AlexV

3
@ imgx64 Se ha solucionado 33 días después de su publicación :) He actualizado mi respuesta para reflejar las fuentes actuales.
AlexV

2
No creo que el argumento para usar PHP_EOL para la salida (!) Sea válido. PHP_EOL es del lado del servidor, mientras que la salida es normalmente para el cliente (que utiliza diferentes delimitadores de final de línea). Ejemplo: si crea una salida de texto sin formato de varias líneas en un sistema Linux con PHP_EOL y la envía a un sistema Windows, no será un delimitador de final de línea válido; dependerá del software del cliente que muestre la salida. Los navegadores y algunos editores de texto pueden manejarlo, pero si ve el texto, por ejemplo, en el Bloc de notas, todo estará en una línea.
StanE

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

82

Usas PHP_EOLcuando quieres una nueva línea y quieres ser multiplataforma.

Esto podría ser cuando está escribiendo archivos en el sistema de archivos (registros, exportaciones, otros).

Puede usarlo si desea que su HTML generado sea legible. Entonces puedes seguir tu <br />con a PHP_EOL.

Lo usaría si está ejecutando php como un script de cron y necesita generar algo y tener un formato para una pantalla.

Puede usarlo si está creando un correo electrónico para enviar que necesita algún formato.


25
No necesita utilizar nuevas líneas independientes de la plataforma al generar HTML.
Rob

66
@Rob, si las versiones anteriores de IE me dieran un mejor visor de fuente de página que el bloc de notas de Windows, podría haber estado de acuerdo con usted.
Zoredache

14
@Zoredache: el HTML se generará con nuevas líneas apropiadas para la plataforma en la que se ejecuta PHP, no necesariamente apropiadas para la plataforma desde la que está accediendo a las páginas.
Dominic Rodger

2
+1 por mencionar la construcción de correos electrónicos $header = "From: $from" . PHP_EOL; $header .= "Reply-To: $from" . PHP_EOL; $header .= "Return-Path: $from" . PHP_EOL;
Jakob Cosoroaba

49
PHP_EOLno debe usarse para separar encabezados de correo electrónico. Según el manual de PHP Mail , varios encabezados adicionales deben separarse con un CRLF (\ r \ n).
Halil Özgür

19

PHP_EOL (cadena) El símbolo correcto 'Fin de línea' para esta plataforma. Disponible desde PHP 4.3.10 y PHP 5.0.2

Puede usar esta constante cuando lee o escribe archivos de texto en el sistema de archivos del servidor.

Los finales de línea no importan en la mayoría de los casos ya que la mayoría del software es capaz de manejar archivos de texto independientemente de su origen. Debes ser coherente con tu código.

Si las terminaciones de línea son importantes, especifique explícitamente las terminaciones de línea en lugar de usar la constante. Por ejemplo:

  • Los encabezados HTTP deben estar separados por\r\n
  • Los archivos CSV deben usarse \r\ncomo separador de filas

55
fuente de " Encabezados HTTP deben ser ...": ietf.org/rfc/rfc2616.txt capítulo 4 sección 1
Adrian Föder

2
Las líneas de mensajes SMTP deben terminar por\r\n
Bob Stein, el

12

Me gustaría agregar una respuesta que aborde "Cuándo no usarlo", ya que aún no se ha cubierto y puedo imaginar que se usa a ciegas y nadie se da cuenta de que hay un problema hasta más adelante. Algo de esto contradice algunas de las respuestas existentes.

Si sale a una página web en HTML, particularmente texto en <textarea>, <pre>o <code>probablemente siempre quiera usar \ny no PHP_EOL.

La razón de esto es que si bien el código puede funcionar bien en un servidor, que es una plataforma similar a Unix, si se implementa en un host de Windows (como la plataforma Windows Azure), puede alterar la forma en que se muestran las páginas en algunos navegadores (específicamente Internet Explorer, algunas versiones de las cuales verán tanto \ n como \ r).

No estoy seguro de si esto sigue siendo un problema desde IE6 o no, por lo que podría ser bastante discutible, pero parece digno de mencionar si ayuda a las personas a pensar en el contexto. Puede haber otros casos (como XHTML estricto) donde la salida repentina de \r's en algunas plataformas podría causar problemas con la salida, y estoy seguro de que hay otros casos extremos como ese.

Como ya señaló alguien, no querrá usarlo al devolver encabezados HTTP, ya que siempre deben seguir el RFC en cualquier plataforma.

No lo usaría para algo así como delimitadores en archivos CSV (como alguien ha sugerido). La plataforma en la que se ejecuta el servidor no debe determinar las terminaciones de línea en los archivos generados o consumidos.


10

PHP_EOL me pareció muy útil para el manejo de archivos, especialmente si está escribiendo varias líneas de contenido en un archivo.

Por ejemplo, tiene una cadena larga que desea dividir en varias líneas mientras escribe en un archivo sin formato. Usar \ r \ n podría no funcionar, así que simplemente coloque PHP_EOL en su script y el resultado será increíble.

Mira este sencillo ejemplo a continuación:

<?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 funcionará ya que la secuencia debe ser \ r \ n </pedantry>
frak

10

No, PHP_EOL no maneja los problemas finales, porque el sistema donde usa esa constante no es el mismo sistema al que envía la salida.

No recomendaría usar PHP_EOL en absoluto. El uso de Unix / Linux \ n, MacOS / OS X también cambió de \ r a \ n y en Windows muchas aplicaciones (especialmente los navegadores) también pueden mostrarlo correctamente. En Windows, también es fácil cambiar el código existente del lado del cliente para usar \ n solo y aún mantener la compatibilidad con versiones anteriores: simplemente cambie el delimitador para el recorte de línea de \ r \ n a \ n y envuélvalo en una función de corte () .


3
Sería bueno saber por qué mi respuesta es rechazada ... Loco ... La respuesta aceptada es incorrecta , mientras que la mía es correcta. En general, no es correcto decir que PHP_EOL maneja el problema. Puede (y debe) usarse si lee o escribe SOLO algo en / desde el mismo sistema. Pero la mayoría de las veces, PHP se usa para enviar algo al cliente (que es lo que probablemente pensó el interrogador). Nuevamente: PHP_EOL es una constante pura del lado del servidor. NO (y no puede) manejar saltos de línea del lado del cliente correctamente. Por favor escriba un comentario y dígame, si cree que escribí algo mal.
StanE

3
+1 por hacer un buen punto contra el grano. Creo que se perdió porque los navegadores no representan espacios en blanco en html, por lo que el uso común sería para aplicaciones de consola. Y como usted dijo, en ese caso, el final de línea se interpretaría para el entorno de ejecución, lo que tiene sentido para las aplicaciones de consola, pero no para las aplicaciones web cliente-servidor.
Jeff Puckett

Bueno, la respuesta realmente no se relaciona. Usted menciona la compatibilidad del navegador y el envío de archivos a otros sistemas. Newline es relevante en la salida de texto, por lo que los navegadores no son relevantes. Y al contrario de su punto principal, estos archivos de texto se consumen generalmente en la misma plataforma el que están escritas.
grantwparks

6

La definición de PHP_EOL es que le da el carácter de nueva línea del sistema operativo en el que está trabajando.

En la práctica, casi nunca debería necesitar esto. Considere algunos casos:

  • Cuando está enviando a la web, realmente no hay ninguna convención, excepto que debe ser coherente. Como la mayoría de los servidores son Unixy, de todas formas querrás usar un "\ n".

  • Si está enviando a un archivo, PHP_EOL puede parecer una buena idea. Sin embargo, puede obtener un efecto similar al tener una nueva línea literal dentro de su archivo, y esto lo ayudará si está tratando de ejecutar algunos archivos con formato CRLF en Unix sin bloquear las nuevas líneas existentes (como un tipo con un sistema de arranque dual) , Puedo decir que prefiero el último comportamiento)

PHP_EOL es tan ridículamente largo que realmente no vale la pena usarlo.


33
-1 para "PHP_EOL es tan ridículamente largo". No es un argumento válido.
viam0Zah

1
Estoy completamente de acuerdo contigo. No tiene ningún sentido desplegar php en otra cosa que no sea * nix. Por lo tanto, no tiene sentido usar PHP_EOL o DIRECTORY_SEPARATOR.
Stann

@Stann ¿Puedes explicar tu punto sobre "No tiene ningún sentido desplegar php en otra cosa que no sea * nix"?
Sajuuk

2
@Sajuuk Creo que eso se llamaría "sarcasmo".
Félix Gagnon-Grenier

3

Hay un lugar obvio donde podría ser útil: cuando está escribiendo código que usa predominantemente cadenas de comillas simples. Es discutible si:

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

El arte de esto es ser consistente. El problema con la combinación y combinación '' y "" es que cuando obtienes cadenas largas, realmente no quieres tener que buscar qué tipo de cotización utilizaste.

Como con todas las cosas en la vida, depende del contexto.


3

La "nueva línea" estándar de DOS / Windows es CRLF (= \ r \ n) y no LFCR (\ n \ r). Si ponemos lo último, es probable que produzca algunos comportamientos inesperados (bueno, de hecho, ¡algo esperado!: D).

Hoy en día, casi todos los programas (bien escritos) aceptan el estándar UNIX LF (\ n) para el código de nueva línea, incluso los demonios de remitentes de correo (RFC establece CRLF como nueva línea para encabezados y cuerpo de mensaje).


2

Práctico con error_log () si está generando varias líneas.

He encontrado que muchas declaraciones de depuración se ven raras en mi instalación de Windows ya que los desarrolladores han asumido terminaciones de Unix al dividir cadenas.


2

Utilizo la constante PHP_EOL en algunos scripts de línea de comandos que tuve que escribir. Desarrollo en mi máquina Windows local y luego pruebo en una caja de servidor Linux. Usar la constante significaba que no tenía que preocuparme por usar el final de línea correcto para cada una de las diferentes plataformas.


2

Tengo un sitio donde un script de registro escribe una nueva línea de texto en un archivo de texto después de una acción del usuario, que puede usar cualquier sistema operativo.

Usar PHP_EOL no parece ser óptimo en este caso. Si el usuario está en Mac OS y escribe en el archivo de texto, colocará \ n. Al abrir el archivo de texto en una computadora con Windows, no muestra un salto de línea. Por esta razón, uso "\ r \ n" en su lugar, que funciona al abrir el archivo en cualquier sistema operativo.


1

Está escribiendo código que utiliza predominantemente cadenas de comillas simples.

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

0

Estoy usando WebCalendar y descubrí que Mac iCal no acepta importar un archivo ics generado porque el final de la línea está codificado en xcal.php como "\ r \ n". Entré y reemplacé todas las ocurrencias con PHP_EOL y ahora iCal está feliz. También lo probé en Vista y Outlook también pudo importar el archivo, aunque el carácter de final de línea es "\ n".


<late> Eso significa que su aplicación funcionará mal cuando se implemente en un servidor Windows. Si quieres \n, úsalo explícitamente.
duskwuff -inactive-

0

Cuando jumi (plugin joomla para PHP) compila su código por alguna razón, elimina todas las barras invertidas de su código. Tal que algo así se $csv_output .= "\n";convierte$csv_output .= "n";

Muy molesto error!

Use PHP_EOL en su lugar para obtener el resultado que buscaba.


2
Realmente espero que este sea un problema de configuración que aún no haya encontrado. No he usado Joomla, pero ¡qué horrible comportamiento si así es como funciona!
jon_darkstar

0

En algunos sistemas puede ser útil usar esta constante porque si, por ejemplo, está enviando un correo electrónico, puede usar PHP_EOL para tener un script entre sistemas que funcione en más sistemas ... pero incluso si es útil en algún momento puede encontrar esto El alojamiento moderno indefinido constante con el último motor php no tiene este problema, pero creo que algo bueno es escribir un código de bit que salve esta situación:

<?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");
    }
  }
?>

Entonces puede usar PHP_EOL sin problemas ... obvio que PHP_EOL debe usarse en un script que debería funcionar en más sistemas a la vez, de lo contrario puede usar \ n o \ r o \ r \ n ...

Nota: PHP_EOL puede ser

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

Espero que esta respuesta ayude.


0

Acabo de experimentar este problema al enviar a un cliente de Windows. Claro, PHP_EOL es para el lado del servidor, pero la mayoría de la salida de contenido de php es para clientes de Windows. Así que tengo que colocar mis hallazgos aquí para la próxima persona.

A) echo 'Mi texto'. PHP_EOL; // Malo porque esto solo genera \ ny la mayoría de las versiones del bloc de notas de Windows muestran esto en una sola línea, y la mayoría del software de contabilidad de Windows no puede importar este tipo de caracteres de fin de línea.

B) echo 'Mi texto \ r \ n'; // Mal porque las cadenas php entre comillas simples no interpretan \ r \ n

C) echo "Mi texto \ r \ n"; // ¡Yay funciona! Parece correcto en el bloc de notas y funciona al importar el archivo a otro software de Windows, como el software de contabilidad y fabricación de Windows.


-2

Prefiero usar \ n \ r. También estoy en un sistema de Windows y \ n funciona bien en mi experiencia.

Dado que PHP_EOL no funciona con expresiones regulares, y estas son la forma más útil de tratar con el texto, entonces realmente nunca lo usé o necesité.


12
Tenga cuidado con el pedido de caracteres de nueva línea, debe ser \ r \ n (CR + LF): en.wikipedia.org/wiki/Newline
azkotoki

No lo usa, pero su sitio puede ser abierto por cualquiera en cualquier PC, por lo que puede ser un problema
Owaiz Yusufi
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.