Quand dois-je utiliser la constante PHP & # 8220; PHP_EOL & # 8221 ;?

Question

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

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

Answer 1

Oui, PHP_EOL est ostensiblement utilisé pour rechercher le caractère de nouvelle ligne de manière compatible avec plusieurs plates-formes, afin de gérer les problèmes de DOS / Unix.

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

Answer 2

De main / php.h de PHP 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_EOL peut être "\ r \ n" (sur les serveurs Windows) ou "\ n" ou ( sur autre chose). Sur les versions PHP antérieures 5.4.0RC8, une troisième valeur était possible pour PHP_EOL : "\ r" (sur les serveurs MacOSX). C'était faux et a été corrigé le 01/03/2012 avec le bug 61193 . .

Comme d'autres personnes vous l'ont déjà dit, vous pouvez utiliser PHP_EOL dans tout type de sortie (où toutes des valeurs sont valides, telles que: HTML, XML, journaux .. .) où vous voulez des nouvelles lignes unifiées. N'oubliez pas que c'est le serveur qui détermine la valeur, pas le client. Vos visiteurs Windows obtiendront de votre serveur Unix une valeur qui leur est parfois gênante.

Je voulais juste montrer les valeurs possibles de PHP_EOL sauvegardées par les sources PHP car elles n'ont pas encore été affichées ici ...

Answer 3

Vous utilisez PHP_EOL lorsque vous souhaitez une nouvelle ligne et que vous souhaitez être multiplate-forme.

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

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

Vous l'utiliseriez si vous exécutiez php en tant que script de cron et que vous deviez générer quelque chose et le faire formater pour un écran.

Vous pouvez l'utiliser si vous créez un courrier électronique pour l'envoyer nécessitant un certain formatage.

Answer 4

  

PHP_EOL (chaîne)   Le bon symbole 'Fin de ligne' pour cette plate-forme.   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 importent peu 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 \ n comme séparateur de ligne

Answer 5

J'aimerais ajouter une réponse à l'adresse "Quand pas l'utiliser" comme il n'a pas encore été couvert et peut imaginer qu'il soit utilisé à l'aveuglette et que personne ne s'en rende compte, il y a un problème pour plus tard. Cela contredit en partie certaines des réponses existantes.

Si vous effectuez une sortie sur une page Web au format HTML, en particulier du texte dans code> , ou ou probablement toujours vouloir utiliser \ n et non PHP_EOL .

La raison en est que, même si le code peut 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 (telle que la plate-forme Windows Azure), il peut modifier le mode d'affichage des pages. dans certains navigateurs (notamment Internet Explorer - 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 c'est peut-être assez théorique, mais il semble utile de le mentionner si cela aide les gens à réfléchir rapidement au contexte. Il peut y avoir d’autres cas (tels que XHTML strict) dans lesquels la sortie soudaine de \ r sur certaines plates-formes pourrait causer des problèmes de sortie, et je suis sûr qu’il existe d’autres cas extrêmes comme celui-ci.

Comme l'a déjà noté quelqu'un, vous ne voudriez pas l'utiliser pour renvoyer des en-têtes HTTP, car ils devraient toujours suivre le RFC sur toutes les plateformes.

Je ne l'emploierais pas pour quelque chose comme les délimiteurs sur les 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 utilisés.

Answer 6

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

Je ne recommanderais pas du tout d'utiliser PHP_EOL. Unix / Linux utilisé \ n, MacOS / OS X est également passé de \ r à \ n et, sous Windows, de nombreuses applications (notamment les navigateurs) peuvent également l’afficher correctement. Sous Windows, il est également facile de changer le code côté client existant en utilisant uniquement \ n tout en conservant la compatibilité ascendante: il suffit de changer le délimiteur pour le rognage de ligne de \ r \ n à \ n et de l'envelopper dans une fonction semblable à trim () .

Answer 7

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

Par exemple, vous avez une longue chaîne que vous souhaitez fractionner en plusieurs lignes lors de l'écriture dans un fichier brut. L'utilisation de \ r \ n risque de ne pas fonctionner, insérez simplement PHP_EOL dans votre script pour obtenir un résultat 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";
}
?>

Answer 8

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

En pratique, vous ne devriez presque jamais avoir besoin de cela. Considérons quelques cas:

• Lorsque vous effectuez une sortie sur le Web, il n'y a vraiment aucune convention à part que vous devez être cohérent. Étant donné que la plupart des serveurs sont Unixy, vous souhaiterez utiliser un " \ n " de toute façon.

• Si vous exportez dans un fichier, PHP_EOL peut sembler une bonne idée. Cependant, vous pouvez obtenir un effet similaire en insérant une nouvelle ligne littérale dans votre fichier. Cela vous aidera si vous essayez d'exécuter des fichiers au format CRLF sous Unix sans écraser les nouvelles lignes existantes (comme un gars avec un système à double démarrage , Je peux dire que je préfère ce dernier comportement)

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

Answer 9

Cela pourrait être utile à un endroit évident: 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 du mélange et de la mise en correspondance "" et """ est que lorsque vous obtenez de longues chaînes, vous ne voulez pas vraiment aller chercher quel type de citation vous avez utilisé.

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

Answer 10

DOS / Windows standard & new; newline " est CRLF (= \ r \ n) et non LFCR (\ n \ r). Si nous mettons ce dernier point, il est probable que certains comportements inattendus (enfin, en quelque sorte, sont attendus!: D).

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

Answer 11

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.

Utiliser PHP_EOL ne semble pas être optimal dans ce cas. Si l'utilisateur est sous Mac OS et écrit dans le fichier texte, il mettra \ n. Lorsque vous ouvrez le fichier texte sur un ordinateur Windows, il ne montre pas de saut de ligne. Pour cette raison, j'utilise " \ r \ n " au lieu de cela qui fonctionne lorsqu’on ouvre le fichier sur n’importe quel OS.

Answer 12

Pratique avec error_log () si vous produisez plusieurs lignes.

J'ai trouvé que de nombreuses instructions de débogage avaient un aspect bizarre sur mon installation Windows, car les développeurs ont supposé des terminaisons Unix lors de la rupture de chaînes.

Answer 13

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

Answer 14

J'utilise la constante PHP_EOL dans certains scripts en ligne de commande que je devais écrire. Je développe sur ma machine Windows locale puis teste sur un serveur Linux. Utiliser la constante signifiait que je n'avais pas à m'inquiéter d'utiliser la bonne fin de ligne pour chacune des différentes plateformes.

Answer 15

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

Answer 16

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

Bug très ennuyant!

Utilisez plutôt PHP_EOL pour obtenir le résultat recherché.

Answer 17

Sur certains systèmes, il peut être utile d’utiliser cette constante, car si, par exemple, vous envoyez un courrier électronique, vous pouvez utiliser PHP_EOL pour avoir un script inter-système fonctionnant sur plus de systèmes ... mais même si cela vous est utile peut trouver cette constante, hébergement indéfini, moderne avec le dernier moteur php n'ont pas ce problème, mais je pense qu'une bonne chose est d'écrire un code de bit qui enregistre 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èmes ... Il est évident que PHP_EOL doit être utilisé sur un script qui doit fonctionner sur plusieurs systèmes à la fois, sinon vous pouvez utiliser \ n ou \ r ou \ r ... \ <...>

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.

Answer 18

Je préfère utiliser \ n \ r. De plus, je suis sur un système Windows et \ n fonctionne parfaitement selon mon expérience.

Puisque 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 jamais vraiment utilisé ni utilisé.