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

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?

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.

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 ...

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.

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

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.

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

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 () .

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.

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.

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).

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.

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.

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.

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

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

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.

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.

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.

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.