Quand dois-je utiliser la constante PHP "PHP_EOL"?

360

Quand est-ce une bonne idée d'utiliser PHP_EOL?

Je vois parfois cela dans des exemples de code de PHP. Est-ce que cela gère les problèmes de fin de ligne DOS / Mac / Unix?

Christian Oudard
la source
1
Je pense qu'il y a beaucoup de conseils trompeurs dans les réponses votées sur cette page. Si vous exécutez un script sur deux plates-formes différentes, puis comparez la sortie ou les données générées (fichiers journaux, page html, enregistrements de base de données, etc.), alors PHP_EOL entraînera une incompatibilité dans le diff. Dans la plupart des cas, ce n'est pas ce que vous voulez.
donquixote

Réponses:

357

Oui, PHP_EOLest apparemment utilisé pour trouver le caractère de nouvelle ligne d'une manière compatible avec plusieurs plates-formes, il gère donc les problèmes DOS / Unix.

Notez que PHP_EOL représente le caractère de fin pour le système actuel . Par exemple, il ne trouvera pas de fin de ligne Windows lorsqu'il est exécuté sur un système de type Unix.

Adam Bellaire
la source
9
Doit-il être utilisé comme caractère de fin de ligne lors de l'écriture d'un script de ligne de commande?
Thomas Owens
5
@Andre: Et quiconque écrit des applications à installer, à utiliser et à déployer par d'autres? Suggérez-vous que ceux-ci devraient tous limiter leurs "plates-formes prises en charge" à * nix?
Cylindrique
1
@Stann - Ce que font les "grands projets" que vous connaissez n'est guère le facteur décisif des meilleures pratiques, encore moins ce qui est ou n'est pas utile. Je maintiens un "gros projet" qui est déployé en partie sur plusieurs hôtes, dont certains serveurs Windows. Ne partez pas du principe que les constantes ne font rien de mal et sont un moyen parfaitement valide d'écrire du code neutre sur la plate-forme. Vos commentaires contraires sont quelque peu absurdes.
Chris Baker
5
Non, je ne pense pas que votre réponse soit correcte. Vous générez du code sur un système mais envoyez la sortie à un autre système. PHP_EOL, cependant, vous indique le délimiteur de fin de ligne UNIQUEMENT pour le système où il est utilisé. Il ne vous garantit pas que l'autre système utilise le même délimiteur. Voir ma réponse ci-dessous.
StanE
1
mais ne l'utilisez pas PHP_EOLpour les données publiées à partir du formulaire.
Nabi KAZ
88

Depuis main/php.hPHP version 7.1.1 et 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

Comme vous pouvez le voir PHP_EOLpeut être "\r\n"(sur les serveurs Windows) ou "\n"(sur toute autre chose). Sur les versions PHP antérieures à 5.4.0RC8, il y avait une troisième valeur possible pour PHP_EOL: "\r"(sur les serveurs MacOSX). C'était faux et a été corrigé le 2012-03-01 avec le bogue 61193 .

Comme d'autres vous l'ont déjà dit, vous pouvez utiliser PHP_EOLdans n'importe quel type de sortie (où l' une de ces valeurs est valide - comme: HTML, XML, journaux ...) où vous voulez des retours à la ligne unifiés . Gardez à l'esprit que c'est le serveur qui détermine la valeur, pas le client. Vos visiteurs Windows obtiendront la valeur de votre serveur Unix, ce qui est parfois gênant pour eux.

Je voulais juste montrer les valeurs possibles de PHP_EOLsoutenues par les sources PHP car cela n'a pas encore été montré ici ...

AlexV
la source
3
Sensationnel. Les développeurs PHP se trompent à ce sujet. Comme le lien Wikipédia que vous mentionnez, Mac OS 9 et avant utilisaient "\ r", mais pas OS X, qui utilise "\ n". Quelqu'un devrait déposer un rapport de bogue ...
imgx64
27
@ imgx64 Ouais peut-être, mais honnêtement avez-vous déjà vu un serveur MAC de production?
AlexV
3
@ imgx64 Il a été corrigé 33 jours après votre publication :) J'ai mis à jour ma réponse pour refléter les sources actuelles.
AlexV
2
Je ne pense pas que l'argument pour utiliser PHP_EOL pour la sortie (!) Soit valide. PHP_EOL est côté serveur tandis que la sortie est normalement pour le client (qui utilise des délimiteurs de fin de ligne différents). Exemple: Si vous créez une sortie de texte brut sur plusieurs lignes sur un système Linux avec PHP_EOL et que vous l'envoyez à un système Windows, ce ne sera pas un délimiteur de fin de ligne valide - cela dépendra du logiciel client qui affichera la sortie. Les navigateurs et certains éditeurs de texte peuvent le gérer, mais si vous affichez le texte par exemple dans le Bloc-notes, tout sera sur une seule ligne.
StanE
php -r "echo addcslashes(PHP_EOL, PHP_EOL), PHP_EOL;"découvrir.
Bob Stein
82

Vous utilisez PHP_EOLquand vous voulez une nouvelle ligne, et vous voulez être multi-plateforme.

Cela peut se produire lorsque vous écrivez des fichiers dans le système de fichiers (journaux, exportations, autres).

Vous pouvez l'utiliser si vous souhaitez que votre code HTML généré soit lisible. Donc, vous pourriez suivre votre <br />avec un PHP_EOL.

Vous l'utiliseriez si vous exécutez php en tant que script à partir de cron et que vous deviez produire quelque chose et le formater pour un écran.

Vous pouvez l'utiliser si vous créez un e-mail à envoyer nécessitant une mise en forme.

Zoredache
la source
25
Vous n'avez pas besoin d'utiliser des sauts de ligne indépendants de la plateforme lors de la génération de HTML.
Rob
6
@Rob, Si les anciennes versions d'IE me donnaient un meilleur visualiseur de page source, alors le bloc-notes Windows, j'aurais pu être d'accord avec vous.
Zoredache
14
@Zoredache - le HTML sera généré avec des nouvelles lignes appropriées pour la plate-forme sur laquelle PHP s'exécute, pas nécessairement appropriées pour la plate-forme à partir de laquelle vous accédez aux pages.
Dominic Rodger
2
+1 pour avoir mentionné la création d'e-mails $header = "From: $from" . PHP_EOL; $header .= "Reply-To: $from" . PHP_EOL; $header .= "Return-Path: $from" . PHP_EOL;
Jakob Cosoroaba
49
PHP_EOLne doit pas être utilisé pour séparer les en-têtes des e-mails. Selon le manuel PHP Mail , plusieurs en-têtes supplémentaires doivent être séparés par un CRLF (\ r \ n).
Halil Özgür
19

PHP_EOL (chaîne) Le symbole 'End Of Line' correct pour cette plateforme. Disponible depuis PHP 4.3.10 et PHP 5.0.2

Vous pouvez utiliser cette constante lorsque vous lisez ou écrivez des fichiers texte sur le système de fichiers du serveur.

Les fins de ligne n'ont pas d'importance dans la plupart des cas car la plupart des logiciels sont capables de gérer des fichiers texte quelle que soit leur origine. Vous devez être cohérent avec votre code.

Si les fins de ligne sont importantes, spécifiez explicitement les fins de ligne au lieu d'utiliser la constante. Par exemple:

  • Les en-têtes HTTP doivent être séparés par\r\n
  • Les fichiers CSV doivent utiliser \r\ncomme séparateur de lignes
Salman A
la source
5
source pour "les en-têtes HTTP doivent être ...": ietf.org/rfc/rfc2616.txt chapitre 4 section 1
Adrian Föder
2
Les lignes de message SMTP doivent être terminées par\r\n
Bob Stein
12

Je voudrais apporter une réponse qui aborde "Quand ne pas l'utiliser" car elle n'a pas encore été couverte et peut imaginer qu'elle soit utilisée à l'aveugle et que personne ne remarque qu'il y a un problème jusqu'à plus tard. Certains de ces éléments contredisent quelque peu certaines des réponses existantes.

Si la sortie vers une page Web en HTML, en particulier du texte en <textarea>, <pre>ou si <code>vous voulez toujours toujours utiliser \net non PHP_EOL.

La raison en est que bien que le code puisse fonctionner correctement sur un serveur - qui se trouve être une plate-forme de type Unix - s'il est déployé sur un hôte Windows (comme la plate-forme Windows Azure), il peut modifier la façon dont les pages sont affichées dans certains navigateurs. (spécifiquement Internet Explorer - dont certaines versions verront à la fois le \ n et le \ r).

Je ne sais pas si c'est toujours un problème depuis IE6 ou non, donc cela peut être assez théorique, mais semble utile de mentionner si cela aide les gens à réfléchir au contexte. Il peut y avoir d'autres cas (tels que XHTML strict) où la sortie soudaine de fichiers \rsur certaines plates-formes pourrait causer des problèmes avec la sortie, et je suis sûr qu'il existe d'autres cas marginaux comme celui-ci.

Comme déjà noté par quelqu'un, vous ne voudriez pas l'utiliser lors du retour des en-têtes HTTP - car ils devraient toujours suivre le RFC sur n'importe quelle plate-forme.

Je ne l'utiliserais pas pour quelque chose comme des délimiteurs sur des fichiers CSV (comme quelqu'un l'a suggéré). La plate-forme sur laquelle le serveur s'exécute ne doit pas déterminer les fins de ligne dans les fichiers générés ou consommés.

Iain Collins
la source
10

J'ai trouvé PHP_EOL très utile pour la gestion des fichiers, surtout si vous écrivez plusieurs lignes de contenu dans un fichier.

Par exemple, vous avez une longue chaîne que vous souhaitez diviser en plusieurs lignes lors de l'écriture dans un fichier brut. L'utilisation de \ r \ n peut ne pas fonctionner, alors mettez simplement PHP_EOL dans votre script et le résultat est impressionnant.

Découvrez cet exemple simple ci-dessous:

<?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
la source
3
\ n \ r ne fonctionnera jamais car la séquence est censée être \ r \ n </
pedantry
10

Non, PHP_EOL ne gère pas les problèmes de fin, car le système sur lequel vous utilisez cette constante n'est pas le même système sur lequel vous envoyez la sortie.

Je ne recommanderais pas du tout d'utiliser PHP_EOL. Unix / Linux utilise \ n, MacOS / OS X est également passé de \ r à \ n et sur Windows, de nombreuses applications (en particulier les navigateurs) peuvent également l'afficher correctement. Sous Windows, il est également facile de modifier le code côté client existant pour utiliser uniquement \ n et de conserver la compatibilité descendante: il suffit de changer le délimiteur pour le découpage de ligne de \ r \ n en \ n et de l'envelopper dans une fonction de type trim () .

StanE
la source
3
Ce serait bien de savoir pourquoi ma réponse est dévalorisée ... Fou ... La réponse acceptée est fausse , tandis que la mienne est correcte. Il n'est généralement pas correct de dire que PHP_EOL gère le problème. Il peut (et devrait) être utilisé si vous lisez ou écrivez UNIQUEMENT quelque chose vers / depuis le même système. Mais la plupart du temps, PHP est utilisé pour renvoyer quelque chose au client (ce qui est probablement ce à quoi le questionneur a pensé). Encore une fois: PHP_EOL est une constante côté serveur pur. Il ne gère PAS (et ne peut pas) correctement les sauts de ligne côté client. Veuillez écrire un commentaire et dites-moi, si vous pensez que j'ai écrit quelque chose de mal.
StanE
3
+1 pour avoir fait un bon point contre le grain. Je pense que c'est perdu parce que les navigateurs ne rendent pas les espaces en html, donc l'utilisation courante serait pour les applications console. Et comme vous l'avez dit, dans ce cas, la fin de ligne serait interprétée pour l'environnement d'exécution, ce qui est logique pour les applications de console, mais pas pour les applications Web client-serveur.
Jeff Puckett
Eh bien, la réponse n'a pas vraiment de rapport. Vous mentionnez la compatibilité du navigateur et l'envoi de fichiers à d'autres systèmes. La nouvelle ligne est pertinente dans la sortie de texte, donc les navigateurs ne le sont pas. Et contrairement à votre argument principal, ces fichiers texte sont généralement consommés sur la même plate-forme sur laquelle ils sont écrits.
grantwparks
6

La définition de PHP_EOL est qu'il vous donne le caractère de nouvelle ligne du système d'exploitation sur lequel vous travaillez.

En pratique, vous ne devriez presque jamais en avoir besoin. Prenons quelques cas:

  • Lorsque vous effectuez une sortie sur le Web, il n'y a vraiment aucune convention, sauf que vous devez être cohérent. Comme la plupart des serveurs sont Unixy, vous voudrez quand même utiliser un "\ n".

  • Si vous exportez vers un fichier, PHP_EOL peut sembler une bonne idée. Cependant, vous pouvez obtenir un effet similaire en ayant un retour à la ligne littéral dans votre fichier, et cela vous aidera si vous essayez d'exécuter des fichiers au format CRLF sur Unix sans encombrer les retours à la ligne existants (comme un gars avec un système à double démarrage) , Je peux dire que je préfère ce dernier comportement)

PHP_EOL est si ridiculement long qu'il ne vaut vraiment pas la peine de l'utiliser.

Edward Z. Yang
la source
33
-1 pour "PHP_EOL est tellement ridiculement long". Ce n'est pas un argument valable.
viam0Zah
1
Je suis complètement d'accord avec toi. Il n'y a aucun sens à déployer php sur autre chose que * nix. Ainsi - il est inutile d'utiliser PHP_EOL ou DIRECTORY_SEPARATOR.
Stann
@Stann Pouvez-vous expliquer votre point sur "Il n'y a aucun sens à déployer php sur autre chose que * nix"?
Sajuuk
2
@Sajuuk Je pense que ce serait appelé "sarcasme".
Félix Gagnon-Grenier
3

Il y a un endroit évident où cela pourrait être utile: lorsque vous écrivez du code qui utilise principalement des chaînes de guillemets simples. On peut se demander si:

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

L'art est d'être cohérent. Le problème avec le mixage et l'appariement "" et "" est que lorsque vous obtenez de longues cordes, vous ne voulez pas vraiment devoir aller à la chasse pour le type de citation que vous avez utilisé.

Comme pour toutes les choses de la vie, cela dépend du contexte.

SjH
la source
3

La "nouvelle ligne" standard DOS / Windows est CRLF (= \ r \ n) et non LFCR (\ n \ r). Si nous mettons ce dernier, il est susceptible de produire des comportements inattendus (enfin, en fait, du genre attendu!: D).

De nos jours, presque tous les programmes (bien écrits) acceptent le standard UNIX LF (\ n) pour le code de nouvelle ligne, même les démons d'expéditeur de courrier (RFC définit CRLF comme nouvelle ligne pour les en-têtes et le corps du message).

Nica Mlg
la source
2

Pratique avec error_log () si vous générez plusieurs lignes.

J'ai trouvé beaucoup de déclarations de débogage bizarres sur mon installation Windows car les développeurs ont supposé les terminaisons Unix lors de la rupture des chaînes.

Gavin Gilmour
la source
2

J'utilise la constante PHP_EOL dans certains scripts de ligne de commande que j'ai dû écrire. Je développe sur ma machine Windows locale puis teste sur un serveur Linux. L'utilisation de la constante signifiait que je n'avais pas à me soucier de l'utilisation de la fin de ligne correcte pour chacune des différentes plateformes.

chrismacp
la source
2

J'ai un site où un script de journalisation écrit une nouvelle ligne de texte dans un fichier texte après une action de l'utilisateur, qui peut utiliser n'importe quel système d'exploitation.

L'utilisation de PHP_EOL ne semble pas être optimale dans ce cas. Si l'utilisateur est sous Mac OS et écrit dans le fichier texte, il mettra \ n. Lors de l'ouverture du fichier texte sur un ordinateur Windows, il ne montre pas de saut de ligne. Pour cette raison, j'utilise plutôt "\ r \ n" qui fonctionne lors de l'ouverture du fichier sur n'importe quel OS.

intTiger
la source
1

Vous écrivez du code qui utilise principalement des chaînes de guillemets simples.

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

J'utilise WebCalendar et j'ai constaté que Mac iCal s'interdit d'importer un fichier ics généré car la fin de ligne est codée en dur dans xcal.php sous la forme "\ r \ n". Je suis entré et j'ai remplacé toutes les occurrences par PHP_EOL et maintenant iCal est content! Je l'ai également testé sur Vista et Outlook a également pu importer le fichier, même si le caractère de fin de ligne est "\ n".

Lex
la source
<late> Cela signifie que votre application ne fonctionnera pas correctement lorsqu'elle sera déployée sur un serveur Windows. Si vous le souhaitez \n, utilisez-le explicitement.
duskwuff -inactive-
0

Lorsque jumi (plugin joomla pour PHP) compile votre code pour une raison quelconque, il supprime toutes les barres obliques inverses de votre code. Tels que quelque chose comme $csv_output .= "\n";devient$csv_output .= "n";

Bug très ennuyeux!

Utilisez plutôt PHP_EOL pour obtenir le résultat que vous recherchiez.

Allan
la source
2
j'espère vraiment que c'est un problème de configuration que vous n'avez pas encore trouvé. je n'ai pas utilisé joomla, mais quel comportement horrible si c'est vraiment comme ça que ça marche!
jon_darkstar
0

Sur certains systèmes, il peut être utile d'utiliser cette constante car si, par exemple, vous envoyez un e-mail, vous pouvez utiliser PHP_EOL pour avoir un script inter-systèmes fonctionnant sur plus de systèmes ... mais même si c'est utile parfois, vous pouvez le trouver un hébergement constant indéfini et moderne avec le dernier moteur php n'a pas ce problème mais je pense qu'une bonne chose est d'écrire un peu de code qui sauve cette situation:

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

Vous pouvez donc utiliser PHP_EOL sans problème ... il est évident que PHP_EOL doit être utilisé sur un script qui devrait fonctionner sur plusieurs systèmes à la fois, sinon vous pouvez utiliser \ n ou \ r ou \ r \ n ...

Remarque: PHP_EOL peut être

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

J'espère que cette réponse vous aidera.

Alessandro
la source
0

Je viens de rencontrer ce problème lors de la sortie vers un client Windows. Bien sûr, PHP_EOL est pour le côté serveur, mais la plupart du contenu de php est destiné aux clients Windows. Je dois donc placer mes conclusions ici pour la prochaine personne.

A) faites écho à «Mon texte». PHP_EOL; // Mauvais car cela ne produit que \ n et la plupart des versions du bloc-notes Windows affichent cela sur une seule ligne, et la plupart des logiciels de comptabilité Windows ne peuvent pas importer ce type de caractère de fin de ligne.

B) echo 'Mon texte \ r \ n'; // Mauvais car les chaînes php entre guillemets simples n'interprètent pas \ r \ n

C) echo "Mon texte \ r \ n"; // Ouais ça marche! Semble correct dans le bloc-notes et fonctionne lors de l'importation du fichier vers d'autres logiciels Windows tels que les logiciels de comptabilité et de fabrication Windows.

hamish
la source
-2

Je préfère utiliser \ n \ r. Je suis également sur un système Windows et \ n fonctionne très bien dans mon expérience.

Étant donné que PHP_EOL ne fonctionne pas avec les expressions régulières, et que ce sont les moyens les plus utiles de gérer le texte, je ne l'ai vraiment jamais utilisé ou nécessaire.


la source
12
Méfiez-vous de l'ordre des caractères de nouvelle ligne, il devrait être \ r \ n (CR + LF): en.wikipedia.org/wiki/Newline
azkotoki
Vous ne l'utilisez pas mais votre site peut être ouvert par n'importe qui sur n'importe quel PC, donc cela peut être un problème
Owaiz Yusufi