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

Question

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

Answer 7

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

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

Answer 8

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

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

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

Answer 9

Я нашел 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"; 
} 
?> 

Answer 10

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

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

Answer 11

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

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

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

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

Answer 12

От 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 с bug 61193.

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

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

Answer 13

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

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

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

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

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

Answer 14

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

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

Answer 15

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

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

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

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

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

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

Answer 16

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

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

Answer 17

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

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