Django 2.1 - Uploaded Files and Upload Handlers

अपलोड की गई फ़ाइलें और अपलोड हैंडलर




django

अपलोड की गई फ़ाइलें और अपलोड हैंडलर

अपलोड की गई फाइलें

class UploadedFile [source]

फ़ाइल अपलोड के दौरान, वास्तविक फ़ाइल डेटा request.FILES में संग्रहीत किया जाता है। इस शब्दकोश में प्रत्येक प्रविष्टि एक UploadedFile ऑब्जेक्ट (या एक उपवर्ग) है - एक अपलोड की गई फ़ाइल के चारों ओर एक साधारण आवरण। आप आमतौर पर अपलोड की गई सामग्री तक पहुंचने के लिए इनमें से किसी एक तरीके का उपयोग करेंगे:

UploadedFile.read()

फ़ाइल से पूरा अपलोड किया गया डेटा पढ़ें। इस विधि से सावधान रहें: यदि अपलोड की गई फ़ाइल बहुत बड़ी है, तो यदि आप इसे मेमोरी में पढ़ने की कोशिश करते हैं, तो यह आपके सिस्टम को प्रभावित कर सकता है। आप शायद इसके बजाय chunks() का उपयोग करना चाहेंगे; निचे देखो।

UploadedFile.multiple_chunks(chunk_size=None)

यदि अपलोड की गई फ़ाइल कई चंक्स में पढ़ने की आवश्यकता के लिए पर्याप्त है, तो True है। डिफ़ॉल्ट रूप से यह 2.5 मेगाबाइट से बड़ी कोई भी फ़ाइल होगी, लेकिन यह कॉन्फ़िगर करने योग्य है; निचे देखो।

UploadedFile.chunks(chunk_size=None)

एक जनरेटर फ़ाइल का हिस्सा लौट रहा है। यदि multiple_chunks() True , तो आपको read() बजाय लूप में इस विधि का उपयोग करना चाहिए read()

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

यहाँ UploadedFile कुछ उपयोगी गुण दिए गए हैं:

UploadedFile.name

अपलोड की गई फ़ाइल का नाम (जैसे my_file.txt )।

UploadedFile.size

आकार, बाइट्स में, अपलोड की गई फ़ाइल का।

UploadedFile.content_type

फ़ाइल के साथ अपलोड की गई सामग्री-प्रकार के हेडर (जैसे पाठ / सादा या एप्लिकेशन / पीडीएफ )। उपयोगकर्ता द्वारा दिए गए किसी भी डेटा की तरह, आपको भरोसा नहीं करना चाहिए कि अपलोड की गई फ़ाइल वास्तव में इस प्रकार है। आपको अभी भी यह सत्यापित करने की आवश्यकता होगी कि फ़ाइल में वह सामग्री है जो सामग्री-प्रकार के हेडर का दावा करती है - "भरोसा करें लेकिन सत्यापित करें।"

UploadedFile.content_type_extra

एक शब्दकोष जिसमें अतिरिक्त पैरामीटर होते हैं, जो content-type हेडर पर जाता है। यह आमतौर पर Google App Engine जैसी सेवाओं द्वारा प्रदान किया जाता है, जो आपकी ओर से फ़ाइल अपलोड को इंटरसेप्ट और हैंडल करते हैं। परिणामस्वरूप आपके हैंडलर को अपलोड की गई फ़ाइल सामग्री प्राप्त नहीं हो सकती है, लेकिन इसके बजाय फ़ाइल के लिए एक URL या अन्य पॉइंटर। ( आरएफसी 2388 खंड 5.3 देखें)।

UploadedFile.charset

पाठ / * सामग्री-प्रकारों के लिए, ब्राउज़र द्वारा प्रदत्त वर्ण सेट (यानी utf8 )। फिर से, "विश्वास लेकिन सत्यापित करें" यहां सबसे अच्छी नीति है।

ध्यान दें

नियमित पायथन फ़ाइलों की तरह, आप अपलोड की गई फ़ाइल पर पुनरावृत्ति करके फ़ाइल लाइन-बाय-लाइन को पढ़ सकते हैं:

for line in uploadedfile:
    do_something_with(line)

यूनिवर्सल न्यूलाइन्स का उपयोग करके लाइनों को विभाजित किया जाता है । निम्नलिखित को एक पंक्ति को समाप्त करने के रूप में पहचाना जाता है: यूनिक्स एंड-ऑफ-लाइन कन्वेंशन '\n' , विंडोज कन्वेंशन '\r\n' , और पुराने मैकिन्टोश सम्मेलन '\r'

UploadedFile उपवर्गों में शामिल हैं:

class TemporaryUploadedFile [source]

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

TemporaryUploadedFile.temporary_file_path() [source]

अस्थायी अपलोड की गई फ़ाइल का पूरा पथ लौटाता है।

class InMemoryUploadedFile [source]

मेमोरी में अपलोड की गई फ़ाइल (यानी स्ट्रीम-टू-मेमोरी)। इस वर्ग का उपयोग MemoryFileUploadHandler द्वारा किया जाता है।

अंतर्निहित अपलोडर

साथ में MemoryFileUploadHandler और TemporaryFileUploadHandler Django की डिफॉल्ट फाइल अपलोड को मेमोरी में छोटी फाइलों और डिस्क पर बड़ी फ़ाइलों को पढ़ने का व्यवहार प्रदान करते हैं। वे django.core.files.uploadhandler में स्थित हैं।

class MemoryFileUploadHandler [source]

फ़ाइल अपलोड करने वाले को मेमोरी में अपलोड करने के लिए स्ट्रीम करें (छोटी फ़ाइलों के लिए उपयोग किया जाता है)।

class TemporaryFileUploadHandler [source]

हैंडलर अपलोड करें जो TemporaryUploadedFile का उपयोग करके एक अस्थायी फ़ाइल में डेटा स्ट्रीम करता है।

कस्टम अपलोड हैंडलर लिखना

class FileUploadHandler [source]

सभी फ़ाइल अपलोड हैंडलर django.core.files.uploadhandler.FileUploadHandler उपवर्ग होने चाहिए। आप अपनी इच्छानुसार अपलोड हैंडलर को परिभाषित कर सकते हैं।

आवश्यक विधियाँ

कस्टम फ़ाइल अपलोड संचालकों को निम्नलिखित विधियों को परिभाषित करना चाहिए :

FileUploadHandler.receive_data_chunk(raw_data, start) [source]

फ़ाइल अपलोड से डेटा का एक "हिस्सा" प्राप्त करता है।

raw_data एक बाइट स्ट्रिंग है जिसमें अपलोड किया गया डेटा है।

start फ़ाइल में वह स्थिति है जहाँ यह raw_data chunk आरंभ होती है।

आपके द्वारा वापस लौटाए गए डेटा को बाद के अपलोड हैंडलर के ' receive_data_chunk तरीकों से receive_data_chunk किया जाएगा। इस तरह, एक हैंडलर अन्य हैंडलर के लिए "फ़िल्टर" हो सकता है।

इस receive_data_chunk को receive_data_chunk करने से receive_data_chunk को शॉर्ट-सर्किट शेष प्राप्त करने के लिए receive_data_chunk से None लौटाएं। यदि आप अपलोड किए गए डेटा को स्वयं संग्रहीत कर रहे हैं और भविष्य के हैंडलर को डेटा की एक प्रति संग्रहीत नहीं करना चाहते हैं तो यह उपयोगी है।

यदि आप एक StopUpload या एक SkipFile अपवाद SkipFile हैं, तो अपलोड निरस्त हो जाएगा या फ़ाइल पूरी तरह से छोड़ दी जाएगी।

FileUploadHandler.file_complete(file_size) [source]

जब कोई फ़ाइल अपलोड करना समाप्त हो जाता है तो कॉल किया जाता है

हैंडलर को UploadedFile ऑब्जेक्ट वापस करना चाहिए जो request.FILES में संग्रहीत किया जाएगा। हैंडलर भी यह बताने के लिए None भी None लौट सकते हैं कि UploadedFile ऑब्जेक्ट को बाद के अपलोड हैंडलर से आना चाहिए।

वैकल्पिक तरीके

कस्टम अपलोड हैंडलर निम्नलिखित वैकल्पिक तरीकों या विशेषताओं में से किसी को भी परिभाषित कर सकते हैं:

FileUploadHandler.chunk_size

आकार, बाइट्स में, "चंक्स" Django को मेमोरी में स्टोर करना चाहिए और हैंडलर में फीड करना चाहिए। यही है, यह विशेषता FileUploadHandler.receive_data_chunk में खिलाए गए विखंडू के आकार को नियंत्रित करती है।

अधिकतम प्रदर्शन के लिए चंक का आकार 4 विभाज्य होना चाहिए और आकार में 2 जीबी (2 31 बाइट) से अधिक नहीं होना चाहिए। जब कई हैंडलर द्वारा कई चंक साइज प्रदान किए जाते हैं, तो Django किसी भी हैंडलर द्वारा परिभाषित सबसे छोटे चंक साइज का उपयोग करेगा।

डिफ़ॉल्ट 64 * 2 10 बाइट्स, या 64 KB है।

FileUploadHandler.new_file(field_name, file_name, content_type, content_length, charset, content_type_extra) [source]

कॉलबैक सिग्नलिंग कि एक नई फ़ाइल अपलोड शुरू हो रही है। किसी भी अपलोड हैंडलर को कोई डेटा दिए जाने से पहले इसे कॉल किया जाता है।

field_name फ़ाइल का एक स्ट्रिंग नाम है <input> फ़ील्ड।

file_name ब्राउज़र द्वारा प्रदान किया गया फ़ाइल नाम है।

content_type ब्राउज़र द्वारा प्रदान किया गया MIME प्रकार है - उदाहरण 'image/jpeg'

content_length ब्राउज़र द्वारा दी गई छवि की लंबाई है। कभी-कभी यह प्रदान नहीं किया जाएगा और None होगा।

charset ब्राउज़र द्वारा दिया गया कैरेक्टर सेट (यानी utf8 ) है। content_length तरह, यह कभी-कभी प्रदान नहीं किया जाएगा।

content_type_extra content-type हेडर से फ़ाइल के बारे में अतिरिक्त जानकारी है। UploadedFile.content_type_extra देखें।

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

FileUploadHandler.upload_complete() [source]

कॉलबैक संकेत करता है कि पूरा अपलोड (सभी फाइलें) पूरा हो गया है।

FileUploadHandler.handle_raw_input(input_data, META, content_length, boundary, encoding) [source]

हैंडलर को कच्चे HTTP इनपुट के पार्सिंग को पूरी तरह से ओवरराइड करने की अनुमति देता है।

input_data एक फाइल की तरह ऑब्जेक्ट है जो read() को सपोर्ट करता है।

META request.META के समान ऑब्जेक्ट है। META

content_length input_data में डेटा की लंबाई है। input_data से content_length बाइट्स से अधिक न पढ़ें।

boundary इस अनुरोध के लिए MIME सीमा है।

encoding अनुरोध का encoding है।

यदि आप जारी रखने के लिए अपलोड करना चाहते हैं या (POST, FILES) का टपल चाहते हैं तो None वापस न करें यदि आप सीधे अनुरोध के लिए उपयुक्त नई डेटा संरचनाओं को वापस करना चाहते हैं।