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

Когда это хорошая идея для использования PHP_EOL?

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

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

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

Начиная 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, так как он еще не был показан здесь ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда jumi (плагин joomla для PHP) по какой-то причине компилирует ваш код, он удаляет все обратные косые черты из вашего кода. Такой что-то вроде $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. Поэтому я должен разместить свои выводы здесь для следующего человека.

А) эхо «Мой текст». PHP_EOL; // Плохо, потому что это просто выводит \ n, и большинство версий Windows Notepad отображают это в одной строке, и большинство программ учета Windows не может импортировать этот тип символа конца строки.

B) повторить «Мой текст \ r \ n»; // Плохо, потому что php-строки в одинарных кавычках не интерпретируют \ r \ n

В) эхо "Мой текст \ r \ n"; // Да, это работает! В блокноте выглядит правильно и работает при импорте файла в другое программное обеспечение Windows, такое как Windows Accounting и Windows Manufacturing.

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

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