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

à Partir de main/php.h de la version de PHP 5.6.30 et la version 7.1.1:

#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" (sur n'importe quoi d'autre). Sur les versions PHP prior 5.4.0RC8, il y avait une troisième valeur possible pour PHP_EOL : "\r" (sur les serveurs MacOSX). Il était erroné et a été corrigé le 01-03-2012 avec bogue 61193 .

As d'autres vous l'ont déjà dit, vous pouvez utiliser PHP_EOL dans n'importe quel type de sortie (où n'importe laquelle de ces valeurs est valide - comme: HTML, XML, logs... où vous voulez unifiée les retours à la ligne (et vous devriez vouloir ce à mon avis).

je voulais juste montrer les valeurs possibles de PHP_EOL supportées par les sources PHP car il n'a pas encore été montré ici...

Vous utilisez PHP_EOL lorsque 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 voulez que votre HTML généré soit lisible. Donc vous pourriez suivre votre <br /> avec un PHP_EOL .

vous l'utilisez si vous exécutez php comme un script à partir de cron et que vous avez besoin de sortir quelque chose et de l'avoir être formaté pour un écran.

vous pourriez l'utiliser si vous construisez un email pour envoyer qui a besoin de formatage.

PHP_EOL (string) Le bon symbole de "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.

n'ont pas d'importance dans la plupart des cas, car la plupart des logiciels sont capables de traiter des fichiers textes, quelle que soit leur origine. Vous devez être cohérent avec votre code.

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

• en-têtes HTTP doit être séparé par \r\n
• fichiers CSV devrait utiliser \r\n comme séparateur de ligne

je voudrais ajouter une réponse qui s'adresse "quand pas à l'utiliser " car il n'a pas encore été couvert et peut imaginer qu'il est utilisé aveuglément et personne remarquant qu'il ya un problème jusqu'à plus tard dans la ligne. Certaines de ces réponses contredisent quelque peu certaines des réponses existantes.

si outputting à une page Web en HTML, en particulier le texte dans <textarea> , <pre> ou <code> vous voulez probablement toujours utiliser \n et non PHP_EOL .

la raison en est que même si le code peut bien fonctionner 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 alors modifier la façon dont les pages sont affichées dans certains navigateurs (en particulier Internet Explorer-dont certaines versions verront à la fois le \N et le \r).

Je ne suis pas sûr que ce soit toujours un problème depuis IE6 ou pas, donc il pourrait être assez discutable mais semble valoir la peine mentionner si cela aide les gens à réfléchir au contexte. Il pourrait y avoir d'autres cas (comme strict XHTML) où la sortie soudaine de \r sur certaines plates-formes pourrait causer des problèmes avec la sortie, et je suis sûr qu'il y a d'autres cas de bord comme celui-ci.

comme quelqu'un l'a déjà noté, vous ne voudriez pas l'utiliser en retournant les 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 délimiteurs sur les fichiers CSV (comme quelqu'un l'a suggéré). La plate-forme sur laquelle le sever est lancé ne devrait 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 le traitement de fichier, surtout si vous écrivez plusieurs lignes de contenu dans un fichier.

par exemple, vous avez une longue chaîne que vous voulez briser dans les lignes multiples tout en écrivant dans le fichier simple. Utiliser \r\n pourrait ne pas fonctionner alors il suffit de mettre PHP_EOL dans votre script et le résultat est impressionnant.

regardez 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 de ligne, parce que le système où vous utilisez cette constante n'est pas le même système où vous envoyez la sortie.

Je ne recommande pas D'utiliser PHP_EOL du tout. Unix / Linux utilise \n, MacOS / OS X changé de \R à \n trop et sur Windows de nombreuses applications (en particulier les navigateurs) peut l'afficher correctement aussi. Sur Windows, il est également facile de changer le code client existant à utiliser \n seulement et maintenir toujours la rétrocompatibilité: juste changez le délimiteur de ligne de \r\n en \n et enveloppez-le dans une fonction trim() like.

la définition de PHP_EOL est qu'elle vous donne le caractère newline du système d'exploitation sur lequel vous travaillez.

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

• quand vous sortez sur le web, il n'y a vraiment aucune convention sauf que vous devez être cohérent. Puisque la plupart des serveurs sont Unixy, vous voudrez utiliser un "\n" de toute façon.

• si vous produisez vers un fichier, PHP_EOL peut sembler être une bonne idée. Cependant, vous pouvez obtenir un effet similaire en ayant une nouvelle ligne littérale à l'intérieur de votre fichier, et cela vous aidera si vous essayez d'exécuter quelques fichiers formatés CRLF sur Unix sans saboter les nouvelles lignes existantes (comme un gars avec un système de double-boot, je peux dire que je préfère le dernier comportement)

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

il y a un endroit évident où il pourrait être utile: lorsque vous écrivez du code qui utilise principalement des chaînes de citations simples. Son discutable quant à savoir si:

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

L'art c'est d'être cohérent. Le problème avec mix and matching " and " est que lorsque vous obtenez de longues cordes, vous ne voulez pas vraiment avoir à aller à la chasse pour le type de citation que vous avez utilisé.

comme pour toute chose dans la vie, cela dépend du contexte.

DOS/Windows standard "saut de ligne" est CRLF (= \r\n) et pas LFCR (\n\r). Si nous mettons ce dernier, il est susceptible de produire quelque inattendu (Eh bien, en fait, un peu attendue! : D) les comportements.

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

j'ai un site où un script de journalisation écrit une nouvelle ligne de texte à un fichier texte après une action de l'utilisateur, qui peut utiliser n'importe quel OS.

en utilisant PHP_EOL ne semble pas être optimal dans ce cas. Si L'utilisateur est sur Mac OS et écrit dans le fichier textfile, il va mettre \n. Lors de l'ouverture du fichier textfile sur un ordinateur windows, il ne montre pas de rupture de ligne. Pour cette raison, j'utilise "\r\n" à la place qui fonctionne lors de l'ouverture du fichier sur N'importe quel OS.

pratique avec error_log () si vous produisez plusieurs lignes.

j'ai trouvé que beaucoup de déclarations de débogage semblent bizarres sur mon windows install car les développeurs ont supposé des terminaisons unix lors de la rupture des chaînes.

vous écrivez du code qui utilise principalement des chaînes de citations simples.

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

j'utilise la constante PHP_EOL dans certains scripts de ligne de commande que j'ai dû écrire. Je me développe sur ma machine Windows locale et ensuite je teste sur une boîte de serveur Linux. En utilisant la constante, je n'ai pas eu à me soucier d'utiliser la fin de ligne correcte pour chacune des plates-formes différentes.

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

quand jumi (Joomla plugin for PHP) compile votre code pour une raison quelconque, il supprime tous les antislashes de votre code. Tel que quelque chose comme $csv_output .= "\n"; devient $csv_output .= "n";

très ennuyeux bug!

utilisez PHP_EOL à la place pour obtenir le résultat que vous cherchiez.

je préfère utiliser \n\r. Aussi, je suis sur un système windows et \n fonctionne très bien dans mon expérience.

puisque PHP_EOL ne fonctionne pas avec des expressions régulières, et que celles-ci sont la façon la plus utile de traiter du texte, alors je ne l'ai vraiment jamais utilisé ou nécessaire.