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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Очень досадный баг!

Вместо этого используйте 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";
}
?>

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

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

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

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

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

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

Из 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). Это было неправильно и было исправлено 01.03.2012 с помощью ошибка 61193.

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

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

PHP_EOL (string) The correct 'End Of Line' symbol for this platform. Available since PHP 4.3.10 and PHP 5.0.2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В некоторых системах может быть полезно использовать эту константу, потому что если, например, вы отправляете электронное письмо, вы можете использовать PHP_EOL, чтобы кросс-системный скрипт работал с большим количеством систем ... но даже если это полезно когда-нибудь, вы можете найти это constant undefined, современный хостинг с последним движком 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 отображают это в одной строке, и большинство программ бухгалтерского учета Windows не могут импортировать этот тип символа конца строки.

Б) echo 'Мой текст \ r \ n'; // Плохо, потому что строки php в одинарных кавычках не интерпретируют \ r \ n

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