いつ使用するのが良いPHP_EOLでしょうか？
PHPのコードサンプルでこれが見られることがあります。これはDOS / Mac / Unixの最終行の問題を処理しますか？
回答:
はい、PHP_EOL表面上はクロスプラットフォーム互換の方法で改行文字を見つけるために使用されているため、DOS / Unixの問題を処理します。
PHP_EOLは現在のシステムのエンドライン文字を表すことに注意してください。たとえば、UNIXライクなシステムで実行した場合、Windowsの最終行は見つかりません。
PHP_EOL、フォームから投稿されたデータには使用しないでください。
main/php.hPHPのバージョン7.1.1とバージョン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あなたが見ることができるようにPHP_EOLすることができ"\r\n"ます（Windowsサーバーの場合）または"\n"（何かに）。PHPバージョンで前 5.4.0RC8、のための可能な第3の値があったPHP_EOL："\r"（MacOSXのサーバ上）。これは誤りで、バグ61193により2012-03-01で修正されています。
他の人がすでに言ったように、統一された改行が必要なPHP_EOLあらゆる種類の出力（HTML、XML、ログなど、これらの値のいずれかが有効である場合）で使用できます。値を決定するのはサーバーではなく、クライアントであることを覚えておいてください。Windowsの訪問者は、Unixサーバーから値を取得しますが、この値は訪問者にとって不便です。
PHP_EOLここにはまだ表示されていないので、PHPソースによってサポートされている可能性のある値を表示したかっただけです...
php -r "echo addcslashes(PHP_EOL, PHP_EOL), PHP_EOL;"見つけるために。
PHP_EOL新しいラインが必要で、クロスプラットフォームになりたいときに使用します。
これは、ファイルシステム（ログ、エクスポート、その他）にファイルを書き込んでいる場合です。
生成されたHTMLを読みやすくする場合に使用できます。つまり、あなたに従うかもしれない<br />しPHP_EOL。
phpをcronからのスクリプトとして実行していて、何かを出力して画面用にフォーマットする必要がある場合に使用します。
何らかのフォーマットが必要なメールを送信するメールを作成している場合は、これを使用できます。
$header = "From: $from" . PHP_EOL; $header .= "Reply-To: $from" . PHP_EOL; $header .= "Return-Path: $from" . PHP_EOL;
PHP_EOL電子メールヘッダーの分離には使用しないでください。PHPメールのマニュアルによると、複数の追加ヘッダーはCRLF（\ r \ n）で区切る必要があります。
PHP_EOL（文字列）このプラットフォームの正しい「行末」記号。PHP 4.3.10およびPHP 5.0.2以降で使用可能
この定数は、サーバーのファイルシステムでテキストファイルを読み書きするときに使用できます。
ほとんどのソフトウェアは、その起源に関係なくテキストファイルを処理できるため、ほとんどの場合、行末は重要ではありません。あなたはあなたのコードと一貫しているべきです。
行末が重要な場合は、定数を使用する代わりに、行末を明示的に指定します。例えば：
\r\n\r\n行区切り記号として使用する必要があります「いつ使用しないか」については、まだカバーされておらず、盲目的に使用されており、問題が発生していることに気づいていないため、後で回答する予定です。これの一部は、既存の回答の一部と多少矛盾します。
HTMLでWebページに出力する場合、特にでテキストを出力する場合<textarea>、<pre>または<code>常に使用\nしたいが、使用したくない場合PHP_EOL。
これは、コードが1つのサーバー（Unixのようなプラットフォーム）でうまく機能する一方で、Windowsホスト（Windows Azureプラットフォームなど）にデプロイされた場合、一部のブラウザーでのページの表示方法が変わる可能性があるためです（特にInternet Explorer-一部のバージョンでは、\ nと\ rの両方が表示されます）。
これがIE6以降の問題であるかどうかはわかりません。かなりおもしろくないかもしれませんが、人々がコンテキストについて考えるよう促すのに役立つかどうか、言及する価値があるようです。\r一部のプラットフォームでを突然出力すると、出力に問題が発生する可能性のある他のケース（厳密なXHTMLなど）がある可能性があります。そのような他のエッジケースがあると確信しています。
誰かがすでに述べたように、HTTPヘッダーを返すときにこれを使用することは望ましくありません。これらは、どのプラットフォームでも常にRFCに従う必要があるためです。
（誰かが示唆したように）CSVファイルの区切り文字などには使用しません。サーバーが実行されているプラットフォームは、生成または消費されたファイルの行末を決定するべきではありません。
特にファイルに複数行のコンテンツを書き込む場合、PHP_EOLはファイル処理に非常に役立つことがわかりました。
たとえば、プレーンファイルに書き込むときに複数の行に分割する長い文字列があるとします。\ r \ nを使用しても機能しない場合があるので、単純にPHP_EOLをスクリプトに挿入すると、すばらしい結果が得られます。
以下の簡単な例をご覧ください。
<?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";
}
?>いいえ、PHP_EOLはエンドラインの問題を処理しません。その定数を使用するシステムは、出力を送信するシステムとは異なるためです。
PHP_EOLの使用はお勧めしません。Unix / Linuxは\ nを使用し、MacOS / OS Xも\ rから\ nに変更され、Windowsでは多くのアプリケーション（特にブラウザ）でも正しく表示できます。Windowsでは、既存のクライアント側コードを変更して、\ nのみを使用して下位互換性を維持することも簡単です。行トリミングの区切り文字を\ r \ nから\ nに変更し、trim（）のような関数でラップします。 。
PHP_EOLの定義は、作業中のオペレーティングシステムの改行文字を提供することです。
実際には、これはほとんど必要ありません。いくつかのケースを考えてみましょう：
あなたがウェブに出力しているとき、あなたが一貫しているべきであるということを除いて、どんな慣習もありません。ほとんどのサーバーはUnixyであるため、とにかく「\ n」を使用する必要があります。
ファイルに出力する場合、PHP_EOLは良い考えのように思えるかもしれません。ただし、ファイル内にリテラルの改行を挿入することで同様の効果を得ることができます。これは、既存の改行を壊さずにUnixでCRLF形式のファイルを実行しようとしている場合に役立ちます（デュアルブートシステムを持つ人として）。 、私は後者の行動を好むと言うことができます）
PHP_EOLは非常に長いので、実際に使用する価値はありません。
あなたは主に一重引用符の文字列を使用するコードを書いています。
echo 'A $variable_literal that I have'.PHP_EOL.'looks better than'.PHP_EOL;
echo 'this other $one'."\n";私はWebCalendarを使用していますが、行末が「\ r \ n」としてxcal.phpにハードコードされているため、生成されたicsファイルをインポートするときにMac iCalがバーコードを検出します。私は行ってすべての出現箇所をPHP_EOLに置き換えましたが、iCalは満足しています！また、Vistaでテストしました。行末文字が「\ n」であっても、Outlookはファイルをインポートすることもできました。
\n、それを明示的に使用してください。
jumi（PHP用のjoomlaプラグイン）が何らかの理由でコードをコンパイルすると、コードからすべてのバックスラッシュが削除されます。のようなものが$csv_output .= "\n";なるように$csv_output .= "n";
非常に迷惑なバグ！
代わりにPHP_EOLを使用して、結果を取得します。
一部のシステムでは、この定数を使用すると便利な場合があります。たとえば、メールを送信する場合、PHP_EOLを使用してクロスシステムスクリプトをより多くのシステムで機能させることができます...しかし、それが役立つ場合でもこれを見つけることができます最新のphpエンジンを使用した一定の未定義の最新のホスティングにはこの問題はありませんが、この状況を保存するビットコードを記述することは良いことだと思います。
<?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");
}
}
?>そのため、問題なくPHP_EOLを使用できます...一度に複数のシステムで動作するスクリプトでPHP_EOLを使用する必要があることは明らかです。それ以外の場合は、\ nまたは\ rまたは\ r \ n ...を使用できます。
注：PHP_EOLは
1) on Unix LN == \n
2) on Mac CR == \r
3) on Windows CR+LN == \r\nこの回答がお役に立てば幸いです。
Windowsクライアントに出力するときにこの問題が発生しました。もちろん、PHP_EOLはサーバー側向けですが、phpからのほとんどのコンテンツ出力はWindowsクライアント向けです。だから私は私の発見を次の人のためにここに置く必要があります。
A）「My Text」をエコーします。PHP_EOL; //これは単に\ nを出力するだけで、Windowsのメモ帳のほとんどのバージョンはこれを1行で表示し、ほとんどのWindowsアカウンティングソフトウェアはこのタイプの行末文字をインポートできないため、不良です。
B） 'My Text \ r \ n'をエコーします。//一重引用符で囲まれたphp文字列は\ r \ nを解釈しないため、悪い
C）「My Text \ r \ n」をエコーします。//うまくいきました！メモ帳では正しく見え、WindowsアカウンティングやWindows製造ソフトウェアなどの他のWindowsソフトウェアにファイルをインポートするときに機能します。
私は\ n \ rを使用することを好みます。また、私はWindowsシステムを使用しており、\ n私の経験では問題なく動作します。
PHP_EOLは正規表現では機能せず、これらはテキストを処理するための最も有用な方法であるため、実際に使用したり、使用したりすることはありませんでした。