🎯 ⬛️ 🖨️ CBOR - नया बाइनरी डेटा प्रस्तुति प्रारूप 💖 ☕️ 👩🏿‍🤝‍👩🏽

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

सीबीओआर प्रारूप मानक की आधिकारिक तौर पर अक्टूबर 2013 में IETF द्वारा नई RFC 7049 में घोषणा की गई थी, जिसे Carsten Bormann और Paul Hoffman ने लिखा था। पहले लेखक के नाम को देखते हुए, हम प्रारूप के नाम के लिए संक्षिप्त नाम की उत्पत्ति के लिए एक और कारण मान सकते हैं, लेकिन शायद यह केवल एक संयोग है। CBOR प्रारूप को MIME प्रकार का एप्लिकेशन / कोबरा प्राप्त हुआ।

वर्तमान में, संरचित डेटा का प्रतिनिधित्व करने के लिए संभवतः सभी प्रकार के द्विआधारी प्रारूप हैं, जिनमें से कुछ मानकीकृत, लोकप्रिय और व्यापक रूप से उपयोग किए जाते हैं (उदाहरण के लिए, एएसई 1, संदेशपैक और बीएसओएन के लिए बीईआर और डीईआर)। सभी मौजूदा मानक अपने कार्यों को हल करते हैं, और CBOR कोई अपवाद नहीं है। प्रारूप को सात महत्वपूर्ण आवश्यकताओं के साथ प्रस्तुत किया गया था, और चूंकि मौजूदा प्रारूपों में से कोई भी उन्हें पूरी तरह से संतुष्ट नहीं कर सकता था, इसलिए एक नया बनाया गया था (हाँ, यह तस्वीर को जन्म देती है )।

नए बाइनरी प्रारूप के लिए आवश्यकताएँ

इंटरनेट पर प्रचलित अधिकांश डेटा प्रकार मानकों का अस्पष्ट कोडिंग।
प्रारूप को द्विआधारी प्रतिनिधित्व का उपयोग करके बुनियादी डेटा प्रकारों और संरचनाओं को एनकोड करने में सक्षम होना चाहिए। इसी समय, बिल्कुल सभी डेटा प्रकारों के लिए अद्वितीय कोडिंग की आवश्यकता नहीं है, उदाहरण के लिए, संख्या 7 को एक स्ट्रिंग और एक पूरे के रूप में दोनों का प्रतिनिधित्व किया जा सकता है।
एनकोडर / डिकोडर के लिए एक कॉम्पैक्ट कार्यान्वयन, जो आपको उन कार्यान्वयनों को बनाने की अनुमति देगा जो प्रोसेसर की क्षमताओं और उपलब्ध मेमोरी आकार पर मांग नहीं कर रहे हैं।
प्रारूप में स्वरूपों के परिचित मशीन कार्यान्वयन का उपयोग करना चाहिए (उदाहरण के लिए, पूर्णांक या फ्लोटिंग-पॉइंट संख्या के लिए - IEEE 754)
वर्णन योजना का अभाव।
साथ ही, JSON प्रारूप प्रस्तुत डेटा (ऑब्जेक्ट, एरे, स्ट्रिंग, आदि) का स्व-वर्णन करता है। विवरण योजना की अनुपस्थिति आपको एक सरल और सार्वभौमिक डिकोडर बनाने की अनुमति देती है।
डेटा क्रमांकन जितना संभव हो उतना कॉम्पैक्ट होना चाहिए, लेकिन ए (डी) एनकोडर लिखने की आसानी की कीमत पर नहीं।
एन्कोडेड डेटा की मात्रा के ऊपरी बार के लिए, JSON प्रारूप में प्रस्तुति की मात्रा ली गई है।
प्रारूप सीमित संसाधनों के साथ और भारी मात्रा में डेटा के साथ काम करने वाले अनुप्रयोगों में समान रूप से लागू होना चाहिए।
इसका तात्पर्य यह है कि डेटा को एन्कोडिंग और डिकोड करने पर क्रियान्वयन CPU के लिए समान रूप से मितव्ययी होना चाहिए।
प्रारूप को JSON से डेटा को JSON में बदलने के लिए सभी मौजूदा प्रकारों का समर्थन करना चाहिए।
प्रारूप को एक्स्टेंसिबल होना चाहिए और उन्नत प्रारूप को डिकोडर के पुराने संस्करणों द्वारा सफलतापूर्वक डिकोड किया जाना चाहिए।
यह माना जाता है कि प्रारूप का उपयोग दशकों तक किया जाएगा और एक ही समय में पिछड़े संगतता बनाए रखेंगे, ताकि प्रारूप मानक के भविष्य के संस्करणों को सामान्य रूप से पुराने संस्करणों के लिए डिकोडर द्वारा संसाधित किया जा सके। ताकि यदि कोई अज्ञात एक्सटेंशन मिल जाए, तो संदेश को डिकोड करना अभी भी संभव है।

जैसा कि आप आवश्यकताओं से देख सकते हैं, CBOR JSON डेटा मॉडल पर ध्यान केंद्रित करता है, लेकिन यह सीमित नहीं है, लोकप्रिय डेटा प्रकार जोड़ रहा है और भविष्य में प्रारूप का विस्तार करने की अनुमति देता है।

CBOR विशिष्टता

यह समझने के लिए कि प्रारूप कार्यों को सफलतापूर्वक कैसे हल करता है, और अन्य प्रारूपों के साथ तुलना करने में सक्षम होने के लिए, सीबीओआर प्रारूप में डेटा को एन्कोडिंग करने की प्रक्रिया पर विचार करें।

प्रत्येक डेटा आइटम एक बाइट से शुरू होता है जिसमें डेटा के मुख्य प्रकार और अतिरिक्त जानकारी का विवरण होता है। मुख्य प्रकार 3 सबसे महत्वपूर्ण बिट्स पर कब्जा कर लेता है और इसमें 0 से 7. तक मान हो सकते हैं। अतिरिक्त जानकारी 0 से 31 तक मान प्राप्त कर सकते हैं।

जैसा कि आप दृष्टांत में देख सकते हैं, अतिरिक्त जानकारी के मूल्य में तीन सशर्त श्रेणियां हाइलाइट की गई हैं:

यदि मान 0 से 23 तक है, तो यह मान पूर्णांक के रूप में सीधे उपयोग किया जाता है। उदाहरण के लिए, यदि मुख्य प्रकार एक पूर्णांक है, तो अतिरिक्त जानकारी का मूल्य तत्व का मूल्य है। यदि मुख्य प्रकार एक स्ट्रिंग है, तो यह संख्या स्ट्रिंग की लंबाई को इंगित करती है।
यदि मान 24 से 27 के बीच है, तो बाद के बाइट्स में चर लंबाई का एक पूर्णांक होता है, क्रमशः 1-, 2-, 4- और 8-बाइट गैर-नकारात्मक पूर्णांक। उदाहरण के लिए, यदि मुख्य प्रकार एक पूर्णांक है, तो अगले बाइट्स में इसका मान होता है, और यदि स्ट्रिंग - तो इसकी लंबाई।
मान 31 विशेष है और इंगित करता है कि तत्व की लंबाई परिभाषित नहीं है। उदाहरण के लिए, एक स्ट्रिंग के मामले में, इसका मतलब है कि स्ट्रिंग की लंबाई अज्ञात है।

मान 28-30 मानक के भविष्य के संस्करणों के लिए आरक्षित हैं।

जैसा कि पहले से ही उदाहरणों में दिखाया गया है, मुख्य प्रकार के मूल्य के आधार पर, अतिरिक्त जानकारी का अर्थ एक अलग अर्थ लेता है। बुनियादी डेटा प्रकारों पर विचार करें।

टाइप 0: गैर-नकारात्मक पूर्णांक

अतिरिक्त जानकारी में संख्या के मान शामिल हैं (यदि यह 24 से कम है), तो अन्य मामलों में, अतिरिक्त जानकारी पूर्णांक के आकार को इंगित करती है, जो अनुसरण करेगी। यदि 24 uint8_t , तो 25 uint16_t , 26 uint32_t और 27 uint64_t ।

उदाहरण के लिए, संख्या 16 0x10 पर एन्कोडेड है, और तीन बाइट्स 0x19 , 0x01f4 (500) के अनुक्रम में 500 नंबर है।

टाइप 1: नकारात्मक पूर्णांक

मान टाइप 0 के साथ सादृश्य द्वारा एन्कोड किया गया है, एकमात्र अंतर यह है कि किसी को पूर्ण मूल्य से घटाया जाता है। उदाहरण के लिए, -16 0x2F पर एन्कोड किया 0x2F , और संख्या -500 0x39 , 0x01f3 ( 0x01f3 ) है

टाइप 2: बाइट स्ट्रिंग

एक बाइट स्ट्रिंग के लिए, अतिरिक्त जानकारी बाइट्स में स्ट्रिंग की लंबाई एन्कोड करती है। उदाहरण के लिए, 16-बाइट बाइट स्ट्रिंग के मामले में, यह 0x50 पर टाइप किया जाएगा (टाइप 2, मूल्य 16) 16 बाइट्स के बाद बाइट स्ट्रिंग होता है। और 500 बाइट स्ट्रिंग के लिए, तीन बाइट हैडर है: 0x59 (टाइप 2, मूल्य 25), 0x01f4 (500), इसके बाद 500 बाइट्स स्ट्रिंग डेटा।

टाइप 3: टेक्स्ट स्ट्रिंग

एक टेक्स्ट स्ट्रिंग एक UTF-8 एन्कोडेड यूनिकोड वर्ण स्ट्रिंग है। बाइट स्ट्रिंग के साथ, अतिरिक्त जानकारी बाइट्स में स्ट्रिंग की लंबाई को एन्कोड करती है। JSON प्रारूप के विपरीत, टेक्स्ट स्ट्रिंग को फॉर्म \n या \u000a , आदि में सिंक ट्रांसफर वर्णों से बचने की आवश्यकता नहीं होती है।

टाइप 4: तत्वों की सरणी

स्ट्रिंग के प्रकार के अनुरूप, अतिरिक्त जानकारी सरणी की लंबाई इंगित करती है, लेकिन बाइट्स में नहीं, बल्कि तत्वों की संख्या में। सरणी में तत्वों का एक ही प्रकार का होना जरूरी नहीं है, यह स्ट्रिंग्स, संख्याओं आदि का एक सेट हो सकता है। शीर्ष लेख के बाद, सरणी के तत्व तुरंत अनुसरण करते हैं। उदाहरण के लिए, सरणी [0,"A"] निम्नानुसार एन्कोडेड है:

 82 -   2- , 00 -   0, 61 -    1 , 41 - "A"

टाइप 5: जोड़ी नक्शा (साहचर्य सरणी, हैश, शब्दकोश, JSON ऑब्जेक्ट ...)

यह प्रकार एक कार्ड को परिभाषित करता है, जिसमें "कुंजी" - "मूल्य" जोड़े शामिल हैं। अतिरिक्त जानकारी ऐसी जोड़ियों की संख्या निर्धारित करती है। उदाहरण के लिए, 9 जोड़े का एक कार्ड 0xa9 (टाइप 5 + मान 9) के रूप में एन्कोड किया गया है, इसके बाद तत्वों के 9 जोड़े हैं: पहली कुंजी, पहला मूल्य, दूसरा कुंजी, आदि। चाबियाँ विभिन्न प्रकार की हो सकती हैं, लेकिन एक नियम के रूप में, यह शायद ही कभी मांग में है।

टाइप 6: अन्य आधार प्रकारों के शब्दार्थ टैगिंग

यह प्रकार मानक के विस्तार के लिए व्यापक संभावनाएं खोलता है। अतिरिक्त जानकारी एक पूर्णांक टैग संख्या निर्धारित करती है, जो 0 से 18446744073709551615 पर टैग की एक सीमा को परिभाषित करती है। टैग मूल प्रकार के एक विशिष्ट प्रतिनिधित्व को संदर्भित करता है, जिससे आप समर्थित डेटा प्रकारों का असीमित विस्तार कर सकते हैं।

उदाहरण के लिए, मानक विशेष रूप से बताता है कि टैग 0 RFC 3339 (RFC 4287 द्वारा संशोधित) में वर्णित प्रारूप में एक दिनांक-समय के पाठ स्ट्रिंग को परिभाषित करता है। उदाहरण के लिए, जब एन्कोडिंग समय 1970-01-01T00:00Z हमें मिलता है:

 0 -    0 71 -    17  31 39 37 30 2d 30 31 2d 30 31 54 30 30 3a 30 30 5a -   1970-01-01T00:00Z

कृपया ध्यान दें कि भले ही डिकोडर को पता न हो कि टैग 0 का क्या मतलब है, यह अभी भी डेटा को डीकोड करने में सक्षम होगा, क्योंकि टैग के बाद मूल प्रकार 3 का एक तत्व होता है - एक पाठ स्ट्रिंग।

फिलहाल, कई टैग मानक द्वारा परिभाषित किए गए हैं, आईएएनए टैग की सूची के रखरखाव में लगे हुए हैं, वर्तमान वितरण को यहां देखा जा सकता है

यह 55799 टैग को अलग से ध्यान देने योग्य है, जिसका अर्थ है कि सीबीओआर प्रारूप में डेटा आगे बढ़ता है। वास्तव में, यह कोई पेलोड नहीं ले जाता है, लेकिन, उदाहरण के लिए, जब सीबीओआर प्रारूप में डेटा को किसी फ़ाइल में सहेजा जाता है, तो यह टैग शुरुआत में 0xd9d9f7 अनुक्रम 0xd9d9f7 , जिसे उपयोगिताओं द्वारा फ़ाइल के प्रकार को निर्धारित करने के लिए जादू के मूल्य के रूप में उपयोग किया जा सकता है। इसके अलावा, यह अनुक्रम किसी भी मौजूदा यूनिकोड एनकोडिंग में नहीं पाया जाता है, इसलिए, यह आपको पाठ डेटा से CBOR को जल्दी से भेद करने की अनुमति देता है।

टाइप 7: फ्लोटिंग पॉइंट नंबर और अन्य सरल डेटा प्रकार

यह प्रकार आपको सरल मानों, साथ ही फ़्लोटिंग पॉइंट नंबरों का वर्णन करने की अनुमति देता है। अतिरिक्त जानकारी निम्नलिखित अर्थ का वहन करती है:

0..23 - सरल मान (0 से 23 तक कोड)
24 - साधारण मूल्य (कोड 24 से 255)
25 - IEEE 754 आधा-सटीक फ़्लोटिंग-पॉइंट नंबर (16 बिट्स)
26 - IEEE 754 एकल सटीक फ़्लोटिंग पॉइंट नंबर (32 बिट्स)
27 - IEEE 754 डबल सटीक फ़्लोटिंग पॉइंट नंबर (64 बिट्स)
28-30 - अपरिभाषित
31 - अनिश्चित लंबाई वाले तत्वों के लिए कोड ब्रेक (विराम) रोकें

यह मानक सरल मानों के लिए कई कोड परिभाषित करता है:

20 - मिथ्या
21 - सच
22 - अशक्त
23 - अनिर्धारित

अन्य साधारण मूल्य भी IANA द्वारा पंजीकृत हैं, वर्तमान में सरल मूल्यों की एक सूची यहां उपलब्ध है ।

कुछ मूल प्रकार की अपरिभाषित तत्व लंबाई

चार मूल प्रकार: एक सरणी, एक नक्शा, एक बाइट और एक पाठ स्ट्रिंग में तत्वों के लिए अपरिभाषित मूल्य हो सकता है (जो अतिरिक्त जानकारी में 31 के मूल्य द्वारा निर्दिष्ट किया गया है)। यह आपको एन्कोडिंग तत्वों को शुरू करने की अनुमति देता है जिनकी संख्या अभी भी अज्ञात है। यह डेटा को स्ट्रीम करने वाले अनुप्रयोगों में मांग में हो सकता है।

सरणियों और मानचित्रों के मामले में, तत्व एक के बाद एक का पालन करते हैं, और एक रुकावट कोड का उपयोग पूरा होने का संकेत देने के लिए किया जाता है। सरणी या मानचित्र के अंतिम तत्व के तुरंत बाद, टाइप 7 का एक तत्व अतिरिक्त जानकारी 31 के साथ आता है - यह बाइट 0xFF ।

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

एक उदाहरण:

 5F --      44 --    4  aabbccdd --    43 --    3  eeff99 --    FF -- "break"

डीकोडिंग के बाद, सभी टुकड़ों को एक लाइन में जोड़ दिया जाता है: aabbccddeeff99

कैनोनिकल प्रारूप कार्यान्वयन

CBOR मानक कई नियमों को परिभाषित करता है जो एक ही आउटपुट के उत्पादन के लिए एक ही इनपुट के साथ अलग-अलग कार्यान्वयन की अनुमति देते हैं। हालांकि, यह अभी भी अनुमति है, अगर मानक से विचलन की अनुमति देने के लिए, आवेदन की कुछ आवश्यकताएं हैं, अगर यह आम तौर पर बनाए जा रहे दस्तावेज़ की वैधता का उल्लंघन नहीं करता है।

एन्कोडेड डेटा के लिए सबसे संक्षिप्त प्रतिनिधित्व का उपयोग करना। उदाहरण के लिए, यदि पूर्णांक 500 कूटबद्ध है, तो uint16_t का प्रतिनिधित्व चुना जाना चाहिए, और नहीं, कहना चाहिए, uint64_t । जब नंबर 0.0 एन्कोडिंग किया जाता है 0.0 एनकोडर को एक पूर्णांक प्रकार में बदलना चाहिए, क्योंकि यह अधिक संक्षिप्त प्रतिनिधित्व देगा। यदि एक अस्थायी बिंदु संख्या को महत्वपूर्ण बिट्स को खोए बिना एकल परिशुद्धता के साथ दर्शाया जा सकता है, तो एनकोडर को डबल परिशुद्धता, आदि का उपयोग नहीं करना चाहिए।
साहचर्य सरणियों की कुंजियाँ आरोही क्रम में क्रमबद्ध होनी चाहिए (बाइट प्रकार, छोटी कुंजियाँ पहले जाएं)
यदि संभव हो, तो अनिश्चित लंबाई वाले तत्वों को एक निश्चित लंबाई के साथ बदल दिया जाता है।
विहित कार्यान्वयन में टैग का उपयोग नहीं किया जाना चाहिए, लेकिन टैग के साथ डेटा संसाधित करते समय, उन्हें सहेजना होगा

हैंडलिंग में त्रुटि

सीबीओआर मानक प्रारूप में त्रुटियों से निपटने के लिए एक अलग दृष्टिकोण की अनुमति देता है। त्रुटियों को प्रारूप के साथ ही जोड़ा जा सकता है (अतिरिक्त जानकारी में अज्ञात मान, सरल मान, सरणी तत्वों की गलत संख्या, आदि), और मूल्यों के साथ (उदाहरण के लिए, टेक्स्ट स्ट्रिंग में अमान्य UTF-8 कोड या साहचर्य सरणी में डुप्लिकेट कुंजियाँ )।

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

अन्य द्विआधारी प्रारूपों के साथ तुलना

मानक का पाठ इस बात पर एक तुलनात्मक तालिका प्रदान करता है कि कैसे विभिन्न मौजूदा प्रारूपों में सरणियों को एन्कोड किया गया है। पहले सरणी में दो तत्व होते हैं, एक नेस्टेड सरणी के साथ। अनिश्चित लंबाई का दूसरा सरणी (इसके लिए सशर्त प्रतीक _ उपयोग किया जाता है) में एक नेस्टेड सरणी (परिमित लंबाई का) भी होता है।

 +---------------+-------------------------+-------------------------+ | Format | [1, [2, 3]] | [_ 1, [2, 3]] | +---------------+-------------------------+-------------------------+ | RFC 713 | c2 05 81 c2 02 82 83 | | | | | | | ASN.1 BER | 30 0b 02 01 01 30 06 02 | 30 80 02 01 01 30 06 02 | | | 01 02 02 01 03 | 01 02 02 01 03 00 00 | | | | | | MessagePack | 92 01 92 02 03 | | | | | | | BSON | 22 00 00 00 10 30 00 01 | | | | 00 00 00 04 31 00 13 00 | | | | 00 00 10 30 00 02 00 00 | | | | 00 10 31 00 03 00 00 00 | | | | 00 00 | | | | | | | UBJSON | 61 02 42 01 61 02 42 02 | 61 ff 42 01 61 02 42 02 | | | 42 03 | 42 03 45 | | | | | | CBOR | 82 01 82 02 03 | 9f 01 82 02 03 ff | +---------------+-------------------------+-------------------------+

जैसा कि आप देख सकते हैं, MessagePack और CBOR में सबसे अधिक कॉम्पैक्ट प्रतिनिधित्व है, जबकि केवल BER, UBJSON और CBOR में अनंत दृश्यों को एनकोड करने की क्षमता है।

मौजूदा सीबीओआर कार्यान्वयन

मानक की रिहाई के तुरंत बाद, विभिन्न प्रोग्रामिंग भाषाओं में (डी) एन्कोडर के पहले कार्यान्वयन दिखाई देने लगे। उदाहरण के लिए, C , पर्ल , रूबी , पायथन , जावा , गो, और कई अन्य (हालांकि मैंने जल्दी से जीथब को देखा और मुझे अभी तक कोई जावास्क्रिप्ट कार्यान्वयन नहीं मिला ...)।

ये सभी कार्यान्वयन पूरी तरह से मानक का समर्थन नहीं करते हैं और शायद बहुत अधिक मौजूद हैं या दिखाई देंगे। यह सब पूरी तरह से पुष्टि करता है कि मानक का मुख्य लक्ष्य हासिल किया गया है: (डी) एनकोडर का कार्यान्वयन थोड़ा जटिलता का कार्य है। यह संभावना है कि जल्द ही साक्षात्कार में, प्रोग्रामर एक परीक्षण कार्य के रूप में एक लक्स सीबीओआर डिकोडर को लागू करने के लिए पूछना शुरू कर देंगे।

PS यदि आपको पाठ में त्रुटियां, टाइपोस या गलतियाँ मिलें, तो कृपया मुझे बताएं, मैं इसे ठीक कर दूंगा।

CBOR - नया बाइनरी डेटा प्रस्तुति प्रारूप