मैं सी ++/क्यूटी में multipart/related के लिए एक मूल MIME पार्सर लागू करने का प्रयास कर रहा हूं।एमआईएम आरएफसी "सामग्री-प्रकार" पैरामीटर भ्रम? अस्पष्ट आरएफसी विनिर्देश
अब तक मैं हेडर के लिए कुछ बुनियादी पार्सर कोड लिख रहा हूं, और मैं आरएफसी को पढ़ रहा हूं कि यह सुनिश्चित करने के लिए कि जितना संभव हो सके विनिर्देश के करीब सब कुछ कैसे करें।
से RFC882 धारा 3.1.1:
प्रत्येक हेडर फ़ील्ड ASCII वर्ण की एक एकल, तार्किक पंक्ति के रूप में देखी जा सकती है, एक जिसमें दुर्भाग्य से आरएफसी में एक बात यह है कि मुझे थोड़ी confuses है क्षेत्र का नाम और एक फील्ड-बॉडी। सुविधा के लिए, इस वैचारिक इकाई के फ़ील्ड-बॉडी हिस्से को एकाधिक-रेखा प्रतिनिधित्व में विभाजित किया जा सकता है; यह "फोल्डिंग" कहा जाता है। सामान्य नियम यह है कि जहां भी रैखिक-सफेद-स्थान (केवल एलडब्लूएसपी-वर्ण नहीं), एक सीआरएलएफ हो सकता है, इसके बाद तुरंत एक एलडब्लूएसपी-चार डाला जा सकता है। इस प्रकार, एकल लाइन
ठीक है, तो मैं बस एक हेडर फ़ील्ड पार्स और अगर एक CRLF रैखिक सफेद स्थान के साथ इस प्रकार है, मैं बस एक उपयोगी तरीके से उन एक भी शीर्ष लेख पंक्ति में परिणाम की concat। चलो आगे बढ़ना ...
RFC2045 धारा 5.1 से:
RFC 822 के संवर्धित BNF संकेतन में, इस प्रकार एक Content-Type हैडर क्षेत्र मूल्य परिभाषित किया गया है:
content := "Content-Type" ":" type "/" subtype *(";" parameter) ; Matching of media type and subtype ; is ALWAYS case-insensitive.[ ...]
parameter := attribute "=" value attribute := token ; Matching of attributes ; is ALWAYS case-insensitive. value := token/quoted-string token := 1*<any (US-ASCII) CHAR except SPACE, CTLs, or tspecials>
ओका y। तो ऐसा लगता है अगर आप मानकों के साथ एक Content-Type हैडर निर्दिष्ट करना चाहते हैं, बस इसे इस तरह कार्य करें:
Content-Type: multipart/related; foo=bar; something=else
... और एक ही शीर्ष लेख का एक मुड़ा हुआ संस्करण इस प्रकार दिखाई देगा:
Content-Type: multipart/related;
foo=bar;
something=else
सही बात? अच्छा। जैसा कि मैंने RFC के पढ़ने रखा, मैं RFC2387 धारा 5.1 (उदाहरण) में निम्नलिखित में आए:
Content-Type: Multipart/Related; boundary=example-1
start="<[email protected]>";
type="Application/X-FixedRecord"
start-info="-o ps"
--example-1
Content-Type: Application/X-FixedRecord
Content-ID: <[email protected]>
[data]
--example-1
Content-Type: Application/octet-stream
Content-Description: The fixed length records
Content-Transfer-Encoding: base64
Content-ID: <[email protected]>
[data]
--example-1--
हम्म, यह अजीब है। क्या आप Content-Type शीर्षलेख देखते हैं? इसमें कई पैरामीटर हैं, लेकिन सभी के पास ";" नहीं है पैरामीटर डिलीमीटर के रूप में।
हो सकता है कि मैं सिर्फ RFC के सही ढंग से पढ़ा नहीं था, लेकिन मेरी पार्सर सख्ती से विनिर्देश परिभाषित करता है की तरह काम करता है, type और start-info मापदंडों एक एकल स्ट्रिंग या बुरा, एक पार्सर त्रुटि में परिणाम होगा।
दोस्तों, इस पर आपका क्या विचार है? आरएफसी में सिर्फ एक टाइपो? या किसी को याद किया था?
धन्यवाद!
ऐसे मानकों के साथ काम करते समय, आउटपुट लिखते समय इनपुट पढ़ने और सख्त होने पर आपको सहिष्णु रहना चाहिए। – Gumbo
यह उदाहरणों में एक टाइपो है। पैरामीटर को हमेशा अर्धविरामों के साथ सीमित किया जाना चाहिए, भले ही फोल्ड किया जाए। फोल्डिंग हेडर के अर्थशास्त्र को बदलने के लिए नहीं है, केवल पठनीयता की अनुमति देने के लिए और लाइन लम्बाई प्रतिबंधों वाले सिस्टम के लिए खाते हैं। –
@ रेमी लेबेउ: आप इसे उत्तर के रूप में क्यों नहीं पोस्ट करते हैं, इसलिए मैं इसे स्वीकार कर सकता हूं? मैंने आरएफसी के मूल लेखक से संपर्क करने की कोशिश की, लेकिन उन्होंने अब तक जवाब नहीं दिया। – BastiBen