मल्टीपार्ट/फॉर्म-डेटा, फ़ील्ड के लिए डिफ़ॉल्ट वर्णमाला क्या है?

Question

यदि कोई वर्णमाला नहीं दी जाती है तो मल्टीपार्ट/फॉर्म-डेटा को डीकोड करने के लिए डिफ़ॉल्ट एन्कोडिंग का उपयोग करना चाहिए? RFC2388 राज्यों:

4,5 प्रपत्र डेटा

एक बहुखण्डीय/फार्म-डेटा के प्रत्येक भाग में पाठ का वर्णसेट एक सामग्री- प्रकार है माना जाता है। उस स्थिति में जहां फ़ील्ड तत्व टेक्स्ट है, पाठ के लिए वर्णमाला पैरामीटर वर्णित वर्ण एन्कोडिंग इंगित करता है।

उदाहरण के लिए

, जिसमें एक उपयोगकर्ता द्वारा लिखे गए 'जो बकाया है <eu> 100' जहां <eu> यूरो प्रतीक प्रपत्र डेटा हो सकता है के रूप में वापस है एक पाठ क्षेत्र के साथ एक रूप है:

--AaB03x 
content-disposition: form-data; name="field1" 
content-type: text/plain;charset=windows-1250 
content-transfer-encoding: quoted-printable>> 

Joe owes =80100. 
--AaB03x 

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

धन्यवाद!

Answer 1

HTTP 1.1 के लिए डिफ़ॉल्ट वर्णसेट आईएसओ -885 9 -1 (लैटिन 1) है, मुझे लगता है कि यह भी यहां लागू होता है।

3.7.1 कैनॉनिकलाइज़ेशन और पाठ चूक

--snip--

"चारसेट" पैरामीटर वर्ण सेट को परिभाषित करने के लिए मीडिया के कुछ प्रकार के साथ प्रयोग किया जाता है (खंड 3.4) डेटा का जब प्रेषक द्वारा कोई स्पष्ट वर्णमाला पैरामीटर प्रदान नहीं किया जाता है, तो "टेक्स्ट" प्रकार के मीडिया उपप्रकारों को HTTP के माध्यम से प्राप्त होने पर "आईएसओ -885 9 -1" का डिफ़ॉल्ट वर्णमाला मान परिभाषित किया जाता है। चरित्र में डेटा "आईएसओ -885 9 -1" के अलावा सेट करता है या इसके सबसेट को उपयुक्त वर्णसेट मान के साथ लेबल किया जाना चाहिए। संगतता समस्याओं के लिए खंड 3.4.1 देखें।

Answer 2

यह स्पष्ट रूप से HTML5 में बदल गया है (http://dev.w3.org/html5/spec-preview/constraints.html#multipart-form-data देखें)।

गैर-फ़ाइल फ़ील्ड के अनुरूप जेनरेट किए गए मल्टीपार्ट/फॉर्म-डेटा संसाधन के हिस्सों में सामग्री-प्रकार शीर्षलेख निर्दिष्ट नहीं होना चाहिए।

तो चरित्र सेट कहां निर्दिष्ट है? जहां तक ​​मैं एन्कोडिंग एल्गोरिदम से बता सकता हूं, केवल एक ही स्थान _charset_ नामक एक फॉर्म डेटा सेट एंट्री के भीतर है।

यदि आपके फॉर्म में _charset_ नामक एक छिपी हुई इनपुट नहीं है, तो क्या होता है? मैंने क्रोम 28 में इसका परीक्षण किया है, यूटीएफ -8 में एन्कोड किए गए फॉर्म को भेज रहा है और एक आईएसओ -885 9 -1 में भेज रहा है और भेजे गए हेडर और पेलोड का निरीक्षण कर रहा है, और मुझे कहीं भी वर्णमाला नहीं दिखाई दे रही है (भले ही टेक्स्ट एन्कोडिंग निश्चित रूप से बदलती है)। यदि मैं फॉर्म में खाली _charset_ फ़ील्ड शामिल करता हूं, तो Chrome सही वर्णमाला प्रकार के साथ पॉप्युलेट करता है। मुझे लगता है कि किसी सर्वर-साइड कोड को _charset_ फ़ील्ड को समझने के लिए देखना चाहिए?

मैं क्रोम एक्सटेंशन लिखते समय इस समस्या में भाग गया जो FormData ऑब्जेक्ट का XMLHttpRequest.send का उपयोग करता है, जो always gets encoded in UTF-8 no matter what the source document encoding is है।

अनुरोध इकाई शरीर सेट प्रपत्र डेटा के रूप में और utf-8 स्पष्ट वर्ण एन्कोडिंग के रूप के साथ डेटा के साथ बहुखण्डीय/फार्म-डेटा एन्कोडिंग एल्गोरिथ्म चलाने का परिणाम हो।

माइम प्रकार को "मल्टीपार्ट/फॉर्म-डेटा;", यू +0020 स्पेस कैरेक्टर, "सीमा =", और मल्टीपार्ट/फॉर्म-डेटा एन्कोडिंग द्वारा उत्पन्न मल्टीपार्ट/फॉर्म-डेटा सीमा स्ट्रिंग का संयोजन होना चाहिए कलन विधि।

जैसा कि मैंने पहले पाया, charset = utf-8 कहीं भी पोस्ट अनुरोध में निर्दिष्ट नहीं है, जब तक आप के रूप में एक खाली _charset_ क्षेत्र है, जो इस मामले में स्वचालित रूप से "utf- साथ पॉपुलेटेड हो जाएगी शामिल 8 "।

यह चीजों की स्थिति की मेरी समझ है। मैं अपनी धारणाओं में किसी भी सुधार का स्वागत करता हूं!

Answer 3

@owlman द्वारा विस्तृत स्पष्टीकरण के लिए धन्यवाद।

बस कुछ और यहाँ की जानकारी:

अपलोड अनुरोध पेलोड टुकड़ा:

------WebKitFormBoundarydZAwJIasnBbGaUqM 
Content-Disposition: form-data; name="file"; filename="xxx.txt" 
Content-Type: text/plain 

हैं "xxx.txt" इसमें कुछ यूनिकोड वर्ण UTF-8 एन्कोडिंग, राल (4.0 के रूप में उपयोग करते हुए है। 40) इसे सही ढंग से डीकोड नहीं कर सकता है, लेकिन जेट्टी (9.x) कर सकते हैं।

मुझे लगता है कि राल के व्यवहार का कारण यह है कि सामग्री-प्रकार किसी भी एन्कोडिंग को निर्दिष्ट नहीं करता है, इसलिए "ISO8859-1" का उपयोग करके फ़ाइल नाम डीकोड करें, जिसके परिणामस्वरूप खराब वर्ण हो सकते हैं।

https://mail-archives.apache.org/mod_mbox/struts-user/200310.mbox/%3C3FA0395B.1080209@kumachan.net.nz%3E

ऐसा लगता है कि राल के व्यवहार सर्वलेट युक्ति 2.3

के अनुसार है और मैं जिसके लिए इस व्यवहार को बदल सकते http://www.caucho.com/resin-4.0/reference.xtp से किसी भी सेटिंग को नहीं मिल रहा है:

मैं कुछ Googling किया राल।