Коли я використовую константу PHP "PHP_EOL"?

Коли це хороша ідея використовувати PHP_EOL?

Я інколи бачу це в зразках коду PHP. Чи вирішує цю проблему кінцеві лінії DOS / Mac / Unix?

Так, PHP_EOLнібито використовується для пошуку символу нової лінії в сумісній платформі, тому він обробляє проблеми DOS / Unix.

Зауважте, що PHP_EOL представляє символ кінцевої лінії для поточної системи. Наприклад, він не знайде кінцеву лінію Windows при виконанні в unix-подібній системі.

Від main/php.hPHP версії 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). Це було неправильно і було виправлено помилку 61193 за 2012-03-01 .

Як вже говорили інші, ви можете використовувати PHP_EOLбудь-який вид виводу (де будь-яке з цих значень дійсне - наприклад: HTML, XML, журнали ...), де потрібно уніфіковані нові рядки . Майте на увазі, що саме сервер визначає значення, а не клієнт. Ваші відвідувачі Windows отримують цінність від вашого сервера Unix, що для них іноді незручно.

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

Ви використовуєте, PHP_EOLколи хочете новий рядок, і хочете бути кросплатформенним.

Це може бути під час запису файлів у файлову систему (журнали, експорт тощо).

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

Ви б використовували його, якщо ви використовуєте php як скрипт із cron, і вам потрібно було щось вивести і форматувати його на екрані.

Ви можете використовувати його, якщо ви створюєте електронний лист для надсилання, яке потребує певного форматування.

PHP_EOL (рядок) Правильний символ 'End Of Line' для цієї платформи. Доступно з 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 (як хтось запропонував). Платформа, на якій працює sever, не повинна визначати закінчення рядків у створених або споживаних файлах.

Я вважаю 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 і оберніть його в обрізку (), як функцію .

Визначення 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 (), якщо ви виводите кілька рядків.

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

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

У мене є сайт, де журнал-скрипт записує новий рядок тексту в текстовий файл після дії користувача, який може використовувати будь-яку ОС.

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

B) відлуння 'Мій текст \ r \ n'; // Погано, тому що одноцитовані рядки php не інтерпретують \ r \ n

В) відлуння "Мій текст \ r \ n"; // Так, це працює! Виглядає правильно в блокноті та працює при імпорті файлу до іншого програмного забезпечення Windows, такого як облік Windows та програмне забезпечення для виготовлення Windows.

Я вважаю за краще використовувати \ n \ r. Також я перебуваю в системі Windows і \ n добре працює на моєму досвіді.

Оскільки PHP_EOL не працює з регулярними виразами, і це найкорисніший спосіб поводження з текстом, то я насправді ніколи його не використовував і не потребував.