स्थैतिक भंडारण, प्रसंस्करण और पुनर्प्राप्ति

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



सिस्टम द्वारा हल किए गए कार्य:

- सुविधाजनक फ़ाइल डाउनलोड;

- अतुल्यकालिक छवि प्रसंस्करण की संभावना;

- पूर्वावलोकन के साथ आसान काम;

- निष्पादन से कॉन्फ़िगरेशन को अलग करना।



चलो चलते हैं







सबसे पहले, निम्नलिखित फ़ील्ड के साथ डेटाबेस में एक फ़ाइल तालिका बनाएं: आईडी, नाम, आकार, चौड़ाई, ऊंचाई, is_deleted, is_ready, अद्यतन, बनाई गई।



फ़ाइल डाउनलोड करते समय, सबसे पहले, फ़ाइल तालिका में एक प्रविष्टि बनाई जाएगी। आगे, आईडी के आधार पर, जिस पथ को सहेजने की आवश्यकता है, उसकी गणना की जाएगी।



$number = sprintf('%08d', $id);

$uri = '/' .

substr($number, 0, 2) . '/' .

substr($number, 2, 2) . '/' .

substr($number, 4, 2) . '/' .

$number;









आउटपुट में हमें कुछ ऐसा मिलता है: / 00/47/31/00473161



upd1 Arkadiy_Kulev ने संकेत दिया कि निर्देशिकाओं की गहराई दो स्तरों तक सीमित होनी चाहिए।



upd2 दरअसल, फ़ोल्डरों में चित्रों के बेहतर वितरण के लिए पथ को रिवर्स ऑर्डर में रखना अधिक सही है। यह url है हम इस तरह के / 161/473/00473161 प्राप्त करते हैं। धन्यवाद



ऐसा क्यों किया जाता है?

• file_id इकाई तालिकाओं में एक फ़ील्ड होगा जिसे चित्रों की आवश्यकता होगी ($ उपयोगकर्ता-> avatar_file_id)। यह दृष्टिकोण डेटाबेस में अतिरिक्त प्रश्नों के बिना चित्र के पूर्ण पथ को निर्धारित करने के लिए एक file_id के आधार पर अनुमति देता है।
• हमें व्यवस्थापक पैनल के माध्यम से सभी चित्रों, उपयोगकर्ता और डाउनलोड करने योग्य ऑपरेटरों के साथ काम करने का एक एकीकृत तरीका मिलता है।
• एक फ़ोल्डर संरचना डिस्क पर बनाई गई है ताकि एक फ़ोल्डर में 100 से अधिक सबफ़ोल्डर या फाइलें न हों। हालाँकि यह संख्या 1000 फ़ोल्डरों तक बढ़ाई जा सकती है, बड़ी संख्या के साथ एफएस के साथ काम करना मुश्किल हो सकता है।
• फ़ाइल तालिका एसिंक्रोनस फ़ाइल हैंडलिंग के साथ मदद करती है। यदि हमें अचानक सभी छवियों को किसी अन्य प्रारूप में बदलने या किसी अन्य जोड़तोड़ को करने की आवश्यकता है, तो हम उन छवियों की पहचान करने के लिए is_ready फ़ील्ड का उपयोग कर सकते हैं (या अपना स्वयं का फ़ील्ड जोड़ सकते हैं) जिन्हें हमने पहले ही संसाधित किया है और जिन्हें प्रक्रिया में छोड़ दिया गया है।
• Is_deleted फ़ील्ड के लिए धन्यवाद, छवि विलोपन एसिंक्रोनस रूप से किया जा सकता है। कोड को केवल सही सेट करना चाहिए (इसे ट्रिगर पर लागू करना अधिक सुविधाजनक है), और एक विशेष कलेक्टर इसे हटा देगा (बेशक, आपको इसे लिखने की आवश्यकता है)। इसे ट्रिगर पर लागू किया जा सकता है।

जैसा कि उदाहरण से देखा जा सकता है "00/47/31/00473161", इस दृष्टिकोण के साथ छवियों के संभावित डाउनलोड की संख्या एक अरब तक सीमित है। स्वाभाविक रूप से, कार्यान्वयन चरण में इसे बदलना मुश्किल नहीं है।



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



...

if ($form->isValid()) {

// , Image_Manager

// $_FILE .

...

$im = new Image_Manager($options); //

// 'avatar' ,

$file_id = $im->receive('avatar'); //

$user->avatar_file_id = $file_id;

$user->save()

}







हमने मूल छवि को सहेजा और उपयोगकर्ता को इसकी आईडी दी। लेकिन इसे अभी भी संसाधित करने की आवश्यकता है, और साइट पर प्रदर्शन के लिए कई पूर्वावलोकन आकार बनाना संभव है। आप कई तरीकों से आगे बढ़ सकते हैं, एक बार में चित्र बना सकते हैं या आलसी लोड का उपयोग कर सकते हैं। दूसरी विधि में भी कई विकास विकल्प हैं और इस लेख के दायरे से परे है (लेख के अंत में, लिंक की एक सूची दी गई है, जो इस पद्धति के संभावित कार्यान्वयन का एक उदाहरण देती है)। हम पहले रास्ते से जाएंगे। और बस इसके लिए, $ विकल्प सरणी को image_manager कंस्ट्रक्टर को पास किया जाता है, और स्ट्रिंग "अवतार" को रिवाइव विधि के लिए भेजा जाता है।



थंबनेल बनाने के लिए, आपको साइट और उनके मापदंडों पर अपलोड की गई छवियों के प्रकार के विवरण के साथ एक कॉन्फ़िगरेशन फ़ाइल की आवश्यकता है। उदाहरण के लिए (Zend_Config_Ini प्रारूप का उपयोग करके):



...

[avatar] ; big, medium small

resize.big.OutputFileFormat = jpg

resize.big.keepFrame = true

resize.big.backgroundColor = 240.240.240

resize.big.width = 236

resize.big.height = 177

resize.medium.keepFrame = true

resize.medium.backgroundColor = 240.240.240

resize.medium.width = 144

resize.medium.height = 108

resize.small.keepFrame = true

resize.small.width = 72

resize.small.height = 54

resize.small.roundCorners = false



[user_album_photo]

...









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



पूर्वावलोकन को बचाने के लिए, स्रोत फ़ाइल "00/47/31/00473161" को संग्रहीत करने के लिए समान प्रारूप का उपयोग किया जाता है, लेकिन अंत में एक विशेष हैश जोड़ा जाता है, इस पूर्वावलोकन के मापदंडों के आधार पर गणना की जाती है, परिणामस्वरूप, पथ कुछ इस तरह होगा "/ 00/47/31 / 00473161X228068895288952 .jpg "(फिर, यह सिर्फ एक उदाहरण है, आप इसे अलग तरीके से कर सकते हैं)। यह हैश उन तस्वीरों के लिए एक पूर्वावलोकन के अस्तित्व को निर्धारित करने में मदद करता है जिसमें पैरामीटर बदल गए हैं और, यदि नहीं, तो अनुरोध पर एक चित्र तैयार करें।



यह निष्कर्ष से निपटने के लिए बनी हुई है। सबसे आसान विकल्प एक विशेष छवि सहायक लिखना होगा जो एक यूआरएल सहायक की तरह काम करता है:



// url

$this->image($user->avatar_file_id, 'small', 'avatar')









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



नतीजतन, हमें एक सुविधाजनक कॉन्फ़िगरेशन फ़ाइल मिली, एक लाइन में एक फ़ाइल अपलोड करें और साइट के सभी चित्रों के साथ उपयोगकर्ता-परिभाषित लोगों सहित काम करने का एक एकीकृत तरीका है।



संबंधित लिंक:

http://habrahabr.ru/blogs/nginx/77873/ - यहाँ बहुत मूल्यवान टिप्पणियाँ हैं

http://habrahabr.ru/blogs/nginx/94435/

http://ru.wikipedia.org/wiki/WebDAV - जब स्टेटिक्स को एक अलग सर्वर में स्थानांतरित किया जा रहा है