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

¿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?

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.

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í ...

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.

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

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.

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

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 () .

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.

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.

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).

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.

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.

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.

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";

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

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.

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.

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.

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é.