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

Когда рекомендуется использовать PHP_EOL?

Я иногда вижу это в образцах кода PHP. Означает ли этот дескриптор проблемы DOS/Mac/Unix?

ОТВЕТЫ

Ответ 1

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

Обратите внимание, что PHP_EOL представляет символ конца для текущей системы. Например, он не найдет конечную линию Windows при выполнении в unix-подобной системе.

Ответ 2

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

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

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

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

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

Ответ 3

Из main/php.h PHP версии 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 было третье возможное значение для PHP_EOL: "\r" (на серверах MacOSX). Это было неправильно и исправлено в 2012-03-01 с ошибкой 61193.

Как уже говорили вам другие, вы можете использовать PHP_EOL в любом виде вывода (где любое из этих значений допустимо - например: HTML, XML, журналы...), где вы хотите объединить новые строки. Имейте в виду, что это сервер, который определяет значение, а не клиент. Ваши посетители Windows получат значение с вашего Unix-сервера, что иногда неудобно для них.

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

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

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

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

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

Ответ 6

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

Например, у вас длинная строка, которую вы хотите разбить на несколько строк при записи в обычный файл. Использование \r\n может не работать, поэтому просто поставьте PHP_EOL в свой script, и результат будет потрясающим.

Посмотрите этот простой пример ниже:

<?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 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";
}
?>

Ответ 7

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

Я бы не рекомендовал использовать PHP_EOL. Unix/Linux использует \n, MacOS/OS X изменен с \r на\n и в Windows многие приложения (особенно браузеры) могут отображать их правильно. В Windows также легко изменить существующий клиентский код, чтобы использовать только \n и по-прежнему поддерживать обратную совместимость. Просто измените разделитель на обрезку строки с \r\n на\n и оберните его в функцию trim().

Ответ 8

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

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

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

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

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

Ответ 9

Стандартная "новая строка" DOS/Windows - это CRLF (=\r\n), а не LFCR (\n\r). Если мы поместим последнее, это может привести к неожиданному (ну, по сути, виду ожидаемого!: D) поведения.

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

Ответ 10

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

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

Искусство этого должно быть последовательным. Проблема с миксами и совпадением "и" заключается в том, что когда вы получаете длинные строки, вы действительно не хотите идти на охоту за тем, какую цитату вы использовали.

Как и во всех вещах в жизни, это зависит от контекста.

Ответ 11

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

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

Ответ 12

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

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

Ответ 13

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

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

Ответ 14

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

Ответ 15

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

Ответ 16

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

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

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

Ответ 17

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

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