Когда я использую постоянную PHP «PHP_EOL»?

Да, PHP_EOL якобы используется для поиска символа новой строки кросс-платформенным способом, поэтому он обрабатывает проблемы DOS / Unix.

Вы используете PHP_EOL когда хотите новую строку, и хотите быть кросс-платформенным.

Это может быть, когда вы пишете файлы в файловой системе (журналы, экспорт, другие).

Вы можете использовать его, если хотите, чтобы ваш сгенерированный HTML был доступен для чтения. Таким образом, вы можете следить за своим <br /> с помощью PHP_EOL .

Вы бы использовали его, если вы используете php как скрипт из cron, и вам нужно было что-то выводить и отформатировать его для экрана.

Вы можете использовать его, если вы создаете электронное письмо для отправки, которое требует некоторого форматирования.

Из main/php.h PHP версии 5.6.30 и версии 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 

Как вы видите, PHP_EOL может быть "\r\n" (на серверах Windows) или "\n" (что-то еще). В версиях PHP, предшествующих 5.4.0RC8, для PHP_EOL было возможно третье значение: "\r" (на серверах MacOSX). Это было неправильно и исправлено в 2012-03-01 с ошибкой 61193 .

Как уже говорили вам другие, вы можете использовать PHP_EOL в любом виде вывода (где любое из этих значений допустимо – например: HTML, XML, журналы …), где вы хотите использовать унифицированные новые строки (и вам это нужно по моему мнению) ,

Я просто хотел показать значения возможностей PHP_EOL поддерживаемые PHP-источниками, так как пока не показано здесь …

PHP_EOL (строка) Правильный символ «Конец строки» для этой платформы. Доступно с PHP 4.3.10 и PHP 5.0.2

Вы можете использовать эту константу при чтении или записи текстовых файлов в файловой системе сервера.

Окончание строк в большинстве случаев не имеет значения, так как большинство программных средств способны обрабатывать текстовые файлы независимо от их происхождения. Вы должны соответствовать вашему коду.

Если заканчивается конец строки, явным образом указываю окончания строки вместо использования константы. Например:

• Заголовки HTTP должны быть разделены \r\n
• Файлы CSV должны использовать \r\n качестве разделителя строк

Я хотел бы дать ответ, в котором говорится: «Когда не использовать его», поскольку он еще не был охвачен и может представить, что он используется вслепую, и никто не замечает, что проблема доходит до конца. Некоторые из них несколько противоречат некоторым из существующих ответов.

Если вы выводите на веб-страницу в HTML, особенно текст в <textarea> , <pre> или <code> вы, вероятно, всегда хотите использовать \n а не PHP_EOL .

Причина этого заключается в том, что, хотя код может работать хорошо на одном сервере, который является платформой, подобной Unix, – если она развернута на узле Windows (например, платформа Windows Azure), то она может изменить способ отображения страниц в некоторых браузерах (в частности, Internet Explorer – некоторые версии которого будут видеть как \ n, так и \ r).

Я не уверен, если это по-прежнему является проблемой, так как IE6 или нет, так что это может быть довольно спорным, но, кажется, стоит отметить, если это помогает людям оперативно думать о контексте. Могут быть и другие случаи (например, строгий XHTML), где suddently вывод \r на некоторых платформах может вызвать проблемы с выходом, и я уверен, что есть и другие подобные случаи.

Как уже заметил кто-то, вы не захотите использовать его при возврате заголовков HTTP – так как они всегда должны следовать RFC на любой платформе.

Я бы не использовал его для чего-то вроде разделителей в файлах CSV (как кто-то предложил). Платформа, на которой выполняется сервер, не должна определять окончание строки в сгенерированных или потребляемых файлах.

Определение PHP_EOL заключается в том, что оно дает вам символ новой строки операционной системы, над которой вы работаете.

На практике вы почти никогда не нуждаетесь в этом. Рассмотрим несколько случаев:

• Когда вы выходите в Интернет, действительно нет никакого соглашения, за исключением того, что вы должны быть последовательными. Поскольку большинство серверов Unixy, вы все равно хотите использовать «\ n».

• Если вы выводите файл, PHP_EOL может показаться хорошей идеей. Тем не менее, вы можете получить аналогичный эффект, имея буквальную новую строку внутри вашего файла, и это поможет вам, если вы попытаетесь запустить некоторые файлы в формате CRLF в Unix, не сбивая существующие новые строки (как парень с системой двойной загрузки , Я могу сказать, что я предпочитаю последнее поведение)

PHP_EOL настолько смехотворно длинный, что его действительно не стоит использовать.

Я нашел 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 () ,

Существует одно очевидное место, где это может быть полезно: когда вы пишете код, который преимущественно использует одиночные кавычки. Его аргументы в пользу того,

 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) поведения.

В настоящее время почти все (хорошо написанные) программы принимают стандарт UNF LF (\ n) для кода новой строки, даже демоны почтовых отправителей (RFC устанавливает CRLF как новую строку для заголовков и тела сообщения).

Вы пишете код, который преимущественно использует одиночные кавычки.

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

У меня есть сайт, где скрипт регистрации записывает новую строку текста в текстовый файл после действия пользователя, который может использовать любую ОС.

Использование PHP_EOL в этом случае не представляется оптимальным. Если пользователь находится в Mac OS и записывает в текстовый файл, он помещает \ n. При открытии текстового файла на компьютере Windows он не отображает разрыв строки. По этой причине я использую вместо этого «\ r \ n», который работает при открытии файла на любой ОС.

Handy с error_log (), если вы выводите несколько строк.

Я обнаружил, что многие отладочные заявления выглядят странно на моих установках Windows, поскольку разработчики предполагают окончание unix при разрыве строк.

Я использую константу PHP_EOL в некоторых сценариях командной строки, которые мне приходилось писать. Я разрабатываю свою локальную машину Windows, а затем тестирую на сервере Linux. Использование константы означало, что мне не нужно было беспокоиться об использовании правильной строки, заканчивающейся для каждой из разных платформ.

Я использую WebCalendar и обнаружил, что Mac iCal barfs импортирует сгенерированный файл ics, потому что конец строки жестко закодирован в xcal.php как «\ r \ n». Я вошел и заменил все вхождения PHP_EOL, и теперь iCal счастлив! Я также тестировал его на Vista, и Outlook смог также импортировать этот файл, даже если символ конца строки «\ n».

Когда jumi (плагин joomla для PHP) компилирует ваш код по какой-то причине, он удаляет все обратные косые черты из вашего кода. Такое что-то вроде $csv_output .= "\n"; становится $csv_output .= "n";

Очень раздражающая ошибка!

Вместо этого используйте PHP_EOL, чтобы получить результат.

Я предпочитаю использовать \ n \ r. Кроме того, я нахожусь в системе Windows, и \ n отлично работает в моем опыте.

Поскольку PHP_EOL не работает с регулярными выражениями, и это самый полезный способ работы с текстом, я никогда не использовал его или не нуждался.