2013-03-27 4 views
7

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

मैं यह नहीं समझ सकता कि इस संबंध में बाइनरी डेटा कैसे प्रबंधित किया जाता है। मेरा क्लाइंट (फ़ायरफ़ॉक्स) इसे 7 बिट ASCII या किसी भी चीज़ में एन्कोडिंग नहीं करता है, यह केवल कच्चे बाइनरी डेटा भेज रहा है। क्या यह डेटा को मनमानी स्थानों पर लाइनों में विभाजित करता है? मल्टीपार्ट डेटा के लिए निर्दिष्ट अधिकतम लाइन लंबाई है? मैंने मल्टीपार्ट/फॉर्म-डेटा के लिए आरएफसी को देखने का प्रयास किया है, लेकिन कुछ भी नहीं मिला।

उत्तर

7

आरएफसी के माध्यम से खुदाई करने के बाद, मुझे लगता है कि आखिर में मैं इसे सीधे अपने सिर में मिला। शरीर के अंग (यानी, multipart/* संदेश में किसी व्यक्तिगत भाग की बॉडी सामग्री) केवल उस पंक्ति के आधार पर होने की आवश्यकता है जिसमें भाग के अंत में सीमा CR+LF से शुरू होती है। लेकिन अन्यथा, डेटा को लाइन-आधारित नहीं होना चाहिए, और यदि सामग्री में लाइनब्रेक्स होने लगते हैं, तो उनके बीच कोई अधिकतम दूरी नहीं है, न ही उन्हें किसी भी तरह से बचने की आवश्यकता है (ठीक है, जब तक कि Content-Transfer-Encoding उद्धृत नहीं किया गया हो- स्ट्रिंग)। Content-Transfer-Encoding के लिए 7-बिट, 8-बिट और बाइनरी विकल्प वास्तव में इंगित नहीं करते हैं कि डेटा पर कोई भी एन्कोडिंग किया गया है (और इसलिए कोई एन्कोडिंग पूर्ववत करने की आवश्यकता नहीं है), वे केवल डेटा के प्रकार को इंगित करने के लिए हैं आप शरीर के अंग में देखने की उम्मीद कर सकते हैं।

मैं वास्तव में अपने [खराब व्यक्त] प्रश्न में क्या प्राप्त कर रहा था यह था कि सॉकेट से डेटा को कैसे पढ़ा/बफर करना था ताकि मैं सुनिश्चित कर सकूं कि मैंने सीमा पकड़ ली है, और बिना मनमाने ढंग से बड़े बफर (उदाहरण के लिए) , यदि सामग्री में कोई लाइनब्रैक नहीं हुआ है, और इसलिए readline पूरी चीज़ को बफर कर रहा है)।

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

2

RFC 2045 की समीक्षा करने का प्रयास करें। आमतौर पर, बाइनरी सामग्री को आपके एप्लिकेशन द्वारा BASE64 में परिवर्तित किया गया है और "सामग्री-स्थानांतरण-एन्कोडिंग: बेस 64" का उपयोग करके बहु भाग संदेश में शामिल किया गया है। द्विआधारी डेटा स्थानांतरित करने के लिए अन्य तंत्र, लेकिन यह काफी आम है। बाइनरी डेटा ऑक्टेट्स में परिवर्तित हो गया है और आर्बिटरी लम्बाई तारों में घुमाया गया है (एन्कोडिंग संस्करण के आधार पर - ऊपर BASE64 लिंक देखें)। प्राप्तकर्ता फिर इसे मूल बाइनरी सामग्री में डीकोड करता है।

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

+1

धन्यवाद, मैं एक अलग आरएफसी देख रहा था जो जानकारीपूर्ण नहीं था। मुझे आरएफसी 2046 भी मिला जो विशेष रूप से सेक्शन 5 में बहु-भाग वाले संदेशों को परिभाषित करता है। नोट करें कि इन आरएफसी में एक सूक्ष्मता है जो मेरे माध्यम से बंद है: यह कहता है कि मल्टीपार्ट संदेशों में 7-बिट, 8-बिट और बाइनरी के अलावा एन्कोडिंग नहीं हो सकती (यानी, बेस -64 नहीं)। हालांकि, यह कहता है कि बहुभागियों के भीतर अलग-अलग हिस्सों में स्वयं सामग्री-एन्कोडिंग हो सकती है, इसलिए आप सही हैं कि बेस -64 संभव है। – brianmearns

संबंधित मुद्दे