मैं PHP निरंतर "PHP_EOL" का उपयोग कब करूं?

Question

इसका उपयोग कब करना एक अच्छा विचार है PHP_EOL?

मैं कभी-कभी इसे PHP के कोड नमूनों में देखता हूं। क्या यह डॉस / मैक / यूनिक्स एंडलाइन मुद्दों को संभालता है?

Comments

मुझे लगता है कि इस पृष्ठ पर उत्कीर्ण जवाबों में बहुत भ्रामक सलाह है। यदि आप दो अलग-अलग प्लेटफार्मों पर एक स्क्रिप्ट चलाते हैं, तो आउटपुट या उत्पन्न डेटा (लॉग फाइलें, एचटीएमएल पेज, डेटाबेस रिकॉर्ड आदि) की तुलना करें, तो PHP_EOL के परिणामस्वरूप अंतर में एक बेमेल हो जाएगा। ज्यादातर मामलों में यह वह नहीं है जो आप चाहते हैं।

— दान

Answer 1

हां, PHP_EOLएक क्रॉस-प्लेटफॉर्म-संगत तरीके से न्यूलाइन वर्ण को खोजने के लिए आमतौर पर उपयोग किया जाता है, इसलिए यह डॉस / यूनिक्स मुद्दों को संभालता है।

ध्यान दें कि PHP_EOL वर्तमान प्रणाली के लिए एंडलाइन वर्ण का प्रतिनिधित्व करता है। उदाहरण के लिए, यह एक यूनिक्स जैसी प्रणाली पर निष्पादित होने पर विंडोज एंडलाइन नहीं मिलेगा।

Comments

कमांड-लाइन स्क्रिप्ट लिखते समय क्या इसे अंत-पंक्ति वर्ण के रूप में उपयोग किया जाना चाहिए?

— थॉमस ओवेन्स

@ और: कैसे किसी के बारे में है कि एप्लिकेशन को स्थापित, उपयोग और दूसरों द्वारा तैनात लिखा जाता है? क्या आप सुझाव दे रहे हैं कि ये सभी अपने "समर्थित प्लेटफॉर्म" को * निक्स तक सीमित कर दें?

— सिलिंड्रिक

@ स्टैन - "बड़े प्रोजेक्ट्स" के बारे में जो आप जानते हैं कि शायद ही सबसे अच्छा अभ्यास करने का निर्णय लेने वाला कारक है, अकेले चलो क्या है या उपयोगी नहीं है। मैं एक "बड़ी परियोजना" को बनाए रखता हूं जो कुछ होस्ट्स पर कुछ विंडोज़ सर्वर सहित कई मेजबानों में भाग में तैनात है। यह मत समझो - स्थिरांक कुछ भी चोट नहीं पहुंचाते हैं, और प्लेटफ़ॉर्म-न्यूट्रल कोड लिखने के लिए पूरी तरह से वैध तरीका है। इसके विपरीत आपकी टिप्पणियाँ कुछ बेतुकी हैं।

— क्रिस बेकर

नहीं, मुझे नहीं लगता कि आपका उत्तर सही है। आप एक सिस्टम पर कोड जेनरेट करते हैं लेकिन आउटपुट को दूसरे सिस्टम पर भेजते हैं। हालाँकि, PHP_EOL आपको केवल उस सिस्‍टम के लिए सीमांकन रेखा को बताता है जहां इसका उपयोग किया जाता है। यह आपको गारंटी नहीं देता कि दूसरी प्रणाली समान सीमांकक का उपयोग करती है। नीचे मेरा जवाब देखें।

— स्टेनी

लेकिन PHP_EOLफॉर्म से पोस्ट किए गए डेटा के लिए उपयोग न करें ।

— नबी काज

Answer 2

से 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"(विंडोज सर्वर पर) या "\n"(किसी और चीज पर) हो सकता है। पीएचपी संस्करणों पर पहले 5.4.0RC8, वहाँ के लिए एक तिहाई मूल्य संभव थे PHP_EOL: "\r"(MacOSX सर्वर पर)। यह गलत था और 2012-03-01 को बग 61193 के साथ तय किया गया था ।

जैसा कि अन्य लोगों ने आपको पहले ही बताया था, आप PHP_EOLकिसी भी प्रकार के आउटपुट में उपयोग कर सकते हैं (जहाँ इनमें से कोई भी मान मान्य है - जैसे: HTML, XML, लॉग ...) जहाँ आप एकीकृत नई रूपरेखा चाहते हैं । ध्यान रखें कि यह सर्वर है कि यह मूल्य निर्धारित कर रहा है, ग्राहक नहीं। आपके विंडोज आगंतुकों को आपके यूनिक्स सर्वर से मूल्य मिलेगा जो उनके लिए कभी-कभी असुविधाजनक होता है।

मैं बस PHP_EOLPHP स्रोतों द्वारा समर्थित के मानों को दिखाना चाहता था क्योंकि यह अभी तक यहाँ नहीं दिखाया गया है ...

Comments

वाह। PHP डेवलपर्स इस बारे में गलत हैं। विकिपीडिया लिंक के रूप में आप उल्लेख करते हैं, मैक OS 9 और "\ r" का उपयोग करने से पहले, लेकिन OS X नहीं, जो "\ n" का उपयोग करता है। किसी को बग रिपोर्ट दर्ज करनी चाहिए ...

— imgx64

@ imgx64 हाँ हो सकता है, लेकिन ईमानदारी से क्या आपने कभी उत्पादन मैक सर्वर देखा है?

— एलेक्सवी

@ imgx64 आपकी पोस्ट के 33 दिन बाद यह तय किया गया है :) मैंने वर्तमान स्रोतों को प्रतिबिंबित करने के लिए अपना उत्तर अपडेट कर दिया है।

— एलेक्सवी

मुझे नहीं लगता कि आउटपुट ((!) के लिए PHP_EOL का उपयोग करने का तर्क मान्य है। PHP_EOL सर्वर-साइड है, जबकि आउटपुट क्लाइंट के लिए सामान्य रूप से होता है (जो अलग-अलग लाइन को समाप्त करता है)। उदाहरण: यदि आप PHP_EOL के साथ एक लिनक्स सिस्टम पर एक बहु-रेखा सादा पाठ आउटपुट बनाते हैं और इसे एक विंडोज सिस्टम पर भेजते हैं, तो यह सीमांत को समाप्त करने वाली एक वैध रेखा नहीं होगी - यह निर्भर करेगा कि क्लाइंट सॉफ्टवेयर क्या आउटपुट प्रदर्शित करेगा। ब्राउज़र और कुछ पाठ संपादक इसे संभाल सकते हैं, लेकिन यदि आप नोटपैड में उदाहरण के लिए पाठ देखते हैं, तो सब कुछ एक पंक्ति में होगा।

— स्टेनली

php -r "echo addcslashes(PHP_EOL, PHP_EOL), PHP_EOL;"पता लगाने के लिए।

— बॉब स्टीन

Answer 3

PHP_EOLजब आप एक नई लाइन चाहते हैं, और आप क्रॉस-प्लेटफ़ॉर्म बनना चाहते हैं, तो आप इसका उपयोग करते हैं।

यह तब हो सकता है जब आप फाइलसिस्टम (लॉग्स, एक्सपोर्ट, अन्य) को फाइल लिख रहे हैं।

यदि आप चाहते हैं कि आपका जेनरेट किया गया HTML पठनीय हो तो आप इसका उपयोग कर सकते हैं। तो आप अपने <br />एक के साथ पालन ​​कर सकते हैं PHP_EOL।

यदि आप php को cron से स्क्रिप्ट के रूप में चला रहे हैं, तो आप इसका उपयोग करेंगे और आपको कुछ आउटपुट करने की आवश्यकता होगी और इसे स्क्रीन के लिए स्वरूपित किया जाएगा।

यदि आप कुछ फ़ॉर्मेटिंग की आवश्यकता के लिए ईमेल भेजने के लिए उपयोग कर रहे हैं, तो आप इसका उपयोग कर सकते हैं।

Comments

HTML उत्पन्न करते समय आपको प्लेटफ़ॉर्म-स्वतंत्र newlines का उपयोग करने की आवश्यकता नहीं है।

— रॉब

@ आरओबी, यदि IE के पुराने संस्करणों ने मुझे एक बेहतर पृष्ठ-स्रोत दर्शक दिया है तो विंडोज़ नोटपैड मैं आपके साथ सहमत हो सकता है।

— Zoredache

@Zoredache - पीएचपी जिस प्लेटफ़ॉर्म पर चल रहा है, उसके लिए उपयुक्त नईलाइन्स के साथ एचटीएमएल जेनरेट होगा, ज़रूरी नहीं कि जिस प्लेटफ़ॉर्म से आप पेज एक्सेस कर रहे हों।

— डोमिनिक रॉगर

ईमेल बिल्डिंग का उल्लेख करने के लिए +1 $header = "From: $from" . PHP_EOL; $header .= "Reply-To: $from" . PHP_EOL; $header .= "Return-Path: $from" . PHP_EOL;

— जैकब कोसोरोबा

PHP_EOLईमेल हेडर को अलग करने के लिए उपयोग नहीं किया जाना चाहिए। PHP मेल मैनुअल के अनुसार , कई अतिरिक्त हेडर को CRLF (\ r \ n) के साथ अलग किया जाना चाहिए।

— हालिल Halzgür

Answer 4

PHP_EOL (स्ट्रिंग) इस प्लेटफ़ॉर्म के लिए सही 'एंड ऑफ़ लाइन' प्रतीक है। PHP 4.3.10 और PHP 5.0.2 के बाद से उपलब्ध है

जब आप सर्वर के फाइल सिस्टम पर टेक्स्ट फाइल पढ़ते या लिखते हैं तो आप इस स्थिरांक का उपयोग कर सकते हैं।

ज्यादातर मामलों में लाइन एंडिंग मायने नहीं रखती क्योंकि ज्यादातर सॉफ्टवेयर अपनी उत्पत्ति की परवाह किए बिना टेक्स्ट फाइलों को संभालने में सक्षम हैं। आपको अपने कोड के अनुरूप होना चाहिए।

यदि लाइन एंडिंग मायने रखती है, तो निरंतर का उपयोग करने के बजाय स्पष्ट रूप से लाइन एंडिंग निर्दिष्ट करें। उदाहरण के लिए:

• HTTP हेडर द्वारा अलग किया जाना चाहिए\r\n
• CSV फ़ाइलों को पंक्ति विभाजक के रूप में उपयोग करना चाहिए\r\n

Comments

"HTTP हेडर होना चाहिए ..." के लिए स्रोत: ietf.org/rfc/rfc2616.txt अध्याय 4 खंड 1

— एड्रियन फोडर

एसएमटीपी संदेश लाइनों चाहिए द्वारा समाप्त किया जा\r\n

— बॉब स्टीन

Answer 5

मैं एक उत्तर में फेंकना चाहूंगा जो "जब उपयोग न करना हो तो" को संबोधित करता है क्योंकि यह अभी तक कवर नहीं किया गया है और यह कल्पना कर सकता है कि इसका उपयोग नेत्रहीन रूप से किया जा रहा है और कोई भी नोटिंग नहीं कर रहा है, बाद में लाइन के नीचे तक कोई समस्या नहीं है। इसमें से कुछ मौजूदा जवाबों में कुछ विरोधाभासी हैं।

यदि HTML में एक वेबपेज के लिए आउटपुट, विशेष रूप से पाठ में <textarea>, <pre>या <code>आप शायद हमेशा उपयोग करना चाहते हैं \nऔर नहीं PHP_EOL।

इसका कारण यह है कि जब कोड एक सीरीज़ पर अच्छा प्रदर्शन कर सकता है - जो कि यूनिक्स जैसा प्लेटफ़ॉर्म होता है - अगर विंडोज होस्ट (जैसे विंडोज एज़्योर प्लेटफ़ॉर्म) पर तैनात किया जाता है, तो यह बदल सकता है कि कुछ ब्राउज़रों में पेज कैसे प्रदर्शित होते हैं (विशेष रूप से इंटरनेट एक्सप्लोरर - कुछ संस्करण जिनमें \ n और \ r दोनों दिखाई देंगे)।

मुझे यकीन नहीं है कि यह अभी भी IE6 के बाद से एक मुद्दा है या नहीं, इसलिए यह काफी मूक हो सकता है लेकिन यह ध्यान देने योग्य है कि क्या यह लोगों को संदर्भ के बारे में सोचने के लिए संकेत देने में मदद करता है। अन्य मामले (जैसे कि सख्त एक्सएचटीएमएल) हो सकते हैं, जहां \rकुछ प्लेटफार्मों पर अचानक आउटपुट देने से आउटपुट के साथ समस्याएं हो सकती हैं, और मुझे यकीन है कि इस तरह के अन्य किनारे मामले भी हैं।

जैसा कि पहले से ही किसी ने नोट किया है, आप HTTP हेडर वापस करते समय इसका उपयोग नहीं करना चाहेंगे - क्योंकि उन्हें हमेशा किसी भी मंच पर RFC का पालन करना चाहिए।

मैं CSV फ़ाइलों पर सीमांकक जैसी चीज़ के लिए इसका उपयोग नहीं करूँगा (जैसा कि किसी ने सुझाव दिया है)। प्लेटफ़ॉर्म जिस पर चल रहा है, वह उत्पन्न या उपभोग की गई फ़ाइलों में लाइन अंत का निर्धारण नहीं करना चाहिए।

Answer 6

मैंने फ़ाइल हैंडलिंग के लिए 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";
}
?>

Comments

अनुक्रम के रूप में \ n \ r कभी काम नहीं करेगा क्योंकि इसका अर्थ \ n \ / </ पैदल चाल> है

— frak

Answer 7

नहीं, PHP_EOL एंडलाइन मुद्दों को संभालता नहीं है, क्योंकि सिस्टम जहां आप उस स्थिरांक का उपयोग करते हैं, वही सिस्टम नहीं है जहां आप आउटपुट भेजते हैं।

मैं PHP_EOL का उपयोग करने की सलाह नहीं दूंगा। Unix / Linux का उपयोग \ n, MacOS / OS X ने \ r से \ n में भी बदल दिया और Windows पर कई एप्लिकेशन (विशेष रूप से ब्राउज़र) इसे सही ढंग से भी प्रदर्शित कर सकते हैं। विंडोज़ पर, केवल \ n का उपयोग करने के लिए मौजूदा क्लाइंट-साइड कोड को बदलना आसान है और अभी भी बैकवर्ड-कम्पैटिबिलिटी बनाए रखता है: बस लाइन को ट्रिम करने के लिए सीमांकक को \ r \ n से \ n में बदलें और इसे ट्रिम () फ़ंक्शन की तरह लपेटें ।

Comments

यह जानकर अच्छा लगेगा कि मेरा उत्तर क्यों अस्वीकृत है ... पागल ... स्वीकृत उत्तर गलत है , जबकि मेरा सही है। यह कहना आम तौर पर सही नहीं है कि PHP_EOL समस्या को संभालता है। एक ही सिस्टम से / से कुछ पढ़ने या लिखने पर इसका उपयोग (और करना चाहिए) । लेकिन ज्यादातर समय PHP का उपयोग क्लाइंट को कुछ वापस भेजने के लिए किया जाता है (जो कि सबसे अधिक संभावना है कि प्रश्नकर्ता ने क्या सोचा था)। दोबारा: PHP_EOL एक शुद्ध सर्वर-साइड स्थिरांक है। यह क्लाइंट साइड लाइन ब्रेक को सही ढंग से हैंडल नहीं करता (और नहीं कर सकता) कृपया एक टिप्पणी लिखें और मुझे बताएं, अगर आपको लगता है कि मैंने कुछ गलत लिखा है।

— स्टेनी

अनाज के खिलाफ एक अच्छा बिंदु बनाने के लिए +1। मुझे लगता है कि यह खो गया है क्योंकि ब्राउज़र HTML में व्हाट्सएप को प्रस्तुत नहीं करते हैं, इसलिए सामान्य उपयोग कंसोल अनुप्रयोगों के लिए होगा। और जैसा कि आपने कहा था, उस स्थिति में लाइनिंग एंडिंग की व्याख्या पर्यावरण के लिए की जाएगी, जो कंसोल ऐप्स के लिए समझ में आता है, लेकिन क्लाइंट-सर्वर वेब एप्लिकेशन के लिए नहीं।

— जेफ पकेट

खैर, जवाब वास्तव में संबंधित नहीं है। आप ब्राउज़र संगतता और अन्य सिस्टमों को फाइल भेजने का उल्लेख करते हैं। टेक्स्ट आउटपुट में न्यूलाइन प्रासंगिक है, इसलिए ब्राउज़र प्रासंगिक नहीं हैं। और अपने मुख्य बिंदु के विपरीत, इन पाठ फ़ाइलों कर रहे हैं आमतौर पर वे पर लिखा रहे हैं एक ही मंच पर सेवन किया।

— अनुदान

Answer 8

PHP_EOL की परिभाषा यह है कि यह आपको उस ऑपरेटिंग सिस्टम की नई पंक्ति देता है, जिस पर आप काम कर रहे हैं।

व्यवहार में, आपको लगभग कभी भी इसकी आवश्यकता नहीं होनी चाहिए। कुछ मामलों पर विचार करें:

• जब आप वेब पर आउटपुट कर रहे होते हैं, तो वास्तव में कोई कन्वेंशन नहीं होता है सिवाय इसके कि आप लगातार रहें। चूंकि अधिकांश सर्वर यूनिक्स हैं, आप वैसे भी "\ n" का उपयोग करना चाहेंगे।

• यदि आप किसी फ़ाइल में आउटपुट कर रहे हैं, तो PHP_EOL एक अच्छे विचार की तरह लग सकता है। हालाँकि, आप अपनी फ़ाइल के अंदर एक शाब्दिक नई लाइन होने से एक समान प्रभाव प्राप्त कर सकते हैं, और यह आपकी मदद करेगा यदि आप मौजूदा newlines (एक दोहरे बूट सिस्टम वाले लड़के के रूप में) के बिना यूनिक्स पर कुछ CRLF स्वरूपित फ़ाइलों को चलाने की कोशिश कर रहे हैं , मैं कह सकता हूं कि मैं बाद के व्यवहार को पसंद करता हूं)

PHP_EOL इतनी हास्यास्पद है कि वास्तव में इसका उपयोग करने लायक नहीं है।

Comments

-1 के लिए "PHP_EOL बहुत हास्यास्पद है"। यह मान्य तर्क नहीं है।

— viam0Zah

मैं पूर्णतः सन्तुष्ट हुँ। किसी भी चीज़ पर php को तैनात करने का कोई अर्थ नहीं है लेकिन * nix। इस प्रकार - PHP_EOL या DIRECTORY_SEPARATOR का उपयोग करने का कोई मतलब नहीं है।

— स्टैन

@Stann क्या आप "nix" पर किसी भी चीज़ के लिए php को तैनात करने के बारे में अपनी बात समझा सकते हैं?

— सजुकुक

@ सज्जुक का मानना ​​है कि इसे "व्यंग्य" कहा जाएगा।

— फेलिक्स गगनोन-ग्रेनियर

Answer 9

एक स्पष्ट स्थान है जहां यह उपयोगी हो सकता है: जब आप कोड लिख रहे हैं जो मुख्य रूप से एकल उद्धरण तार का उपयोग करता है। इसके तर्क के रूप में चाहे:

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

वहां की कला को सुसंगत बनाना है। मिक्स एंड मैचिंग '' और "" के साथ समस्या यह है कि जब आप लंबे स्ट्रिंग्स प्राप्त करते हैं, तो आप वास्तव में यह नहीं चाहते हैं कि आप किस प्रकार के उद्धरण का उपयोग करें।

जीवन में सभी चीजों के साथ, यह संदर्भ पर निर्भर करता है।

Answer 10

डॉस / विंडोज मानक "न्यूलाइन" CRLF (= \ r \ n) है और LFCR (\ n \ r) नहीं है। यदि हम उत्तरार्द्ध डालते हैं, तो यह कुछ अप्रत्याशित (अच्छी तरह से, वास्तव में, अपेक्षित प्रकार !: डी) व्यवहार का उत्पादन करने की संभावना है।

आजकल लगभग सभी (अच्छी तरह से लिखे गए) कार्यक्रम यूनिक्स मानक LF (\ n) को नए कोड के लिए स्वीकार करते हैं, यहां तक ​​कि मेल भेजने वाले डेमॉन (RFC CRLF को हेडर और मैसेज बॉडी के लिए न्यूलाइन के रूप में सेट करते हैं)।

Answer 11

यदि आप कई पंक्तियों का उत्पादन कर रहे हैं, तो error_log () के साथ काम करें।

मैंने पाया है कि बहुत सारे डिबग स्टेटमेंट मेरी खिड़कियों पर अजीब लगते हैं क्योंकि डेवलपर्स ने स्ट्रिंग्स को तोड़ने पर यूनिक्स एंडिंग को ग्रहण किया है।

Answer 12

मैं कुछ कमांड लाइन लिपियों में PHP_EOL निरंतर का उपयोग करता हूं जो मुझे लिखना था। मैं अपने स्थानीय विंडोज मशीन पर विकसित करता हूं और फिर एक लिनक्स सर्वर बॉक्स पर परीक्षण करता हूं। निरंतर का उपयोग करने का मतलब है कि मुझे विभिन्न प्लेटफार्मों में से प्रत्येक के लिए सही लाइन समाप्ति का उपयोग करने के बारे में चिंता करने की ज़रूरत नहीं है।

Answer 13

मेरे पास एक साइट है जहां लॉगिंग-स्क्रिप्ट उपयोगकर्ता से एक कार्रवाई के बाद एक टेक्स्टफाइल को पाठ की एक नई पंक्ति लिखती है, जो किसी भी ओएस का उपयोग कर सकती है।

PHP_EOL का उपयोग इस मामले में इष्टतम नहीं लगता है। यदि उपयोगकर्ता मैक ओएस पर है और टेक्स्टफाइल को लिखता है तो यह \ n डाल देगा। विंडोज कंप्यूटर पर टेक्स्टफाइल को खोलते समय यह लाइन ब्रेक नहीं दिखाता है। इस कारण से मैं इसके बजाय "\ r \ n" का उपयोग करता हूं जो किसी भी OS पर फ़ाइल खोलने पर काम करता है।

Answer 14

आप कोड लिख रहे हैं जो मुख्य रूप से एकल उद्धरण स्ट्रिंग्स का उपयोग करता है।

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

Answer 15

मैं WebCalendar का उपयोग कर रहा हूं और पाया कि मैक iCal बार-बार उत्पन्न जनरेट फ़ाइल को आयात करने पर रोक लगाता है क्योंकि अंत-की-लाइन xcal.php में "\ r \ n" के रूप में हार्डकोड की जाती है। मैं अंदर गया और PHP_EOL के साथ सभी घटनाओं को बदल दिया और अब iCal खुश है! मैंने विस्टा पर भी इसका परीक्षण किया और आउटलुक फ़ाइल को आयात करने में सक्षम था, भले ही लाइन चरित्र का अंत "\ n" हो।

Comments

<देरी> इसका मतलब है कि जब आपका अनुप्रयोग विंडोज सर्वर पर तैनात होता है तो वह खराबी करेगा। यदि आप चाहते हैं \n, तो स्पष्ट रूप से उपयोग करें।

— डस्कवफ-एक्टिव-

Answer 16

जब jumi (PHP के लिए जूमला प्लगइन) किसी कारण से आपके कोड को संकलित करता है तो यह आपके कोड से सभी बैकस्लैश को हटा देता है। ऐसा कि जैसे कुछ $csv_output .= "\n";बन जाता है$csv_output .= "n";

बहुत कष्टप्रद बग!

इसके बाद परिणाम प्राप्त करने के लिए PHP_EOL का उपयोग करें।

Comments

मैं वास्तव में वास्तव में आशा करता हूं कि यह एक कॉन्फ़िगरेशन समस्या है जिसे आपने अभी तक नहीं पाया है। मैं जूमला का इस्तेमाल करता था, लेकिन अगर यह वास्तव में कैसे काम करता है, तो यह एक भयानक व्यवहार है!

— jon_darkstar

Answer 17

कुछ सिस्टम पर इस स्थिरांक का उपयोग करने के लिए उपयोगी हो सकता है क्योंकि यदि, उदाहरण के लिए, आप एक ईमेल भेज रहे हैं, तो आप 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

आशा है कि यह उत्तर मदद करेगा।

Answer 18

मैं सिर्फ इस मुद्दे का अनुभव किया जब एक Windows ग्राहक के लिए outputting। जरूर, PHP_EOL सर्वर साइड के लिए है, लेकिन php से ज्यादातर कंटेंट आउटपुट विंडोज़ क्लाइंट्स के लिए है। इसलिए मुझे अपने निष्कर्षों को अगले व्यक्ति के लिए यहां रखना होगा।

ए) 'मेरा पाठ' प्रतिध्वनि। PHP_EOL; // खराब क्योंकि यह सिर्फ \ n आउटपुट करता है और अधिकांश वर्जन विंडोज नोटपैड इसे एक ही लाइन पर प्रदर्शित करता है, और ज्यादातर विंडो अकाउंटिंग सॉफ्टवेयर इस तरह के लाइन कैरेक्टर के अंत में आयात नहीं कर सकते हैं।

बी) गूंज 'मेरा पाठ \ r \ n'; // खराब क्योंकि एकल उद्धृत php स्ट्रिंग्स \ r \ n की व्याख्या नहीं करते हैं

ग) "मेरा पाठ \ r \ n" प्रतिध्वनि; // ये काम करता है! नोटपैड में सही दिखता है, और फ़ाइल को अन्य विंडोज़ सॉफ़्टवेयर जैसे विंडोज़ अकाउंटिंग और विंडोज़ मैन्युफैक्चरिंग सॉफ़्टवेयर में आयात करते समय काम करता है।

Answer 19

मैं \ n \ r का उपयोग करना पसंद करता हूं। इसके अलावा, मैं एक विंडोज़ सिस्टम पर हूँ और \ n मेरे अनुभव में ठीक काम करता है।

चूंकि PHP_EOL नियमित अभिव्यक्तियों के साथ काम नहीं करता है, और ये पाठ से निपटने का सबसे उपयोगी तरीका है, तो मैंने वास्तव में कभी भी इसका उपयोग नहीं किया या इसके लिए आवश्यक नहीं था।

Comments

Newline char ऑर्डर से सावधान रहें, यह \ r \ n (CR + LF) होना चाहिए: en.wikipedia.org/wiki/Newline

— azkotoki

आप इसका उपयोग नहीं करते हैं, लेकिन आपकी साइट किसी भी पीसी पर किसी के द्वारा भी खुली हो सकती है, इसलिए यह एक मुद्दा हो सकता है

— ओवैस यूसुफी