PHP में एक config फाइल बनाना

Question

मैं अपने PHP प्रोजेक्ट के लिए एक कॉन्फिग फाइल बनाना चाहता हूं, लेकिन मुझे यकीन नहीं है कि यह करने का सबसे अच्छा तरीका क्या है।

मेरे पास अब तक 3 विचार हैं।

1-उपयोग चर

$config['hostname'] = "localhost";
$config['dbuser'] = "dbuser";
$config['dbpassword'] = "dbpassword";
$config['dbname'] = "dbname";
$config['sitetitle'] = "sitetitle";

2-कास्ट का उपयोग करें

define('DB_NAME', 'test');
define('DB_USER', 'root');
define('DB_PASSWORD', '');
define('DB_HOST', 'localhost');
define('TITLE', 'sitetitle');

3-डेटाबेस का उपयोग करें

मैं कक्षाओं में कॉन्फ़िगरेशन का उपयोग कर रहा हूं, इसलिए मुझे यकीन नहीं है कि कौन सा तरीका सबसे अच्छा होगा या यदि कोई बेहतर तरीका है।

Comments

4) ini फ़ाइल का उपयोग करें। 5) एक YAML फ़ाइल का उपयोग करें। 6) JSON फ़ाइल का उपयोग करें। 7) ... बहुत सारे तरीके हैं ... कम से कम न्याय करने के लिए कुछ मानदंडों को परिभाषित करें, कुल मिलाकर "सर्वश्रेष्ठ" नहीं है।

— deceze

@ डिसेज़ उपवास का तरीका क्या है? (स्मृति और उपवास)

— अली अकबर अज़ीज़ी

यह आपके लिए तब एक दिलचस्प रीड होना चाहिए: stackoverflow.com/questions/823352/…

— eithed

मैं जिस तरह से Laravel करता है (जब Laravel का उपयोग नहीं कर रहा हूं) का उपयोग करता हूं। मैं एक वर्ग बनाता हूं जो होस्ट नाम के आधार पर एक विशिष्ट कॉन्फ़िगरेशन फ़ाइल लोड करता है। मैं तब इसका उपयोग करके कहता हूं Config::get('key');। pastebin.com/4iTnjEuM

— MisterBla

Answer 1

एक सरल लेकिन सुरुचिपूर्ण तरीका एक config.phpफ़ाइल बनाना है (या जो भी आप इसे कहते हैं) जो कि एक सरणी देता है:

<?php

return array(
    'host' => 'localhost',
    'username' => 'root',
);

और तब:

$configs = include('config.php');

Comments

मुझे यह तरीका भी पसंद है - मुझे लगता है कि यह एक सम्मिलित फ़ाइल में एक वैरिएबल की घोषणा करने की तुलना में क्लीनर है और यह मानते हुए कि यह आपकी स्क्रिप्ट में होगा

— कॉलिन एम

विन्यास फाइल बनाने की इस उत्तर पद्धति में कहां है? मेरे जैसे php नौसिखिए के लिए?

— लुका

@Luka आप var_export फ़ंक्शन का उपयोग कर सकते हैं ।

— हसन बयात

Answer 2

एक INI फ़ाइल का उपयोग एक लचीला और शक्तिशाली समाधान है! PHP को ठीक से संभालने के लिए एक देशी कार्य है। उदाहरण के लिए, इस तरह से एक INI फ़ाइल बनाना संभव है:

app.ini

[database]
db_name     = mydatabase
db_user     = myuser
db_password = mypassword

[application]
app_email = [e-mail]
app_url   = myapp.com

तो केवल एक चीज जो आपको करने की आवश्यकता है वह है कॉल:

$ini = parse_ini_file('app.ini');

फिर आप $iniसरणी का उपयोग करके आसानी से परिभाषाओं तक पहुंच सकते हैं ।

echo $ini['db_name'];     // mydatabase
echo $ini['db_user'];     // myuser
echo $ini['db_password']; // mypassword
echo $ini['app_email'];   // [e-mail]

महत्वपूर्ण: सुरक्षा कारणों से INI फ़ाइल एक गैर सार्वजनिक फ़ोल्डर में होनी चाहिए

Comments

क्या यह भी उपयोग करने के लिए सुरक्षित है? यदि कोई उपयोगकर्ता ini फ़ाइल के लिए पथ का अनुमान लगाता है, और अपने ब्राउज़र में वहाँ जाता है, तो क्या वे देखेंगे कि फ़ाइल में क्या है?

— NickGames

@ रिकमंड, आपको फ़ाइल को किसी गैर सार्वजनिक फ़ोल्डर में रखना होगा, अन्यथा आप एक गंभीर सुरक्षा जोखिम में होंगे

— Marcio Mazzucato

@NickGames, कृपया parse_ini_file () के

— आर

मुझे यह तरीका पसंद है। बोनस टिप: फ़ाइल का नाम app.ini.php पर रखें। फिर पहली पंक्ति में जोड़ें ;<?php die(); ?>। यदि यह फ़ाइल गलती से एक सार्वजनिक फ़ोल्डर में दिखाई देती है, तो इसे PHP फ़ाइल के रूप में माना जाएगा और पहली पंक्ति में मर जाएगा। यदि फ़ाइल के साथ पढ़ा जाता है parse_ini_file, तो यह पहली पंक्ति को टिप्पणी के रूप में मानेगा ;।

— andreas

नोट: यदि ini फ़ाइल में कोई भी गैर-अल्फ़ान्यूमेरिक वर्ण है, तो उसे दोहरे-उद्धरणों ( ") में संलग्न करना होगा । उदाहरण के लिए, किसी भी पासवर्ड में गैर-अल्फ़ान्यूमेरिक वर्ण होते हैं।

— की शांग

Answer 3

मैं @hugo_leonardo के समाधान के एक मामूली विकास का उपयोग करता हूं :

<?php

return (object) array(
    'host' => 'localhost',
    'username' => 'root',
    'pass' => 'password',
    'database' => 'db'
);

?>

यह आपको ऑब्जेक्ट सिंटैक्स का उपयोग करने की अनुमति देता है जब आप php को शामिल करते हैं: $configs->hostइसके बजाय $configs['host']।

इसके अलावा, यदि आपके ऐप में क्लाइंट साइड (जैसे एक कोणीय ऐप) के लिए आपकी ज़रूरत है, तो आपके पास यह config.phpफ़ाइल हो सकती है जिसमें आपके सभी कॉन्फ़िगर्स शामिल हों (जावास्क्रिप्ट के लिए एक के बजाय एक फ़ाइल में केंद्रीकृत और पीएचपी के लिए एक)। फिर चाल एक और PHP फ़ाइल होगी जो echoकेवल क्लाइंट साइड जानकारी होगी (जानकारी दिखाने से बचने के लिए जिसे आप डेटाबेस कनेक्शन स्ट्रिंग की तरह दिखाना नहीं चाहते हैं)। इसे कहते हैं get_app_info.php:

<?php

    $configs = include('config.php');
    echo json_encode($configs->app_info);

?>

आपके मान के ऊपर config.phpएक app_infoपैरामीटर है:

<?php

return (object) array(
    'host' => 'localhost',
    'username' => 'root',
    'pass' => 'password',
    'database' => 'db',
    'app_info' => array(
        'appName'=>"App Name",
        'appURL'=> "http://yourURL/#/"
    )
);

?>

तो आपके डेटाबेस की जानकारी सर्वर साइड पर रहती है, लेकिन आपके ऐप की जानकारी आपके जावास्क्रिप्ट से सुलभ है, उदाहरण के लिए एक $http.get('get_app_info.php').then(...);प्रकार की कॉल।

Comments

इसे एक वस्तु क्यों बनाते हैं?

— theCrazyProfurer 21

इसे ऑब्जेक्ट बनाने से डेटा की हैंडलिंग बहुत आसान हो जाती है। यह उदाहरण के लिए app_infoजावास्क्रिप्ट को JSON के रूप में कोड की न्यूनतम लाइनों के साथ सभी मापदंडों को प्राप्त करने की अनुमति देता है ।

— BoDeX

PHP 5. के संदर्भ में वस्तुओं को संदर्भ द्वारा पारित किए जाने का एक साइड-इफेक्ट भी है। यह एक अच्छी बात हो सकती है या नहीं भी हो सकती है। Arrays मान द्वारा पारित किया जाता है (लेकिन गाय के रूप में कार्यान्वित किया जाता है) ताकि कॉन्फ़िगरेशन ऑब्जेक्ट के बजाय config सरणियों का उपयोग करना बेहतर हो सके।

— मिकको रेंटालिनेन

@BoDeX मुझे इस तरह से हमेशा पसंद है और ज्यादातर लेखों में पसंदीदा तरीका लगता है, लेकिन मैं कक्षा के माध्यम से इसे कैसे एक्सेस करूंगा? मैंने सुरक्षा लेख में पढ़ा है कि वैश्विक चर बनाना एक अच्छा विचार नहीं है तो आप क्या सुझाव देते हैं?

— केवलविग

Answer 4

रिश्तेदार योग्यता / कमजोरियों के साथ मैं जो विकल्प देख रहा हूं वे हैं:

फ़ाइल आधारित तंत्र

इनकी आवश्यकता है कि आपका कोड ini फ़ाइल को खोजने के लिए विशिष्ट स्थानों में दिखता है। यह हल करने के लिए एक कठिन समस्या है और एक जो हमेशा बड़े PHP अनुप्रयोगों में फसल करता है। हालाँकि, आपको PHP कोड खोजने के लिए समस्या को हल करने की आवश्यकता होगी जो रनटाइम में शामिल / फिर से उपयोग किया जाता है।

इसके लिए सामान्य दृष्टिकोण हमेशा सापेक्ष निर्देशिकाओं का उपयोग करना है, या वर्तमान निर्देशिका से ऊपर की ओर खोज करने के लिए आवेदन की आधार निर्देशिका में विशेष रूप से नामित फ़ाइल ढूंढना है।

कॉन्फिग फाइल के लिए इस्तेमाल होने वाले कॉमन फाइल फॉर्मेट में PHP कोड, इनआई फॉरमैटेड फाइल्स, JSON, XML, YAML और सीरीयल PHP हैं

PHP कोड

यह विभिन्न डेटा संरचनाओं का प्रतिनिधित्व करने के लिए लचीलेपन की एक बड़ी मात्रा प्रदान करता है, और (यह मानते हुए कि इसमें शामिल है या आवश्यकता के माध्यम से संसाधित किया जाता है) पार्स कोड ओपोड कैश से उपलब्ध होगा - एक प्रदर्शन लाभ दे रहा है।

Include_path अतिरिक्त कोड पर निर्भर रहे बिना फ़ाइल के संभावित स्थानों सार संक्षेप के लिए एक साधन प्रदान करता है।

दूसरी ओर, कॉन्फ़िगरेशन को कोड से अलग करने का एक मुख्य कारण अलग-अलग जिम्मेदारियां हैं। यह रनटाइम में अतिरिक्त कोड को इंजेक्ट करने के लिए एक मार्ग प्रदान करता है।

यदि कॉन्फ़िगरेशन एक उपकरण से बनाया गया है, तो उपकरण में डेटा को मान्य करना संभव हो सकता है, लेकिन HTML, URL, MySQL स्टेटमेंट, शेल कमांड के लिए मौजूद PHP कोड में एम्बेड करने के लिए डेटा से बचने के लिए कोई मानक कार्य नहीं है ... ।

सीरियलाइज्ड डेटा यह अपेक्षाकृत कम मात्रा में कॉन्फ़िगरेशन (लगभग 200 वस्तुओं तक) के लिए कुशल है और किसी भी PHP डेटा संरचना के उपयोग की अनुमति देता है। डेटा फ़ाइल बनाने / पार्स करने के लिए बहुत कम कोड की आवश्यकता होती है (इसलिए आप यह सुनिश्चित करने के लिए अपने प्रयासों का खर्च उठा सकते हैं कि फ़ाइल केवल उपयुक्त प्राधिकरण के साथ लिखी गई है)।

फ़ाइल में लिखी गई सामग्री से बचने को स्वचालित रूप से नियंत्रित किया जाता है।

चूंकि आप वस्तुओं को अनुक्रमित कर सकते हैं, यह विन्यास फाइल (__wakeup मैजिक विधि) को पढ़कर कोड को लागू करने का एक अवसर पैदा करता है।

संरचित फ़ाइल

मार्सेल या JSON या XML द्वारा सुझाए गए INI फ़ाइल के रूप में इसे संग्रहीत करना भी फ़ाइल को एक PHP डेटा संरचना में (और XML के अपवाद के साथ, डेटा से बचने और फ़ाइल बनाने के लिए) कोड मंगलाचरण को खत्म करने के लिए एक सरल एपीआई प्रदान करता है क्रमबद्ध PHP डेटा का उपयोग कर भेद्यता।

इसमें क्रमबद्ध डेटा के समान प्रदर्शन विशेषताएँ होंगी।

डेटाबेस भंडारण

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

OTOH अपने डेटाबेस से कनेक्ट करने के लिए आपके द्वारा उपयोग किए जाने वाले क्रेडेंशियल्स को स्टोर करने के लिए एक अच्छी जगह नहीं है!

निष्पादन पर्यावरण

आप निष्पादन वातावरण में मान सेट कर सकते हैं जो PHP में चल रहा है।

यह PHP कोड के लिए किसी विशेष स्थान को देखने के लिए किसी भी आवश्यकता को हटा देता है। OTOH यह बड़ी मात्रा में डेटा के लिए अच्छी तरह से पैमाने पर नहीं है और रनटाइम पर सार्वभौमिक रूप से बदलना मुश्किल है।

क्लाइंट पर

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

इसके विपरीत, संवेदनशील जानकारी संग्रहीत करने के लिए इसके बहुत सारे लाभ हैं जो कि अंतिम उपयोगकर्ता के पास है - यदि आप इसे सर्वर पर संग्रहीत नहीं कर रहे हैं, तो इसे वहां से चोरी नहीं किया जा सकता है।

नेटवर्क निर्देशिकाएँ कॉन्फ़िगरेशन जानकारी संग्रहीत करने के लिए एक और दिलचस्प जगह DNS / LDAP में है। यह छोटी संख्या में सूचना के छोटे टुकड़ों के लिए काम करेगा - लेकिन आपको एसपीएफ के लिए 1 सामान्य फॉर्म पर विचार करने की आवश्यकता नहीं है ।

Infrastucture कैशिंग, प्रतिकृति और वितरण का समर्थन करता है। इसलिए यह बहुत बड़े इन्फ्रास्ट्रक्चर के लिए अच्छा काम करता है।

संस्करण नियंत्रण प्रणाली

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

Answer 5

अच्छी तरह से - यह आपके डेटाबेस कॉन्फ़िगरेशन डेटा को डेटाबेस में संग्रहीत करना मुश्किल होगा - क्या आपको नहीं लगता है?

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

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

Answer 6

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

Comments

php निष्पादित करने का तेज़ तरीका क्या है? const या var?

— अली अकबर अज़ीज़ी

@CooPer परिभाषित करने वाला स्थिरांक, चर को परिभाषित करने की तुलना में काफी धीमा है। लेकिन उनका उपयोग करना थोड़ा तेज है। चूंकि ये एक ही स्थान पर उपयोग होने जा रहे हैं, इसलिए चर कुल मिलाकर उच्च प्रदर्शन की पेशकश करेंगे।

— कॉलिन एम

"महत्वपूर्ण रूप से" इसके लिए थोड़ा भारी शब्द है, अगर आप इसे इस तरह से देख रहे हैं, तो शायद आपको php देवों से संपर्क करना चाहिए और उन्हें निरंतर समर्थन हटाने के लिए कहना चाहिए!

— phpalix

@phpalix एक मान को परिभाषित करना एक मान के साथ एक चर को परिभाषित करने की तुलना में 10-20x धीमे से कहीं भी हो सकता है। मैं कहूंगा कि यह महत्वपूर्ण है। हालांकि, यदि आप अपने आवेदन में निरंतर भारी उपयोग करते हैं - यह बहुत अच्छी तरह से भुगतान कर सकता है। लेकिन एक बार उपयोग करने के लिए एक निरंतर बनाने की सलाह नहीं दी जाती है।

— कॉलिन एम

Answer 7

यदि आपको लगता है कि आप किसी भी कारण से 1 db से अधिक का उपयोग कर रहे हैं, तो चर के साथ जाएं क्योंकि आप एक पैरामीटर को पूरी तरह से अलग db में बदलने के लिए बदल पाएंगे। परीक्षण, ऑटोबैकअप, आदि के लिए Ie

Answer 8

आप एक विन्यास वर्ग चुड़ैल स्थिर गुण बना सकते हैं

class Config 
{
    static $dbHost = 'localhost';
    static $dbUsername = 'user';
    static $dbPassword  = 'pass';
}

तो आप इसे सरल उपयोग कर सकते हैं:

Config::$dbHost  

---

कभी-कभी अपनी परियोजनाओं में मैं कॉन्फ़िगरेशन डेटा तक पहुंचने के लिए एक डिज़ाइन पैटर्न SINGLETON का उपयोग करता हूं। यह उपयोग में बहुत आरामदायक है।

क्यों?

उदाहरण के लिए आपके प्रोजेक्ट में 2 डेटा स्रोत हैं। और आप चुन सकते हैं उनमें से चुड़ैल सक्षम है।

• माई एसक्यूएल
• json

कहीं आपके द्वारा चुनी गई कॉन्फ़िगरेशन फ़ाइल में:

$dataSource = 'mysql' // or 'json'

जब आप स्रोत पूरे ऐप को नए डेटा स्रोत में बदल देते हैं, तो ठीक काम करते हैं और कोड में परिवर्तन की आवश्यकता नहीं होती है।

उदाहरण:

कॉन्फ़िग:

class Config 
{
  // ....
  static $dataSource = 'mysql';
  / .....
}

सिंगलटन वर्ग:

class AppConfig
{
    private static $instance;
    private $dataSource;

    private function __construct()
    {
        $this->init();
    }

    private function init()
    {
        switch (Config::$dataSource)
        {
            case 'mysql':
                $this->dataSource = new StorageMysql();
                break;
            case 'json':
                $this->dataSource = new StorageJson();
                break;
            default:
                $this->dataSource = new StorageMysql();
        }
    }

    public static function getInstance()
    {
        if (empty(self::$instance)) {
            self::$instance = new self();
        }
        return self::$instance;
    }

    public function getDataSource()
    {
        return $this->dataSource;
    }
}

... और आपके कोड में कहीं (जैसे कि कुछ सेवा वर्ग में):

$container->getItemsLoader(AppConfig::getInstance()->getDataSource()) // getItemsLoader need Object of specific data source class by dependency injection

हम सिस्टम में किसी भी जगह से AppConfig ऑब्जेक्ट प्राप्त कर सकते हैं और हमेशा एक ही कॉपी (स्थैतिक के लिए धन्यवाद) प्राप्त कर सकते हैं। वर्ग की init () विधि को निर्माणकर्ता कहा जाता है, जो केवल एक निष्पादन की गारंटी देता है। Init () बॉडी चेक, config $ dataSource का मान और विशिष्ट डेटा स्रोत वर्ग का नया ऑब्जेक्ट बनाता है। अब हमारी स्क्रिप्ट ऑब्जेक्ट प्राप्त कर सकती है और उस पर काम कर सकती है, न कि यह भी कि कौन सा विशिष्ट कार्यान्वयन वास्तव में मौजूद है।

Answer 9

मैं सामान्य रूप से एक एकल con.php फ़ाइल बनाता हूं जिसमें मेरा डेटाबेस कनेक्शन है। फिर मैं उस फाइल को उन सभी फाइलों में शामिल करता हूं जिनके लिए डेटाबेस क्वेश्चन की आवश्यकता होती है।

Comments

मुझे पता है कि, लेकिन आप अपनी डेटा बेस फ़ाइल को वेरिएबल या कास्ट के साथ कैसे बचा सकते हैं? और क्यों?

— अली अकबर अज़ीज़ी

Answer 10

यहाँ मेरा रास्ता है।

<?php

define('DEBUG',0);

define('PRODUCTION',1);



#development_mode : DEBUG / PRODUCTION

$development_mode = PRODUCTION;



#Website root path for links

$app_path = 'http://192.168.0.234/dealer/';



#User interface files path

$ui_path = 'ui/';

#Image gallery path

$gallery_path = 'ui/gallery/';


$mysqlserver = "localhost";
$mysqluser = "root";
$mysqlpass = "";
$mysqldb = "dealer_plus";

?>

किसी भी संदेह टिप्पणी कृपया

Comments

हैलो! क्या आप उपयोग का उदाहरण रख सकते हैं? धन्यवाद

— निक