いつ使用するのが良い考えPHP_EOLですか?
これは、PHP のコード サンプルで時々見られます。これは DOS/Mac/Unix エンドラインの問題を処理しますか?
はい、PHP_EOL表面上はクロスプラットフォーム互換の方法で改行文字を見つけるために使用されるため、DOS/Unix の問題を処理します。
PHP_EOLは、現在のシステムの終了文字を表すことに注意してください。たとえば、UNIX ライクなシステムで実行した場合、Windows のエンドラインは見つかりません。
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
ご覧のとおり、(Windowsサーバーの場合)または(その他の場合)のPHP_EOL可能性があります。5.4.0RC8より前のPHPバージョンでは、 :( MacOSXサーバーの場合)に3番目の値がありました。これは間違っていて、2012-03-01にバグ61193で修正されました。"\r\n""\n"PHP_EOL"\r"
他の人がすでに言ったように、統一された改行PHP_EOLが必要なあらゆる種類の出力(HTML、XML、ログなど、これらの値のいずれかが有効な場合)で使用できます。値を決定するのはサーバーであり、クライアントではないことに注意してください。Windowsの訪問者は、Unixサーバーから価値を得ることがありますが、これは不便な場合があります。
PHP_EOLここではまだ表示されていないので、PHPソースによってサポートされる可能性のある値を表示したかっただけです...
PHP_EOL新しいラインが必要で、クロスプラットフォームになりたいときに使用します。
これは、ファイルシステム (ログ、エクスポート、その他) にファイルを書き込んでいる場合に発生する可能性があります。
生成された HTML を読みやすくしたい場合に使用できます。したがって、あなた<br />の後にPHP_EOL.
cron からスクリプトとして php を実行していて、何かを出力して画面用にフォーマットする必要がある場合に使用します。
書式設定が必要なメールを作成して送信する場合に使用できます。
PHP_EOL (文字列) このプラットフォームの正しい「行末」記号。PHP 4.3.10 および PHP 5.0.2 以降で利用可能
サーバーのファイルシステムでテキストファイルを読み書きするときに、この定数を使用できます。
ほとんどのソフトウェアは、そのソースに関係なくテキスト ファイルを処理できるため、ほとんどの場合、行末は重要ではありません。コードと一貫性を保つ必要があります。
行末が重要な場合は、定数を使用する代わりに行末を明示的に指定します。例えば:
\r\n\r\nまだカバーされておらず、盲目的に使用され、後で問題があることに誰も気付かないことを想像できるため、「いつ使用しないか」に対処する回答を投げかけたいと思います。これのいくつかは、既存の回答のいくつかと多少矛盾しています。
HTML で Web ページに出力する場合、<textarea>特に.<pre><code>\nPHP_EOL
その理由は、コードが 1 つのサーバー (たまたま Unix に似たプラットフォーム) で適切に動作する可能性がある一方で、Windows ホスト (Windows Azure プラットフォームなど) にデプロイされた場合、一部のブラウザーでのページの表示方法が変わる可能性があるためです。 (具体的には Internet Explorer - 一部のバージョンでは \n と \r の両方が表示されます)。
これがIE6以降の問題であるかどうかはわかりませんので、かなり議論の余地があるかもしれませんが、人々がコンテキストについて考えるよう促すのに役立つかどうかは言及する価値があるようです. \r一部のプラットフォームで 's を突然出力すると、出力に問題が発生する可能性がある他のケース (厳密な XHTML など) があるかもしれません。
すでに誰かが指摘したように、HTTP ヘッダーを返すときに使用したくないでしょう。どのプラットフォームでも常に RFC に従う必要があるためです。
CSVファイルの区切り記号のようなものには使用しません(誰かが提案したように)。サーバーが実行されているプラットフォームは、生成または消費されたファイルの行末を決定するべきではありません。
いいえ、PHP_EOL はエンドラインの問題を処理しません。その定数を使用するシステムは、出力を送信するシステムとは異なるためです。
PHP_EOL の使用はお勧めしません。Unix/Linux は \n を使用し、MacOS / OS X も \r から \n に変更され、Windows では多くのアプリケーション (特にブラウザー) も正しく表示できます。Windows では、既存のクライアント側コードを \n のみを使用するように簡単に変更し、下位互換性を維持することもできます。行のトリミングの区切り文字を \r\n から \n に変更し、trim() のような関数でラップするだけです。 .
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 の定義は、作業中のオペレーティング システムの改行文字を提供することです。
実際には、これが必要になることはほとんどありません。いくつかのケースを考えてみましょう:
Web に出力する場合、一貫性を保つこと以外に特に規則はありません。ほとんどのサーバーは Unixy であるため、とにかく "\n" を使用する必要があります。
ファイルに出力する場合、PHP_EOL は良い考えのように思えるかもしれません。ただし、ファイル内にリテラル改行を入れることで同様の効果を得ることができます。これは、既存の改行を上書きせずに Unix で CRLF 形式のファイルを実行しようとしている場合に役立ちます (デュアルブート システムを使用している場合)。 、私は後者の動作を好むと言えます)
PHP_EOL はとてつもなく長いので、実際に使用する価値はありません。
それが役立つであろう明白な場所が 1 つあります。それは、一重引用符文字列を主に使用するコードを記述している場合です。次のいずれかについて議論の余地があります。
echo 'A $variable_literal that I have'.PHP_EOL.'looks better than'.PHP_EOL;
echo 'this other $one'."\n";
それの芸術は一貫していることです。'' と "" を組み合わせて一致させる場合の問題は、長い文字列を取得したときに、使用した引用符の種類を探しに行く必要がないことです。
人生のすべてのものと同様に、それは文脈に依存します。
DOS/Windows 標準の「改行」は CRLF (= \r\n) であり、LFCR (\n\r) ではありません。後者の場合、予想外の (まあ、実際には、予期されたようなものです! :D) 動作が発生する可能性があります。
今日では、ほとんどすべての (適切に作成された) プログラムは、改行コードに UNIX 標準の LF (\n) を受け入れます (RFC は CRLFをヘッダーとメッセージ本文の改行として設定します)。
私が書かなければならなかったいくつかのコマンド ライン スクリプトでは、PHP_EOL 定数を使用します。ローカルの Windows マシンで開発し、Linux サーバー ボックスでテストします。定数を使用すると、異なるプラットフォームごとに正しい行末を使用することを心配する必要がなくなりました。
複数の行を出力している場合は、error_log() で便利です。
開発者が文字列を分割するときに UNIX の末尾を想定しているため、Windows のインストールで多くのデバッグ ステートメントが奇妙に見えることがわかりました。
任意の OS を使用できるユーザーからのアクションの後に、ロギング スクリプトが新しいテキスト行をテキスト ファイルに書き込むサイトがあります。
この場合、PHP_EOL の使用は最適ではないようです。ユーザーが Mac OS を使用していてテキストファイルに書き込むと、\n が挿入されます。Windows コンピューターでテキスト ファイルを開くと、改行が表示されません。このため、代わりに「\r\n」を使用します。これは、任意の OS でファイルを開くときに機能します。
WebCalendarを使用していますが、xcal.phpで行末が「\ r \ n」としてハードコーディングされているため、生成されたicsファイルのインポート時にMaciCalがバーフを実行していることがわかりました。私は入って、すべての出現をPHP_EOLに置き換えました、そして今iCalは幸せです!また、Vistaでテストしたところ、行末文字が「\ n」であっても、Outlookでファイルをインポートできました。
You are writing code that predominantly uses single quote strings.
echo 'A $variable_literal that I have'.PHP_EOL.'looks better than'.PHP_EOL;
echo 'this other $one'."\n";
jumi (PHP 用の joomla プラグイン) が何らかの理由でコードをコンパイルすると、コードからすべてのバックスラッシュが削除されます。のようなものが$csv_output .= "\n";なるような$csv_output .= "n";
非常に厄介なバグ!
代わりに PHP_EOL を使用して、目的の結果を取得してください。
私は\n\rを使用することを好みます。また、私はWindowsシステムを使用しており、\n私の経験では問題なく動作します。
PHP_EOLは正規表現では機能せず、これらはテキストを処理するための最も便利な方法であるため、実際に使用したことはなく、必要もありませんでした。