que - php_eol tab

¿Cuándo uso la constante de PHP “PHP_EOL”?

Question

¿Cuándo es una buena idea usar PHP_EOL ?

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

Answer 1

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

Puede usar esta constante cuando lea o escriba 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 consistente con tu código.

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

• Los encabezados HTTP deben estar separados por /r/n
• Los archivos CSV deben usar /r/n como separador de fila

Answer 2

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

¡Insecto muy molesto!

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

Answer 3

Desde main/php.h de PHP versión 5.6.30 y versión 7.1.1:

#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_EOL puede 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). Fue incorrecto y se ha corregido el 2012-03-01 con el error 61193 .

Como ya te han dicho otros, puedes usar PHP_EOL en cualquier tipo de salida (donde cualquiera de estos valores son válidos, como HTML, XML, registros ...) donde quieras newlines unificadas (y deberías querer esto en mi opinión) .

Solo quería mostrar los valores posibles de PHP_EOL respaldados por las fuentes PHP ya que todavía no se ha mostrado aquí ...

Answer 4

Encontré PHP_EOL 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 simple. El uso de / r / n podría no funcionar, así que simplemente ponga PHP_EOL en su script y el resultado es increíble.

Echa un vistazo a 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";
}
?>

Answer 5

Es útil con error_log () si está generando varias líneas.

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

Answer 6

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

Answer 7

Estoy usando WebCalendar y encontré que Mac iCal barfs al importar un archivo ics generado porque el final de 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, a pesar de que el carácter de final de línea es "/ n".

Answer 8

Hay un lugar obvio donde podría ser útil: cuando escribe un código que utiliza 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 ello es ser consistente. El problema de mezclar y combinar "y" es que cuando obtienes cadenas largas, realmente no quieres tener que buscar el tipo de cita que usaste.

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

Answer 9

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

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

Answer 10

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ías necesitar esto. Considere algunos casos:

• Cuando se 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, querrá usar un "/ n" de todos modos.

• 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á intentando ejecutar algunos archivos con formato CRLF en Unix sin obstruir 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.

Answer 11

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

Si se envía a una página web en HTML, especialmente el texto en <textarea> , <pre> o <code> es probable que siempre quiera usar /n y 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 la / n como la / r).

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

Como ya lo 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 como delimitadores en archivos CSV (como alguien ha sugerido). La plataforma en la que se ejecuta el servidor no debe determinar los finales de línea en los archivos generados o consumidos.

Answer 12

No, PHP_EOL no maneja los problemas de la línea final, porque el sistema donde usas esa constante no es el mismo sistema al que envías la salida.

No recomendaría usar PHP_EOL en absoluto. Unix / Linux usa / 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 solo / ny aún mantener la compatibilidad con versiones anteriores: simplemente cambie el delimitador para el recorte de líneas de / r / n a / n y envuélvalo en una función similar a recortar () .

Answer 13

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 esta es la forma más útil de tratar con texto, entonces realmente nunca lo usé ni lo necesité.

Answer 14

Sí, PHP_EOL se usa aparentemente para encontrar el carácter de nueva línea de una manera compatible con varias plataformas, por lo que maneja los problemas de DOS / Unix.

Tenga en cuenta que PHP_EOL representa el carácter de la 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.

Answer 15

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 estar usando 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, pondrá / 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 lugar de hacerlo cuando se abre el archivo en cualquier sistema operativo.

Answer 16

Utiliza PHP_EOL cuando quiere una nueva línea, y quiere ser multiplataforma.

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

Podrías usarlo si quieres que tu HTML generado sea legible. Así que puedes seguir tu <br /> con un PHP_EOL .

Lo usaría si está ejecutando php como una secuencia de comandos de cron y necesita generar algo y formatearlo para una pantalla.

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

Answer 17

Utilizo la constante PHP_EOL en algunos scripts de línea de comandos que tuve que escribir. Me desarrollo en mi máquina Windows local y luego la pruebo en un 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.