Quando uso la costante PHP “PHP_EOL”?

Quando è una buona idea usare PHP_EOL?

A volte vedo questo negli esempi di codice di PHP. Questo gestisce i problemi di endline DOS / Mac / Unix?

Sì, PHP_EOLè apparentemente utilizzato per trovare il carattere di nuova riga in modo compatibile con più piattaforme, quindi gestisce i problemi DOS / Unix.

Si noti che PHP_EOL rappresenta il carattere di fine linea per il sistema corrente . Ad esempio, non troverà un endline di Windows quando eseguito su un sistema simile a unix.

Da main/php.hdi PHP versione 7.1.1 e versione 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

Come puoi vedere PHP_EOLpuò essere "\r\n"(su server Windows) o "\n"(su qualsiasi altra cosa). Nelle versioni PHP precedenti alla 5.4.0RC8, era possibile un terzo valore perPHP_EOL : "\r"(sui server MacOSX). Era errato ed è stato corretto il 01-03-2012 con il bug 61193 .

Come altri hanno già detto, è possibile utilizzare PHP_EOLin qualsiasi tipo di output (dove uno di questi valori è valido, ad esempio HTML, XML, log ...) in cui si desidera creare nuove righe unificate . Tieni presente che è il server a determinare il valore, non il client. I tuoi visitatori Windows otterranno il valore dal tuo server Unix che a volte è scomodo per loro.

Volevo solo mostrare i possibili valori PHP_EOLsupportati dalle fonti PHP poiché non è stato ancora mostrato qui ...

Usi PHP_EOLquando vuoi una nuova linea e vuoi essere multipiattaforma.

Questo può accadere quando si scrivono file nel filesystem (registri, esportazioni, altro).

Potresti usarlo se vuoi che il tuo HTML generato sia leggibile. Quindi potresti seguire il tuo <br />con aPHP_EOL .

Lo useresti se stai eseguendo php come script da cron e hai bisogno di produrre qualcosa e di formattarlo per uno schermo.

È possibile utilizzarlo se si sta creando un messaggio di posta elettronica per l'invio che richiede una formattazione.

PHP_EOL (stringa) Il simbolo "Fine linea" corretto per questa piattaforma. Disponibile da PHP 4.3.10 e PHP 5.0.2

Puoi usare questa costante quando leggi o scrivi file di testo sul filesystem del server.

Le terminazioni di linea non contano nella maggior parte dei casi poiché la maggior parte dei software è in grado di gestire file di testo indipendentemente dalla loro origine. Dovresti essere coerente con il tuo codice.

Se le terminazioni di riga sono importanti, specifica esplicitamente le terminazioni di riga anziché utilizzare la costante. Per esempio:

• Le intestazioni HTTP devono essere separate da\r\n
• I file CSV devono essere usati \r\ncome separatori di riga

Vorrei inserire una risposta che si rivolge "Quando no usarlo" in quanto non è stato ancora coperto e posso immaginare che venga usato alla cieca e nessuno nota che c'è un problema fino a tardi. Parte di ciò contraddice in parte alcune delle risposte esistenti.

Se stai inviando a una pagina web in HTML, in particolare il testo in <textarea>, <pre>o <code>probabilmente vuoi sempre usarlo \ne non PHP_EOL.

La ragione di ciò è che mentre il codice può funzionare bene su un server - che sembra essere una piattaforma simile a Unix - se distribuito su un host Windows (come la piattaforma Windows Azure), può alterare la modalità di visualizzazione delle pagine in alcuni browser (in particolare Internet Explorer: alcune versioni vedranno sia \ n che \ r).

Non sono sicuro se questo sia ancora un problema dopo IE6 o no, quindi potrebbe essere piuttosto discutibile ma sembra degno di nota se aiuta le persone a spingere a pensare al contesto. Potrebbero esserci altri casi (come l'XHTML rigoroso) in cui si presenta di colpo\r alcune piattaforme potrebbe causare problemi con l'output, e sono sicuro che ci sono altri casi limite come quello.

Come già notato da qualcuno, non vorrai utilizzarlo quando restituisci le intestazioni HTTP, poiché dovrebbero sempre seguire la RFC su qualsiasi piattaforma.

Non lo userei per qualcosa come delimitatori sui file CSV (come qualcuno ha suggerito). La piattaforma su cui è in esecuzione il server non dovrebbe determinare le terminazioni di riga nei file generati o consumati.

Ho trovato PHP_EOL molto utile per la gestione dei file, specialmente se stai scrivendo più righe di contenuto in un file.

Ad esempio, hai una lunga stringa che vuoi dividere in più righe mentre scrivi in ​​un file semplice. L'uso di \ r \ n potrebbe non funzionare, quindi inserisci PHP_EOL nello script e il risultato è fantastico.

Dai un'occhiata a questo semplice esempio di seguito:

<?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 non gestisce i problemi di endline, perché il sistema in cui si utilizza quella costante non è lo stesso sistema a cui si invia l'output.

Non consiglierei affatto di usare PHP_EOL. Unix / Linux usa \ n, anche MacOS / OS X è cambiato da \ r a \ n e su Windows molte applicazioni (specialmente i browser) possono visualizzarlo correttamente. Su Windows, è anche facile cambiare il codice lato client esistente per usare solo \ n e mantenere comunque la retrocompatibilità: basta cambiare il delimitatore per il taglio della linea da \ r \ n a \ n e avvolgerlo in una funzione simile a trim () .

La definizione di PHP_EOL è che ti dà il carattere newline del sistema operativo su cui stai lavorando.

In pratica, non dovresti quasi mai aver bisogno di questo. Considera alcuni casi:

• Quando esci sul web, non c'è davvero alcuna convenzione se non che dovresti essere coerente. Poiché la maggior parte dei server sono Unixy, ti consigliamo comunque di utilizzare un "\ n".

• Se stai inviando un file, PHP_EOL potrebbe sembrare una buona idea. Tuttavia, puoi ottenere un effetto simile avendo una nuova riga letterale all'interno del tuo file, e questo ti aiuterà se stai cercando di eseguire alcuni file formattati CRLF su Unix senza ostruire le nuove linee esistenti (come un ragazzo con un sistema a doppio avvio , Posso dire che preferisco quest'ultimo comportamento)

PHP_EOL è così ridicolmente lungo che non vale davvero la pena usarlo.

C'è un posto ovvio in cui potrebbe essere utile: quando scrivi un codice che usa prevalentemente stringhe di virgolette singole. È discutibile se:

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

La sua arte deve essere coerente. Il problema con il mix and matching '' e "" è che quando ottieni stringhe lunghe, non vuoi davvero andare a caccia per quale tipo di citazione hai usato.

Come per tutte le cose della vita, dipende dal contesto.

"Newline" standard DOS / Windows è CRLF (= \ r \ n) e non LFCR (\ n \ r). Se mettiamo quest'ultimo, è probabile che produca comportamenti inaspettati (beh, in effetti, un po 'attesi!: D).

Oggi quasi tutti i programmi (ben scritti) accettano lo standard UNIX LF (\ n) per il codice newline, anche i demoni del mittente della posta (RFC imposta CRLF come newline per le intestazioni e il corpo del messaggio).

Comodo con error_log () se stai emettendo più righe.

Ho trovato molte dichiarazioni di debug sembrare strane sulla mia installazione di Windows poiché gli sviluppatori hanno assunto terminazioni unix quando hanno rotto le stringhe.

Uso la costante PHP_EOL in alcuni script da riga di comando che ho dovuto scrivere. Sviluppo sul mio computer Windows locale e test su un server Linux. L'uso della costante significava che non dovevo preoccuparmi di usare il finale di linea corretto per ciascuna delle diverse piattaforme.

Ho un sito in cui uno script di registrazione scrive una nuova riga di testo in un file di testo dopo un'azione dell'utente, che può utilizzare qualsiasi sistema operativo.

L'uso di PHP_EOL non sembra essere ottimale in questo caso. Se l'utente è su Mac OS e scrive nel file di testo, inserirà \ n. Quando si apre il file di testo su un computer Windows non mostra un'interruzione di riga. Per questo motivo uso "\ r \ n" invece che funziona quando si apre il file su qualsiasi sistema operativo.

Stai scrivendo codice che utilizza prevalentemente stringhe a virgoletta singola.

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

Sto usando WebCalendar e ho scoperto che Mac iCal barfora sull'importazione di un file ics generato perché la fine della riga è codificata in xcal.php come "\ r \ n". Sono entrato e ho sostituito tutte le occorrenze con PHP_EOL e ora iCal è felice! L'ho anche provato su Vista e Outlook è stato in grado di importare anche il file, anche se il carattere di fine riga è "\ n".

Quando jumi (plugin joomla per PHP) compila il tuo codice per qualche motivo rimuove tutte le barre rovesciate dal tuo codice. Tale che qualcosa del genere$csv_output .= "\n"; diventa$csv_output .= "n";

Bug molto fastidioso!

Utilizza invece PHP_EOL per ottenere il risultato che stavi cercando.

Su alcuni sistemi può essere utile usare questa costante perché se, ad esempio, stai inviando un'e-mail, puoi usare PHP_EOL per avere uno script tra sistemi che funzioni su più sistemi ... ma anche se è utile a volte puoi trovare questo l'hosting costante indefinito e moderno con l'ultimo motore php non presenta questo problema ma penso che una cosa positiva sia scrivere un codice bit che salvi questa situazione:

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

Quindi puoi usare PHP_EOL senza problemi ... ovvio che PHP_EOL dovrebbe essere usato su uno script che dovrebbe funzionare su più sistemi contemporaneamente, altrimenti puoi usare \ n oppure \ r oppure \ r \ n ...

Nota: PHP_EOL può essere

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

Spero che questa risposta aiuti.

Ho appena riscontrato questo problema durante l'output su un client Windows. Certo, PHP_EOL è per lato server, ma la maggior parte dell'output di contenuto da php è per client Windows. Quindi devo mettere i miei risultati qui per la prossima persona.

A) echo "My Text". PHP_EOL; // Cattivo perché genera solo \ n e la maggior parte delle versioni del blocco note di Windows lo visualizza su una sola riga e la maggior parte dei software di contabilità di Windows non può importare questo tipo di carattere di fine riga.

B) echo "Testo personale \ r \ n"; // Cattivo perché le stringhe php a virgoletta singola non interpretano \ r \ n

C) echo "Testo personale \ r \ n"; // Yay funziona! Sembra corretto nel blocco note e funziona durante l'importazione del file in altri software Windows come Windows Accounting e Windows Manufacturing Software.

Preferisco usare \ n \ r. Anche io sono su un sistema Windows e \ n funziona bene nella mia esperienza.

Dal momento che PHP_EOL non funziona con le espressioni regolari e questi sono il modo più utile di trattare il testo, allora non l'ho mai usato o ne avevo bisogno.