Когда я использую константу PHP "PHP EOL"?

С 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, logs...), где вы хотите Единой newlines (и вы должны хотеть это на мой взгляд).

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

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

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

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

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

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

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 очень полезна для обработки файлов, особенно если вы пишете несколько строк содержимого в файл.

например, у вас есть длинная строка, которую вы хотите разбить на несколько строк при записи в обычный файл. Использование \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 use \n, MacOS / OS X тоже изменился с \r на \n, и в Windows многие приложения (особенно браузеры) могут отображать его правильно. В Windows также легко изменить существующий клиентский код, чтобы использовать только \n и по-прежнему поддерживать обратную совместимость: просто измените разделитель для обрезки строк от \r\n до \n и оберните его в функцию trim () like.

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

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

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

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

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

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

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). Если мы поставим последнее, это, вероятно, приведет к некоторым неожиданным (ну, на самом деле, вроде ожидаемым! :Д) поведение.

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

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

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

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

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

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

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

Я использую константу 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 не работает с регулярными выражениями, и это самый полезный способ работы с текстом, то я действительно никогда не использовал его или не нуждался.