Wann verwende ich die PHP-Konstante "PHP_EOL"?

360

Wann ist es eine gute Idee zu verwenden PHP_EOL?

Ich sehe dies manchmal in Codebeispielen von PHP. Behandelt dies DOS / Mac / Unix-Endline-Probleme?

Christian Oudard
quelle
1
Ich denke, in den positiv bewerteten Antworten auf dieser Seite gibt es viele irreführende Ratschläge. Wenn Sie ein Skript auf zwei verschiedenen Plattformen ausführen und dann die Ausgabe oder die generierten Daten (Protokolldateien, HTML-Seite, Datenbankeinträge usw.) vergleichen, führt PHP_EOL zu einer Nichtübereinstimmung im Diff. In den meisten Fällen ist dies nicht das, was Sie wollen.
Donquijote

Antworten:

357

Ja, PHP_EOLwird angeblich verwendet, um das Zeilenumbruchzeichen plattformübergreifend zu finden, sodass DOS / Unix-Probleme behandelt werden.

Beachten Sie, dass PHP_EOL das Endzeilenzeichen für das aktuelle System darstellt. Beispielsweise wird keine Windows-Endzeile gefunden, wenn sie auf einem Unix-ähnlichen System ausgeführt wird.

Adam Bellaire
quelle
9
Sollte es beim Schreiben eines Befehlszeilenskripts als Endzeilenzeichen verwendet werden?
Thomas Owens
5
@Andre: Wie wäre es mit jemandem, der Apps schreibt, die von anderen installiert, verwendet und bereitgestellt werden sollen? Schlagen Sie vor, dass diese alle ihre "unterstützten Plattformen" auf * nix beschränken sollten?
Cylindric
1
@Stann - Was die "großen Projekte", über die Sie wissen, tun, ist kaum der entscheidende Faktor für bewährte Verfahren, geschweige denn, was nützlich ist oder nicht. Ich pflege ein "großes Projekt", das teilweise auf mehreren Hosts bereitgestellt wird, einschließlich einiger Windows-Server. Nehmen Sie nicht an - die Konstanten schaden nichts und sind eine absolut gültige Methode, um plattformneutralen Code zu schreiben. Ihre gegenteiligen Kommentare sind etwas absurd.
Chris Baker
5
Nein, ich glaube nicht, dass Ihre Antwort richtig ist. Sie generieren Code auf einem System, senden die Ausgabe jedoch an ein anderes System. PHP_EOL teilt Ihnen jedoch NUR das Zeilenende-Trennzeichen für das System mit, auf dem es verwendet wird. Es garantiert Ihnen nicht, dass das andere System dasselbe Trennzeichen verwendet. Siehe meine Antwort unten.
StanE
1
aber nicht PHP_EOLfür Daten verwenden, die aus dem Formular gesendet werden.
Nabi KAZ
88

Ab main/php.hPHP Version 7.1.1 und Version 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

Wie Sie sehen PHP_EOLkönnen, kann "\r\n"(auf Windows-Servern) oder "\n"(auf irgendetwas anderem) sein. In PHP-Versionen vor 5.4.0RC8 war ein dritter Wert möglich für PHP_EOL: "\r"(auf MacOSX-Servern). Es war falsch und wurde am 2012-03-01 mit Fehler 61193 behoben .

Wie andere Ihnen bereits gesagt haben, können Sie PHP_EOLin jeder Art von Ausgabe (wo einer dieser Werte gültig ist - wie z. B. HTML, XML, Protokolle ...) einheitliche Zeilenumbrüche verwenden . Denken Sie daran, dass es der Server ist, der den Wert bestimmt, nicht der Client. Ihre Windows-Besucher erhalten den Wert von Ihrem Unix-Server, was für sie manchmal unpraktisch ist.

Ich wollte nur die möglichen Werte von PHP_EOLPHP-Quellen zeigen, da diese hier noch nicht gezeigt wurden ...

AlexV
quelle
3
Beeindruckend. Die PHP-Entwickler liegen einfach falsch. Als Wikipedia-Link erwähnen Sie, dass Mac OS 9 und früher "\ r" verwendet haben, nicht jedoch OS X, das "\ n" verwendet. Jemand sollte einen Fehlerbericht
einreichen
27
@ imgx64 Ja vielleicht, aber ehrlich gesagt hast du jemals einen Produktions-MAC-Server gesehen?
AlexV
3
@ imgx64 Es wurde 33 Tage nach deinem Beitrag behoben :) Ich habe meine Antwort aktualisiert, um aktuelle Quellen wiederzugeben.
AlexV
2
Ich denke nicht, dass das Argument, PHP_EOL für die Ausgabe (!) Zu verwenden, gültig ist. PHP_EOL ist serverseitig, während die Ausgabe normalerweise für den Client erfolgt (der verschiedene Trennzeichen für Zeilenende verwendet). Beispiel: Wenn Sie mit PHP_EOL eine mehrzeilige Nur-Text-Ausgabe auf einem Linux-System erstellen und an ein Windows-System senden, ist dies kein gültiges Trennzeichen für das Zeilenende. Dies hängt davon ab, welche Client-Software die Ausgabe anzeigt. Browser und einige Texteditoren können damit umgehen, aber wenn Sie den Text beispielsweise im Editor anzeigen, wird alles in einer Zeile angezeigt.
StanE
php -r "echo addcslashes(PHP_EOL, PHP_EOL), PHP_EOL;"herausfinden.
Bob Stein
82

Sie verwenden, PHP_EOLwenn Sie eine neue Leitung möchten und plattformübergreifend sein möchten.

Dies kann der Fall sein, wenn Sie Dateien in das Dateisystem schreiben (Protokolle, Exporte usw.).

Sie können es verwenden, wenn Ihr generiertes HTML lesbar sein soll. So könnten Sie Ihrem <br />mit einem folgen PHP_EOL.

Sie würden es verwenden, wenn Sie PHP als Skript von Cron ausführen und etwas ausgeben und es für einen Bildschirm formatieren müssen.

Sie können es verwenden, wenn Sie eine E-Mail zum Senden erstellen, für die eine Formatierung erforderlich ist.

Zoredache
quelle
25
Sie müssen beim Generieren von HTML keine plattformunabhängigen Zeilenumbrüche verwenden.
Rob
6
@Rob, Wenn ältere Versionen von IE mir einen besseren Seitenquellen-Viewer als Windows Notepad gegeben hätten, hätte ich Ihnen vielleicht zugestimmt.
Zoredache
14
@Zoredache - Der HTML-Code wird mit Zeilenumbrüchen generiert, die für die Plattform geeignet sind, auf der PHP ausgeführt wird, und nicht unbedingt für die Plattform, von der aus Sie auf Seiten zugreifen.
Dominic Rodger
2
+1 für die Erwähnung des E-Mail-Aufbaus $header = "From: $from" . PHP_EOL; $header .= "Reply-To: $from" . PHP_EOL; $header .= "Return-Path: $from" . PHP_EOL;
Jakob Cosoroaba
49
PHP_EOLsollte nicht zum Trennen von E-Mail-Headern verwendet werden. Laut PHP Mail- Handbuch sollten mehrere zusätzliche Header mit einer CRLF (\ r \ n) getrennt werden.
Halil Özgür
19

PHP_EOL (Zeichenfolge) Das richtige Symbol für das Zeilenende für diese Plattform. Verfügbar seit PHP 4.3.10 und PHP 5.0.2

Sie können diese Konstante verwenden, wenn Sie Textdateien im Dateisystem des Servers lesen oder schreiben.

Zeilenenden spielen in den meisten Fällen keine Rolle, da die meisten Programme Textdateien unabhängig von ihrer Herkunft verarbeiten können. Sie sollten mit Ihrem Code übereinstimmen.

Wenn Zeilenenden wichtig sind, geben Sie die Zeilenenden explizit an, anstatt die Konstante zu verwenden. Zum Beispiel:

  • HTTP-Header müssen durch getrennt werden\r\n
  • CSV - Dateien sollten verwenden \r\nals Zeilentrenn
Salman A.
quelle
5
Quelle für "HTTP-Header müssen sein ...": ietf.org/rfc/rfc2616.txt Kapitel 4 Abschnitt 1
Adrian Föder
2
SMTP - Nachrichtenzeilen müssen durch beendet werden\r\n
Bob Stein
12

Ich möchte eine Antwort einwerfen, die sich mit "Wann nicht verwenden" befasst, da sie noch nicht behandelt wurde, und ich kann mir vorstellen, dass sie blind verwendet wird und niemand bemerkt, dass es bis später ein Problem gibt. Einige davon widersprechen einigen der vorhandenen Antworten etwas.

Wenn Sie auf einer Webseite in HTML ausgeben, insbesondere in Text <textarea>, <pre>oder <code>wenn Sie wahrscheinlich immer verwenden möchten \nund nicht PHP_EOL.

Der Grund dafür ist, dass Code zwar auf einem Server - der zufällig eine Unix-ähnliche Plattform ist - gut funktioniert, wenn er jedoch auf einem Windows-Host (z. B. der Windows Azure-Plattform) bereitgestellt wird, die Darstellung von Seiten in einigen Browsern möglicherweise ändert (speziell Internet Explorer - in einigen Versionen werden sowohl \ n als auch \ r angezeigt).

Ich bin mir nicht sicher, ob dies seit IE6 immer noch ein Problem ist oder nicht, daher ist es vielleicht ziemlich umstritten, aber es scheint erwähnenswert zu sein, wenn es den Leuten hilft, über den Kontext nachzudenken. Es kann andere Fälle geben (wie z. B. striktes XHTML), in denen eine plötzliche Ausgabe \rauf einigen Plattformen Probleme mit der Ausgabe verursachen kann, und ich bin sicher, dass es andere Randfälle wie diesen gibt.

Wie bereits von jemandem bemerkt, möchten Sie es nicht verwenden, wenn Sie HTTP-Header zurückgeben, da diese auf jeder Plattform immer dem RFC folgen sollten.

Ich würde es nicht für Trennzeichen in CSV-Dateien verwenden (wie jemand vorgeschlagen hat). Die Plattform, auf der der Server ausgeführt wird, sollte die Zeilenenden in generierten oder konsumierten Dateien nicht bestimmen.

Iain Collins
quelle
10

Ich fand PHP_EOL sehr nützlich für die Dateiverwaltung, insbesondere wenn Sie mehrere Inhaltszeilen in eine Datei schreiben.

Beispielsweise haben Sie eine lange Zeichenfolge, die Sie beim Schreiben in eine einfache Datei in mehrere Zeilen aufteilen möchten. Die Verwendung von \ r \ n funktioniert möglicherweise nicht. Fügen Sie einfach PHP_EOL in Ihr Skript ein, und das Ergebnis ist fantastisch.

Schauen Sie sich dieses einfache Beispiel unten an:

<?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";
}
?>
IP Bastola
quelle
3
\ n \ r wird nie funktionieren, da die Sequenz \ r \ n </ pedantry> sein soll
frak
10

Nein, PHP_EOL behandelt keine Endline-Probleme, da das System, an das Sie diese Konstante verwenden, nicht dasselbe System ist, an das Sie die Ausgabe senden.

Ich würde die Verwendung von PHP_EOL überhaupt nicht empfehlen. Unix / Linux verwenden \ n, MacOS / OS X wurde ebenfalls von \ r nach \ n geändert und unter Windows können viele Anwendungen (insbesondere Browser) es auch korrekt anzeigen. Unter Windows ist es auch einfach, vorhandenen clientseitigen Code so zu ändern, dass er nur \ n verwendet und dennoch die Abwärtskompatibilität beibehält: Ändern Sie einfach das Trennzeichen für das Trimmen von Zeilen von \ r \ n in \ n und schließen Sie es in eine trim () -ähnliche Funktion ein .

StanE
quelle
3
Wäre schön zu wissen, warum meine Antwort abgelehnt wird ... Verrückt ... Die akzeptierte Antwort ist falsch , während meine richtig ist. Es ist im Allgemeinen nicht richtig zu sagen, dass PHP_EOL das Problem behandelt. Es kann (und sollte) verwendet werden, wenn NUR etwas in / aus demselben System gelesen oder geschrieben wird. Meistens wird PHP jedoch verwendet, um etwas an den Client zurückzusenden (woran der Fragesteller höchstwahrscheinlich gedacht hat). Nochmals: PHP_EOL ist eine reine serverseitige Konstante. Clientseitige Zeilenumbrüche werden NICHT korrekt behandelt (und können dies auch nicht). Bitte schreibe einen Kommentar und sag mir, wenn du denkst, dass ich etwas falsch geschrieben habe.
StanE
3
+1 für einen guten Punkt gegen den Strich. Ich denke, es ist verloren, weil Browser keine Leerzeichen in HTML rendern, so dass die allgemeine Verwendung für Konsolenanwendungen wäre. Und wie Sie sagten, würde in diesem Fall das Zeilenende für die ausführende Umgebung interpretiert, was für Konsolen-Apps, aber nicht für Client-Server-Webanwendungen sinnvoll ist.
Jeff Puckett
Nun, die Antwort bezieht sich nicht wirklich. Sie erwähnen die Browserkompatibilität und das Senden von Dateien an andere Systeme. Newline ist für die Textausgabe relevant, daher sind Browser nicht relevant. Und im Gegensatz zu Ihrem Hauptsache, diese Textdateien werden in der Regel auf der gleichen Plattform verbraucht sie geschrieben sind.
Grantwparks
6

Die Definition von PHP_EOL ist, dass es Ihnen den Zeilenumbruchcharakter des Betriebssystems gibt, an dem Sie arbeiten.

In der Praxis sollten Sie dies fast nie brauchen. Betrachten Sie einige Fälle:

  • Wenn Sie im Web ausgeben, gibt es wirklich keine Konvention, außer dass Sie konsistent sein sollten. Da die meisten Server Unixy sind, sollten Sie trotzdem ein "\ n" verwenden.

  • Wenn Sie in eine Datei ausgeben, scheint PHP_EOL eine gute Idee zu sein. Sie können jedoch einen ähnlichen Effekt erzielen, indem Sie eine wörtliche neue Zeile in Ihrer Datei haben. Dies hilft Ihnen, wenn Sie versuchen, einige CRLF-formatierte Dateien unter Unix auszuführen, ohne vorhandene neue Zeilen zu beschädigen (als Typ mit einem Dual-Boot-System) Ich kann sagen, dass ich das letztere Verhalten bevorzuge.

PHP_EOL ist so lächerlich lang, dass es sich wirklich nicht lohnt, es zu benutzen.

Edward Z. Yang
quelle
33
-1 für "PHP_EOL ist so lächerlich lang". Es ist kein gültiges Argument.
viam0Zah
1
Ich stimme völlig mit Ihnen. Es macht überhaupt keinen Sinn, PHP auf etwas anderem als * nix bereitzustellen. Daher macht es keinen Sinn, PHP_EOL oder DIRECTORY_SEPARATOR zu verwenden.
Stann
@Stann Können Sie Ihren Standpunkt zu "Es macht überhaupt keinen Sinn, PHP auf etwas anderem als * nix bereitzustellen" erklären?
Sajuuk
2
@Sajuuk Ich glaube, das würde "Sarkasmus" heißen.
Félix Gagnon-Grenier
3

Es gibt einen offensichtlichen Ort, an dem dies nützlich sein könnte: Wenn Sie Code schreiben, der überwiegend einfache Anführungszeichen verwendet. Es ist fraglich, ob:

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

Die Kunst ist es, konsequent zu sein. Das Problem beim Mischen und Anpassen von '' und "" ist, dass Sie, wenn Sie lange Zeichenfolgen erhalten, nicht wirklich nach der Art des Zitats suchen müssen, das Sie verwendet haben.

Wie bei allen Dingen im Leben kommt es auf den Kontext an.

SjH
quelle
3

DOS / Windows-Standard "newline" ist CRLF (= \ r \ n) und nicht LFCR (\ n \ r). Wenn wir letzteres sagen, wird es wahrscheinlich zu unerwarteten (tatsächlich erwarteten!: D) Verhaltensweisen kommen.

Heutzutage akzeptieren fast alle (gut geschriebenen) Programme den UNIX-Standard LF (\ n) für Zeilenumbruchcode, sogar Mail-Absender-Daemons (RFC legt CRLF als Zeilenumbruch für Header und Nachrichtentext fest).

Nica Mlg
quelle
2

Praktisch mit error_log (), wenn Sie mehrere Zeilen ausgeben.

Ich habe festgestellt, dass viele Debug-Anweisungen in meiner Windows-Installation seltsam aussehen, da die Entwickler beim Aufbrechen von Zeichenfolgen Unix-Endungen angenommen haben.

Gavin Gilmour
quelle
2

Ich verwende die PHP_EOL-Konstante in einigen Befehlszeilenskripten, die ich schreiben musste. Ich entwickle auf meinem lokalen Windows-Computer und teste dann auf einer Linux-Server-Box. Die Verwendung der Konstante bedeutete, dass ich mich nicht um die Verwendung des richtigen Zeilenendes für jede der verschiedenen Plattformen kümmern musste.

chrismacp
quelle
2

Ich habe eine Site, auf der ein Protokollierungsskript nach einer Aktion des Benutzers, der ein beliebiges Betriebssystem verwenden kann, eine neue Textzeile in eine Textdatei schreibt.

Die Verwendung von PHP_EOL scheint in diesem Fall nicht optimal zu sein. Wenn der Benutzer unter Mac OS arbeitet und in die Textdatei schreibt, wird \ n eingefügt. Beim Öffnen der Textdatei auf einem Windows-Computer wird kein Zeilenumbruch angezeigt. Aus diesem Grund verwende ich stattdessen "\ r \ n", was beim Öffnen der Datei auf einem beliebigen Betriebssystem funktioniert.

intTiger
quelle
1

Sie schreiben Code, der überwiegend einfache Anführungszeichen verwendet.

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

Ich verwende WebCalendar und habe festgestellt, dass Mac iCal beim Importieren einer generierten ICS-Datei gesperrt ist, da das Zeilenende in xcal.php als "\ r \ n" fest codiert ist. Ich ging hinein und ersetzte alle Vorkommen durch PHP_EOL und jetzt ist iCal glücklich! Ich habe es auch unter Vista getestet und Outlook konnte die Datei auch importieren, obwohl das Zeilenendezeichen "\ n" ist.

Lex
quelle
<late> Dies bedeutet, dass Ihre Anwendung bei der Bereitstellung auf einem Windows-Server eine Fehlfunktion aufweist. Wenn Sie möchten \n, verwenden Sie dies explizit.
Abenddämmerung -inaktiv-
0

Wenn jumi (Joomla-Plugin für PHP) Ihren Code aus irgendeinem Grund kompiliert, werden alle Backslashes aus Ihrem Code entfernt. So etwas wie$csv_output .= "\n"; wird$csv_output .= "n";

Sehr nerviger Bug!

Verwenden Sie stattdessen PHP_EOL, um das gewünschte Ergebnis zu erhalten.

Allan
quelle
2
Ich würde wirklich hoffen, dass dies ein Konfigurationsproblem ist, das Sie noch nicht gefunden haben. Ich habe Joomla nicht benutzt, aber was für ein schreckliches Verhalten, wenn es wirklich so funktioniert!
jon_darkstar
0

Auf einigen Systemen kann es nützlich sein, diese Konstante zu verwenden, denn wenn Sie beispielsweise eine E-Mail senden, können Sie PHP_EOL verwenden, um ein systemübergreifendes Skript auf mehreren Systemen auszuführen ... aber selbst wenn es manchmal nützlich ist, können Sie dies finden Konstantes undefiniertes, modernes Hosting mit der neuesten PHP-Engine hat dieses Problem nicht, aber ich denke, dass es gut ist, einen Bitcode zu schreiben, der diese Situation rettet:

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

Sie können also PHP_EOL problemlos verwenden ... offensichtlich sollte PHP_EOL für Skripte verwendet werden, die auf mehreren Systemen gleichzeitig funktionieren sollten, andernfalls können Sie \ n oder \ r oder \ r \ n verwenden ...

Hinweis: PHP_EOL kann sein

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

Hoffe diese Antwort hilft.

Alessandro
quelle
0

Ich habe dieses Problem gerade bei der Ausgabe auf einem Windows-Client festgestellt. Sicher, PHP_EOL ist für die Serverseite, aber die meisten von PHP ausgegebenen Inhalte sind für Windows-Clients. Also muss ich meine Erkenntnisse hier für die nächste Person platzieren.

A) Echo 'Mein Text'. PHP_EOL; // Schlecht, da dies nur \ n ausgibt und die meisten Versionen des Windows-Notizblocks dies in einer einzelnen Zeile anzeigen und die meisten Windows-Buchhaltungssoftware diese Art von Zeilenendezeichen nicht importieren können.

B) Echo 'Mein Text \ r \ n'; // Schlecht, weil einfach zitierte PHP-Strings \ r \ n nicht interpretieren

C) Echo "Mein Text \ r \ n"; // Ja, es funktioniert! Sieht im Editor korrekt aus und funktioniert beim Importieren der Datei in andere Windows-Software wie Windows Accounting und Windows Manufacturing Software.

hamish
quelle
-2

Ich bevorzuge \ n \ r. Außerdem bin ich auf einem Windows-System und \ n funktioniert meiner Erfahrung nach einwandfrei.

Da PHP_EOL nicht mit regulären Ausdrücken funktioniert und dies die nützlichste Art ist, mit Text umzugehen, habe ich ihn wirklich nie benutzt oder musste.


quelle
12
Vorsicht bei der Newline-Zeichenreihenfolge, es sollte \ r \ n (CR + LF) sein: en.wikipedia.org/wiki/Newline
Azkotoki
Sie verwenden es nicht, aber Ihre Website kann von jedem auf jedem PC geöffnet werden, so dass es ein Problem sein kann
Owaiz Yusufi