Frage

Wann ist es eine gute Idee, es zu verwenden? PHP_EOL?

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

War es hilfreich?

Lösung

Ja, PHP_EOL angeblich verwendet, um die Zeilenende-Zeichen in einem Cross-Plattform-kompatibel Weg zu finden, so dass es behandelt DOS / Unix Probleme.

Beachten Sie, dass PHP_EOL die Endlinie Zeichen für das repräsentiert Strom System. Zum Beispiel wird es kein Windows endline finden, wenn sie auf einem Unix-artiges System ausgeführt wird.

Andere Tipps

Von main/php.h von PHP-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 PHP_EOL sehen kann "\r\n" (auf Windows-Servern) oder "\n" (auf etwas anderes). Auf PHP-Versionen vor 5.4.0RC8 gab es einen dritten Wert möglich PHP_EOL: "\r" (auf Mac OS X Server). Es war falsch, und hat auf 2012.03.01 mit bug 61193 rel="nofollow .

Wie andere bereits Sie gesagt, Sie PHP_EOL in jeder Art von Ausgang (wo jede dieser Werte gelten - wie: HTML, XML, Protokolle ...) verwenden können, wo Sie wollen Unified < a href = "http://en.wikipedia.org/wiki/End_of_line" rel = "nofollow noreferrer"> Zeilenumbrüche . Beachten Sie, dass es ist der Server, der den Wert der Bestimmung, nicht der Kunde. Ihre Windows-Besucher, den Wert von Ihrem Unix-Server erhalten, die für sie manchmal unbequem ist.

Ich wollte nur den possibles Wert von PHP_EOL von den PHP-Quellen gesichert zeigen, da es hier nicht dargestellt ist noch ...

Sie verwenden PHP_EOL wenn Sie eine neue Linie wollen, und Sie wollen Cross-Plattform sein.

Dies könnte sein, wenn Sie Dateien auf das Dateisystem (Protokolle, Exporte, andere) schreiben.

Sie können es verwenden, wenn Sie Ihre generierten HTML lesbar sein soll. So können Sie Ihre <br /> mit einem PHP_EOL folgen.

Sie würden es verwenden, wenn Sie PHP als Skript von cron ausgeführt werden und man benötigt für die Ausgabe zu und haben es für einen Bildschirm formatiert werden.

Sie können es verwenden, wenn Sie eine E-Mail bauen bis zu senden, dass einige Formatierung erforderlich.

  

PHP_EOL (string)   Die richtige ‚End Of Line‘ Symbol 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 auf dem Server des Dateisystem lesen oder schreiben.

Zeilenenden keine Rolle in den meisten Fällen als die meisten Software-Umgang mit Textdateien, unabhängig von ihrer Herkunft fähig sind. Sie sollten mit Ihrem Code konsistent sein.

Wenn Zeilenende Rolle ausdrücklich die Zeilenende stattdessen die Konstante zu verwenden. Zum Beispiel:

  • HTTP-Header muss durch \r\n getrennt werden
  • CSV-Dateien sollte Verwendung \r\n als Zeilentrenn

Ich möchte in einer Antwort werfen, die Adressen „Wenn nicht , es zu benutzen“, wie es wurde bisher noch nicht abgedeckt und sich vorstellen kann es blind verwendet wird und niemand bemerkt das es ein Problem, bis später auf der ganzen Linie. Ein Teil davon widerspricht einige der vorhandenen Antworten etwas.

Wenn in HTML zu einer Webseite ausgibt, insbesondere Texte in <textarea>, <pre> oder <code> Sie wahrscheinlich immer \n verwenden wollen, und nicht PHP_EOL.

Der Grund dafür ist, dass während Code auch auf einem Sever ausführen arbeiten kann - das ist eine Unix-ähnliche Plattform passiert sein - wenn auf einer Windows-Host bereitgestellt (wie die Windows Azure-Plattform), dann kann es ändern, wie Seiten angezeigt werden in einigen Browsern (Internet Explorer speziell - einige Versionen davon werden sehen, sowohl die \ n und \ r)

.

Ich bin mir nicht sicher, ob dies immer noch ein Problem, da IE6 ist oder nicht, so könnte es ziemlich strittig sein, aber scheint erwähnenswert, wenn es Leuten prompt zu denken, über den Kontext hilft. Es könnten auch andere Fälle geben (wie strenge XHTML), wo suddently \r der auf einigen Plattformen zur Ausgabe könnte Probleme mit dem Ausgang verursachen, und ich bin sicher, es gibt auch andere Rand Fälle.

Wie bereits von jemand bemerkt, würden Sie nicht wollen, es zu benutzen, wenn die HTTP-Header zurückkehrt -., Da sie immer die RFC auf jeder Plattform folgen sollte

Ich würde es nicht für so etwas wie Trennzeichen auf CSV-Dateien (wie jemand vorgeschlagen hat). Die Plattform der Server auf läuft sollte die Zeilenenden in erzeugt oder verbraucht Dateien nicht ermittelt werden.

Nein, PHP_EOL behandelt keine Endline-Probleme, da das System, auf dem 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 , MacOS/OSUnter Windows ist es auch einfach, vorhandenen clientseitigen Code so zu ändern, dass nur verwendet wird, und trotzdem die Abwärtskompatibilität aufrechtzuerhalten:Ändern Sie einfach das Trennzeichen für das Zeilenkürzen von in und schließen Sie es in eine trim()-ähnliche Funktion ein.

Ich fand PHP_EOL sehr nützlich für Datei-Handling, speziell wenn Sie mehrere Zeilen mit Inhalt in eine Datei schreiben.

Zum Beispiel haben Sie eine lange Zeichenfolge, die Sie in die mehrere Zeilen brechen wollen, während sie in einfache Datei zu schreiben. \ R \ n verwendet, kann nicht so einfach funktionieren setzt PHP_EOL in das Skript und das Ergebnis ist genial.

Schauen Sie sich dieses einfache Beispiel unter:

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

Die Definition von PHP_EOL ist, dass es das Newline-Zeichen des Betriebssystems erhalten Sie gerade arbeiten.

In der Praxis sollte man fast nie brauchen. Betrachten wir einige Fälle:

  • Wenn Sie auf die Bahn ausgeben, gibt es wirklich keine Konvention außer dass Sie konsistent sein sollte. Da die meisten Server Unixy sind, sollten Sie auf jeden Fall ein "\ n" verwenden.

  • Wenn Sie in einer Datei sind ausgibt, PHP_EOL könnte wie eine gute Idee zu sein scheinen. Sie können jedoch einen ähnlichen Effekt durch eine wörtliche Newline in Ihrer Datei haben, und dies wird Ihnen helfen, wenn Sie versuchen, einige CRLF formatierte Dateien unter Unix laufen, ohne bestehende newlines clobbering (als Mann mit einem Dual-Boot-System ich kann sagen, dass ich das letztere Verhalten bevorzugen)

PHP_EOL ist so lächerlich lange, dass es wirklich nicht wert ist es zu benutzen.

Es gibt einen offensichtlichen Ort, wo es sinnvoll sein könnte: wenn Sie Code schreiben, die überwiegend Apostroph Zeichenkette verwendet. Sein diskutierbar, 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 mit der Mischung und Matching ‚‘ und „“ ist, dass, wenn Sie lange Strings bekommen, Sie wollen gehen nicht wirklich zu haben, die Jagd, welche Art von Angebot Sie verwendet haben.

Wie bei allen Dingen im Leben, es hängt vom Kontext ab.

DOS / Windows-Standard "Newline" ist CRLF (= \ r \ n) und nicht LFCR (\ n \ r). Wenn wir die letztere setzen, ist es wahrscheinlich ein unerwartetes zu produzieren. (Na ja, in der Tat, eine Art zu erwarten: D) Verhaltensweisen

Heute fast alle (gut geschrieben) Programme nehmen den UNIX-Standard LF (\ n) für Newline-Code, auch Absender-Daemons (RFC setzt CRLF als Newline für Kopf- und Nachrichtentext) senden.

Ich habe eine Seite, wo ein Logging-Skript, um eine neue Textzeile in eine Textdatei nach einer Aktion des Benutzers schreibt, die jedes Betriebssystem verwenden können.

PHP_EOL Verwendung scheint in diesem Fall nicht optimal. Wenn der Benutzer auf Mac OS und schreibt in der Text-Datei wird es \ n setzen. Wenn die Textdatei auf einem Windows-Computer öffnen, ist es nicht einen Zeilenumbruch zeigen. Aus diesem Grunde i „\ r \ n“ statt verwenden, das funktioniert, wenn Sie die Datei auf jedem Betriebssystem zu öffnen.

Handy mit error_log (), wenn Sie mehrere Zeilen sind ausgegeben werden.

Ich habe eine Menge von Debug-Anweisungen aussieht seltsam auf meinem Windows gefunden installieren, da die Entwickler Unix-Endungen angenommen haben, wenn Strings Zerschlagung.

Sie schreiben Code, der überwiegend Apostroph Zeichenketten verwendet.

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

Ich verwende die PHP_EOL Konstante in einiger Befehlszeilenskripte ich schreiben musste. Ich entwickle auf meinem lokalen Windows-Rechner und testen Sie dann auf einer Linux-Server-Box. Unter Verwendung der Konstante bedeutete, dass ich brauchte sich keine Sorgen über die richtige Linie für jede der verschiedenen Plattformen endet mit.

Ich bin mit WebCalendar und fand, dass Mac iCal barfs eine generierte ics-Datei auf den Import, da die End-of-line in xcal.php als "\ r \ n" fest einprogrammiert ist. Ich ging hinein und ersetzt alle Vorkommen mit PHP_EOL und jetzt iCal ist glücklich! Getestet habe ich es auch auf Vista und Outlook konnte die Datei als auch importieren, auch wenn das Ende der Zeile Zeichen „\ n“.

Wenn jumi (Joomla-Plugin für PHP) kompiliert Ihren Code aus irgendeinem Grund alle Schrägstriche aus dem Code entfernt. Derart, dass so etwas wie $csv_output .= "\n"; wird $csv_output .= "n";

Sehr ärgerlich Fehler!

Verwenden PHP_EOL stattdessen zu bekommen das gewünschte Ergebnis nach waren.

Auf einigem System kann nützlich sein, diese Konstante zu verwenden, da, wenn zum Beispiel werden Sie eine E-Mail senden, können Sie PHP_EOL verwenden, um eine systemübergreifende Skript zu haben, mehr Systeme arbeiten ... aber auch wenn es manchmal nützlich Sie diese konstante nicht definiert, modernes Hosting mit neuesten pHP-Engine haben dieses Problem nicht finden können, aber ich denke, dass eine gute Sache ist ein wenig Code schreiben, um diese Situation speichert:

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

So Sie PHP_EOL ohne Probleme verwenden können ... offensichtlich, dass PHP_EOL sollte auf Skript verwendet werden, die auf einmal mehr Systeme arbeiten sollte sonst können Sie \ n oder \ r oder \ r \ n ...

Hinweis: PHP_EOL kann sein

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

Hope diese Antwort Hilfe.

Ich ziehe \ n \ r zu verwenden. Auch bin ich auf einem Windows-System und \ n funktioniert gut in meiner Erfahrung.

Da PHP_EOL nicht mit regulären Ausdrücken arbeiten, und dies sind die nützlichste Art und Weise mit Text umzugehen, dann habe ich wirklich nie benutzt oder benötigt.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top