JSON स्ट्रिंग में बाइनरी डेटा। बेस 64 से कुछ बेहतर

613

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

बाइनरी डेटा से बचने के लिए एक स्पष्ट तरीका बेस 64 का उपयोग करना है। हालांकि, बेस 64 में एक उच्च प्रसंस्करण ओवरहेड है। इसके अलावा यह 3 बाइट्स को 4 वर्णों में विस्तारित करता है जो कि लगभग 33% की वृद्धि हुई डेटा आकार की ओर जाता है।

इसके लिए एक उपयोग मामला सीडीएमआई क्लाउड स्टोरेज एपीआई स्पेसिफिकेशन का v0.8 ड्राफ्ट है । आप JSON का उपयोग करके एक REST-Webservice के माध्यम से डेटा ऑब्जेक्ट बनाते हैं, जैसे

PUT /MyContainer/BinaryObject HTTP/1.1
Host: cloud.example.com
Accept: application/vnd.org.snia.cdmi.dataobject+json
Content-Type: application/vnd.org.snia.cdmi.dataobject+json
X-CDMI-Specification-Version: 1.0
{
    "mimetype" : "application/octet-stream",
    "metadata" : [ ],
    "value" :   "TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlz
    IHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3aGljaCBpcyBhIGx1c3Qgb2Yg
    dGhlIG1pbmQsIHRoYXQgYnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB0aGUgY29udGlu
    dWVkIGFuZCBpbmRlZmF0aWdhYmxlIGdlbmVyYXRpb24gb2Yga25vd2xlZGdlLCBleGNlZWRzIHRo
    ZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5hbCBwbGVhc3VyZS4=",
}

बाइनरी डेटा को JSON स्ट्रिंग्स में एन्कोड करने के लिए बेहतर तरीके और मानक तरीके हैं?

json base64

— dmeister
स्रोत

30

अपलोड के लिए: आप इसे केवल एक बार कर रहे हैं, इसलिए यह उतना बड़ा सौदा नहीं है। डाउनलोड के लिए, आप आश्चर्यचकित हो सकते हैं कि gzip के तहत बेस 64 कितनी अच्छी तरह से संपीड़ित होता है , इसलिए यदि आपने gzip को अपने सर्वर पर सक्षम किया है तो आप शायद ठीक हैं।

— मेघावी

2

कट्टर नर्ड के लिए एक और योग्य समाधान msgpack.org : github.com/msgpack/msgpack/blob/master/spec.md

— nicolallias

2

@cloudfeet, एक बार प्रति उपयोगकर्ता प्रति क्रिया । बहुत बड़ी बात है।

— पचेरियर

2

ध्यान दें कि वर्ण आम तौर पर प्रत्येक स्मृति के 2 बाइट्स होते हैं। इस प्रकार, बेस 64 तार पर + 33% (4/3) ओवरहेड दे सकता है, लेकिन उस डेटा को वायर पर डालकर, इसे पुनः प्राप्त करते हुए, और इसका उपयोग करते हुए, ओवरहेड + 166% (8/3) ओवरहेड की आवश्यकता होगी । बिंदु में मामला: यदि एक जावास्क्रिप्ट स्ट्रिंग की अधिकतम लंबाई 100k वर्ण है, तो आप केवल बेस के उपयोग से 37.5k बाइट्स डेटा का प्रतिनिधित्व कर सकते हैं, न कि 75k बाइट्स डेटा का। ये संख्या आवेदन के कई हिस्सों में एक अड़चन हो सकती है, जैसे JSON.parseआदि ......

— पचेरियर

5

@ स्पेसर "आम तौर पर स्मृति के 2 बाइट्स [प्रति चरित्र]" सटीक नहीं है। उदाहरण के लिए v8 में OneByte और TwoByte स्ट्रिंग्स हैं। दो-बाइट स्ट्रिंग्स का उपयोग केवल उन जगहों पर किया जाता है, जहां आवश्यक है कि वे मेमोरी मेमोरी की खपत से बचें। Base64 एक-बाइट स्ट्रिंग्स के साथ एन्कोडेबल है।

— ZachB

459

94 यूनिकोड वर्ण हैं जिन्हें JSON कल्पना के अनुसार एक बाइट के रूप में दर्शाया जा सकता है (यदि आपका JSON UTF-8 के रूप में प्रेषित है)। इस बात को ध्यान में रखते हुए, मुझे लगता है कि आप अंतरिक्ष-वार कर सकते हैं सबसे अच्छा आधार 85 है जो चार बाइट्स को पाँच वर्णों के रूप में प्रस्तुत करता है। हालाँकि, यह बेस 64 पर केवल 7% सुधार है, यह गणना करने के लिए अधिक महंगा है, और कार्यान्वयन बेस 64 की तुलना में कम आम हैं, इसलिए यह शायद जीत नहीं है।

आप बस हर इनपुट बाइट को U + 0000-U + 00FF में संबंधित वर्ण में मैप कर सकते हैं, फिर उन वर्णों को पास करने के लिए JSON मानक द्वारा आवश्यक न्यूनतम एन्कोडिंग करें; यहां लाभ यह है कि आवश्यक डिकोडिंग बिलिन कार्यों से परे शून्य है, लेकिन अंतरिक्ष दक्षता खराब है - एक 105% विस्तार (यदि सभी इनपुट बाइट्स समान रूप से होने की संभावना है) बनाम बेस 85 के लिए 25% या बेस 64 के लिए 33% है।

अंतिम निर्णय: आधार 64 जीतता है, मेरी राय में, इस आधार पर कि यह आम है, आसान है, और बहुत बुरा नहीं है वारंट प्रतिस्थापन के लिए।

इसे भी देखें: Base91 और Base122

— हॉब्स
स्रोत

5

प्रतीक्षा करें कि कैसे बोली पात्रों को 105% विस्तार और केवल 64% base64 एन्कोडिंग करते समय वास्तविक बाइट का उपयोग कर रहा है? Base64 133% नहीं है?

— jjxtra

17

Base91 JSON के लिए बुरा विचार है, क्योंकि इसमें वर्णमाला में उद्धरण है। JSON एन्कोडिंग के बाद सबसे खराब स्थिति में (सभी उद्धरण आउटपुट), यह मूल पेलोड का 245% है।

— जर्नोह

25

पायथन 3.4 में अभी base64.b85encode()और शामिल b85decode()हैं। एक साधारण एनकोड + डीकोड टाइमिंग माप से पता चलता है कि b85, b64 की तुलना में 13 गुना अधिक धीमा है। इसलिए हमारे पास 7% आकार की जीत है, लेकिन 1300% प्रदर्शन हानि है।

— पीटर एनएएस

3

@hobbs JSON कहता है कि नियंत्रण-पात्रों को बच जाना चाहिए। RFC20 खंड 5.2DEL एक नियंत्रण चरित्र होने को परिभाषित करता है।

— तिनो

2

@Tino ECMA-404 विशेष रूप से उन पात्रों को सूचीबद्ध करता है जिन्हें भागने की आवश्यकता है: दोहरे उद्धरण U + 0022, बैकस्लैश U + 005C, और "नियंत्रण वर्ण U + 0000 से U + 001F"।

— हॉब्स

249

मैं एक ही समस्या में भाग गया, और सोचा कि मैं एक समाधान साझा करूंगा: मल्टीपार्ट / फॉर्म-डेटा।

एक मल्टीपार्ट फॉर्म भेजकर आप अपने JSON मेटा-डेटा को स्ट्रिंग के रूप में पहले भेजते हैं , और फिर सामग्री-विवाद नाम से अनुक्रमित कच्चे बाइनरी (छवि), wavs, आदि के रूप में भेजते हैं ।

यहाँ कैसे obj-c में यह करने के लिए एक अच्छा ट्यूटोरियल है , और यहाँ एक ब्लॉग लेख है जो बताता है कि स्ट्रिंग डेटा को प्रपत्र सीमा के साथ कैसे विभाजित किया जाए, और इसे बाइनरी डेटा से अलग किया जाए।

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

दी गई यह सर्वर साइड पर अतिरिक्त काम की आवश्यकता है, लेकिन अगर आप कई चित्र या बड़ी छवियां भेज रहे हैं, तो यह इसके लायक है। अगर आप चाहें तो इसे गज़िप कंप्रेशन के साथ मिला दें।

बेस 64 इनकोडिंग डेटा भेजने वाला IMHO एक हैक है; RFC मल्टीपार्ट / फॉर्म-डेटा इस तरह के मुद्दों के लिए बनाया गया था: पाठ या मेटा-डेटा के संयोजन में बाइनरी डेटा भेजना।

— Ælex
स्रोत

4

वैसे, Google ड्राइव API इस तरह से कर रहा है: Developers.google.com/drive/v2/reference/files/update#examples

— Mathias Conradt

2

जब यह गोल (बाइनरी) खूंटे को एक वर्ग (ASCII) छेद में निचोड़ने की कोशिश करने के बजाय देशी सुविधाओं का उपयोग करता है तो इसका उत्तर इतना कम क्यों है? ...

— मार्क के कोवान

5

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

— t3chb0t

4

@ t3chb0t मल्टीपार्ट / फॉर्म-डेटा मीडिया प्रकार, फॉर्म डेटा ट्रांसपोर्ट करने के लिए पैदा हुआ था, लेकिन आज इसे HTTP / HTML दुनिया के बाहर व्यापक रूप से उपयोग किया जाता है, विशेष रूप से ईमेल सामग्री को एनकोड करने के लिए। आज यह एक सामान्य एन्कोडिंग सिंटैक्स के रूप में प्रस्तावित है। tools.ietf.org/html/rfc7578

— lorenzo

3

@MarkKCowan संभवत: क्योंकि यह प्रश्न के उद्देश्य के लिए सहायक है, यह पूछे गए प्रश्न का उत्तर नहीं देता है, जो प्रभावी रूप से "JSON में उपयोग के लिए पाठ एन्कोडिंग के लिए कम ओवरहेड बाइनरी" है, यह उत्तर JSON को पूरी तरह से खोद देता है।

— चिनोटो वोक्रो

34

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

एक परिणाम के रूप में, यदि रेंज में एक बाइट मान एन्कोडिंग [0..127] UTF-8 एन्कोडिंग में केवल एक बाइट की आवश्यकता होगी, तो रेंज में एक बाइट मान [128..255] को 2 बाइट की आवश्यकता होगी! इससे भी बदतर। JSON में, नियंत्रण वर्ण, "और \" को एक स्ट्रिंग में प्रदर्शित होने की अनुमति नहीं है। इसलिए द्विआधारी डेटा को कुछ परिवर्तन करने की आवश्यकता होगी ताकि इसे ठीक से कूटा जा सके।

देखते हैं। यदि हम अपने बाइनरी डेटा में समान रूप से वितरित यादृच्छिक बाइट मान लेते हैं, तो औसतन, आधे बाइट्स एक बाइट्स में और दूसरे आधे दो बाइट्स में एन्कोड किए जाएंगे। UTF-8 एन्कोडेड बाइनरी डेटा में प्रारंभिक आकार का 150% होगा।

Base64 एन्कोडिंग केवल प्रारंभिक आकार के 133% तक बढ़ता है। इसलिए Base64 एन्कोडिंग अधिक कुशल है।

एक और बेस एन्कोडिंग का उपयोग करने के बारे में क्या? UTF-8 में, 128 ASCII मूल्यों को एन्कोडिंग सबसे अधिक कुशल है। 8 बिट्स में आप 7 बिट्स स्टोर कर सकते हैं। इसलिए अगर हम UTF-8 एन्कोडेड स्ट्रिंग के प्रत्येक बाइट में स्टोर करने के लिए 7 बिट चंक्स में बाइनरी डेटा को काटते हैं, तो एन्कोडेड डेटा केवल प्रारंभिक आकार का 114% हो जाएगा। बेस 64 से बेहतर है। दुर्भाग्य से हम इस आसान चाल का उपयोग नहीं कर सकते क्योंकि JSON कुछ ASCII वर्णों की अनुमति नहीं देता है। ASCII के 33 नियंत्रण वर्ण ([0..31] और 127) और "और \" को बाहर रखा जाना चाहिए। यह हमें केवल 128-35 = 93 वर्ण छोड़ देता है।

इसलिए सिद्धांत रूप में हम एक Base93 एन्कोडिंग को परिभाषित कर सकते हैं जो एन्कोडेड आकार को 8 / log2 (93) = 8 * log10 (2) / log10 (93) = 122% तक बढ़ा देगा। लेकिन एक Base93 एन्कोडिंग एक Base64 एन्कोडिंग के रूप में सुविधाजनक नहीं होगा। Base64 को 6 बिट चंक्स में इनपुट बाइट अनुक्रम को काटने की आवश्यकता होती है, जिसके लिए सरल बिटवाइज़ ऑपरेशन अच्छी तरह से काम करता है। 133% के अलावा 122% से अधिक नहीं है।

यही कारण है कि मैं स्वतंत्र रूप से इस निष्कर्ष पर पहुंचा कि बेस 64 वास्तव में JSON में बाइनरी डेटा को एनकोड करने का सबसे अच्छा विकल्प है। मेरा जवाब इसके लिए एक औचित्य प्रस्तुत करता है। मैं मानता हूं कि यह प्रदर्शन के दृष्टिकोण से बहुत आकर्षक नहीं है, लेकिन JSON का उपयोग करने के लाभ पर भी विचार करें क्योंकि यह मानव पठनीय स्ट्रिंग प्रतिनिधित्व सभी प्रोग्रामिंग भाषाओं में हेरफेर करना आसान है।

यदि प्रदर्शन शुद्ध बाइनरी एन्कोडिंग से महत्वपूर्ण है, तो इसे JSON के प्रतिस्थापन के रूप में माना जाना चाहिए। लेकिन JSON के साथ मेरा निष्कर्ष यह है कि Base64 सबसे अच्छा है।

— chmike
स्रोत

Base128 के बारे में क्या है, लेकिन फिर JSON के धारावाहिक को "और \" से बचने की अनुमति देता है; मुझे लगता है कि उपयोगकर्ता को json parser कार्यान्वयन का उपयोग करना उचित है।

— jcalfee314

1

@ jcalfee314 दुर्भाग्य से यह संभव नहीं है क्योंकि JSON तार में 32 से नीचे ASCII कोड के साथ चार्ट की अनुमति नहीं है। 64 और 128 के बीच एक आधार के साथ एन्कोडिंग पहले से ही परिभाषित किया गया है, लेकिन आवश्यक गणना बेस 64 से अधिक है। एन्कोडेड पाठ आकार में लाभ इसके लायक नहीं है।

— चिकमैक

यदि आधार64 में बड़ी मात्रा में छवियां लोड हो रही हैं (चलो 1000 कहते हैं), या वास्तव में धीमे कनेक्शन पर लोड हो रहा है, तो क्या बेस85 या बेस 93 कभी कम नेटवर्क ट्रैफ़िक (w / या w / o gzip) के लिए भुगतान करेगा? मैं उत्सुक हूँ अगर वहाँ एक बिंदु आता है जहाँ अधिक कॉम्पैक्ट डेटा वैकल्पिक तरीकों में से एक के लिए एक मामला बना देगा।

— 197 पर vol7ron

मुझे संदेह है कि गणना की गति संचरण समय से अधिक महत्वपूर्ण है। छवियां स्पष्ट रूप से सर्वर साइड पर होनी चाहिए। वैसे भी, निष्कर्ष यह है कि JSON द्विआधारी डेटा के लिए खराब है।

— चमीक

" Base64 एन्कोडिंग केवल प्रारंभिक आकार के 133% तक बढ़ता है इसलिए Base64 एन्कोडिंग अधिक कुशल है ", यह पूरी तरह से गलत है क्योंकि वर्ण आमतौर पर 2 बाइट हैं। पर विस्तार देखें stackoverflow.com/questions/1443158/...

— Pacerier

34

BSON (बाइनरी JSON) आपके लिए काम कर सकता है। http://en.wikipedia.org/wiki/BSON

संपादित करें: अगर आप कुछ C # सर्वर साइड लव की तलाश में हैं तो FYI .NET .NET json.net पढ़ने और लिखने का समर्थन करता है।

— DarcyThomas
स्रोत

1

"कुछ मामलों में, BSON लंबाई उपसर्गों और स्पष्ट सरणी सूचकांकों के कारण JSON से अधिक स्थान का उपयोग करेगा।" en.wikipedia.org/wiki/BSON

— पावेल किओच

अच्छी खबर: BSON मूल रूप से बाइनरी, डेटाटाइम, और कुछ अन्य (विशेष रूप से उपयोगी है यदि आप MongoDB का उपयोग कर रहे हैं) जैसे प्रकारों का समर्थन करते हैं। बुरी खबर: यह एन्कोडिंग बाइनरी बाइट्स है ... इसलिए यह ओपी के लिए एक गैर-जवाब है। हालाँकि यह एक ऐसे चैनल पर उपयोगी होगा जो बाइनरी को मूल रूप से RabbitMQ संदेश, ZeroMQ संदेश या एक कस्टम TCP या UDP सॉकेट जैसे समर्थन करता है।

— डैन एच

19

यदि आप बैंडविड्थ समस्याओं से निपटते हैं, तो पहले क्लाइंट की तरफ डेटा को संपीड़ित करने का प्रयास करें, फिर बेस 64-यह।

इस तरह के जादू का अच्छा उदाहरण http://jszip.stuartk.co.uk/ पर है और इस विषय पर अधिक चर्चा Gzip के जावास्क्रिप्ट कार्यान्वयन पर है

— andrej
स्रोत

2

यहाँ एक जावास्क्रिप्ट ज़िप कार्यान्वयन है जो बेहतर प्रदर्शन का दावा करता है: zip.js

— Janus Troelsen

ध्यान दें कि आप कर सकते हैं (और चाहिए) अभी भी के रूप में अच्छी तरह से (आमतौर पर Content-Encoding) के बाद संपीड़ित , बेस 64 बहुत अच्छी तरह से संपीड़ित करता है।

— महमूद अल-कुद्सी

@ MahmoudAl-Qudsi का मतलब है कि आपने बेस 64 (ज़िप (बेस 64 (जिप)))))? मुझे यकीन नहीं है कि एक और ज़िप जोड़ना और फिर इसे आधार 64 (डेटा के रूप में भेजने में सक्षम होना) अच्छा विचार है।

— andrej

18

आप के लिए काम कर सकते हैं:

http://en.wikipedia.org/wiki/Yenc

"yEnc बाइनरी फ़ाइलों को [पाठ] में स्थानांतरित करने के लिए एक बाइनरी-टू-टेक्स्ट एन्कोडिंग योजना है। यह 8-बिट विस्तारित ASCII एन्कोडिंग विधि का उपयोग करके पिछले US-ASCII-आधारित एन्कोडिंग विधियों पर ओवरहेड को कम करता है। yEnc का ओवरहेड अक्सर (यदि है) प्रत्येक बाइट मान औसतन एक ही आवृत्ति के साथ लगभग 1) 2% है, जबकि uuencode और Base64 जैसे 6-बिट एन्कोडिंग विधियों के लिए 33% -40% ओवरहेड की तुलना में कम दिखाई देता है। ... 2003 तक yEnc डी फैक्टर मानक बन गया। यूज़नेट पर बाइनरी फ़ाइलों के लिए एन्कोडिंग सिस्टम। "

हालाँकि, yEnc एक 8-बिट एन्कोडिंग है, इसलिए इसे JSON स्ट्रिंग में संग्रहीत करने में मूल बाइनरी डेटा को संग्रहीत करने के समान समस्याएं हैं - इसे भोले तरीके से करने का मतलब लगभग 100% विस्तार है, जो कि बेस 64 से भी बदतर है।

— richardtallent
स्रोत

42

चूंकि बहुत से लोग अभी भी इस सवाल को देख रहे हैं, मैं यह उल्लेख करना चाहूंगा कि मुझे नहीं लगता कि वास्तव में यहाँ मदद मिलती है। yEnc एक 8-बिट एन्कोडिंग है, इसलिए इसे JSON स्ट्रिंग में संग्रहीत करने में मूल बाइनरी डेटा को संग्रहीत करने के समान समस्याएं हैं - इसे भोले तरीके से करने का मतलब लगभग 100% विस्तार है, जो कि बेस 64 से भी बदतर है।

— हॉब्स

ऐसे मामलों में जब JSON डेटा के साथ बड़े अक्षर वाले yEnc जैसे एन्कोडिंग का उपयोग स्वीकार्य माना जाता है, escapeless निश्चित ज्ञात-इन-एडवांस ओवरहेड प्रदान करने वाले एक अच्छे विकल्प के रूप में काम कर सकता है।

— इवान कोसारेव

10

हालांकि यह सच है कि बेस 64 में ~ 33% विस्तार दर है, यह जरूरी नहीं है कि प्रसंस्करण ओवरहेड इस से काफी अधिक है: यह वास्तव में JSON लाइब्रेरी / टूलकिट पर निर्भर करता है जिसका आप उपयोग कर रहे हैं। एन्कोडिंग और डिकोडिंग सरल सीधे-आगे के संचालन हैं, और उन्हें अनुकूलित वर्ण वर्ण एन्कोडिंग भी किया जा सकता है (क्योंकि JSON केवल UTF-8/16/32 का समर्थन करता है) - बेस 64 अक्षर JSON स्ट्रिंग प्रविष्टियों के लिए हमेशा एकल-बाइट होते हैं। उदाहरण के लिए जावा प्लेटफॉर्म पर ऐसी लाइब्रेरी हैं जो काम को कुशलता से कर सकती हैं, ताकि ओवरहेड ज्यादातर विस्तारित आकार के कारण हो।

मैं पहले के दो उत्तरों से सहमत हूँ:

बेस 64 सरल है, आमतौर पर उपयोग किया जाने वाला मानक है, इसलिए इसे JSON के साथ उपयोग करने के लिए विशेष रूप से कुछ बेहतर मिलने की संभावना नहीं है (बेस -85 का उपयोग पोस्टस्क्रिप्ट आदि द्वारा किया जाता है, लेकिन लाभ तब सबसे अच्छा होता है जब आप इसके बारे में सोचते हैं)
एन्कोडिंग से पहले संपीड़न (और डिकोडिंग के बाद) आपके द्वारा उपयोग किए गए डेटा के आधार पर बहुत सारी समझ बना सकता है

— StaxMan
स्रोत

10

मुस्कान का प्रारूप

यह सांकेतिक शब्दों में बदलना, डिकोड और कॉम्पैक्ट करने के लिए बहुत तेज़ है

गति तुलना (जावा आधारित लेकिन सार्थक फिर भी): https://github.com/eishay/jvm-serializers/wav/

इसके अलावा यह JSON का एक विस्तार है जो आपको बाइट सरणियों के लिए बेस 64 एन्कोडिंग को छोड़ने की अनुमति देता है

अंतरिक्ष महत्वपूर्ण होने पर स्माइल एनकोडिंग स्ट्रिंग्स को जिप किया जा सकता है

— स्टेफानो फ्रेटिनी
स्रोत

3

... और लिंक मर चुका है। यह एक अप-टू-डेट लगता है: github.com/FasterXML/smile-format-specification

— ज़ीरो 3

4

( 7 साल बाद संपादित करें: Google गियर्स समाप्त हो गया है। इस उत्तर को अनदेखा करें।)

Google गियर्स टीम अभाव-बाइनरी-डेटा-प्रकार की समस्या में भाग गई और इसे संबोधित करने का प्रयास किया है:

बूँद एपीआई

जावास्क्रिप्ट में टेक्स्ट स्ट्रिंग्स के लिए एक अंतर्निहित डेटा प्रकार है, लेकिन बाइनरी डेटा के लिए कुछ भी नहीं है। Blob ऑब्जेक्ट इस सीमा को संबोधित करने का प्रयास करता है।

शायद आप किसी भी तरह से बुनाई कर सकते हैं।

— एक पेड nerd
स्रोत

तो जावास्क्रिप्ट और जैसन में ब्लब्स की स्थिति क्या है? क्या इसे गिरा दिया गया है?

— 15

w3.org/TR/FileAPI/#blob-section स्पेस के लिए बेस 64 के रूप में परफॉर्मेंट नहीं है, अगर आप नीचे स्क्रॉल करते हैं तो आप पाते हैं कि यह utf8 मैप का उपयोग करते हुए एनकोड करता है (हॉब्स द्वारा दिए गए विकल्प में से एक के रूप में "यह उत्तर)। और कोई जोंस का समर्थन नहीं, जहां तक मुझे पता है

— Daniele Cruciani

3

चूंकि आप बाइनरी डेटा को एक कड़ाई से पाठ-आधारित और बहुत सीमित प्रारूप में जूता करने की क्षमता की तलाश कर रहे हैं, मुझे लगता है कि बेस 64 का ओवरहेड उस सुविधा की तुलना में कम से कम है जिसे आप JSON के साथ बनाए रखने की अपेक्षा कर रहे हैं। यदि पावर और थ्रूपुट को संसाधित करना एक चिंता का विषय है, तो आपको संभवतः अपने फ़ाइल स्वरूपों पर पुनर्विचार करना होगा।

— jsoverson
स्रोत

2

सिर्फ चर्चा के लिए संसाधन और जटिलता के दृष्टिकोण को जोड़ने के लिए। नए संसाधनों को संग्रहीत करने और उन्हें बदलने के लिए PUT / POST और PATCH करने के बाद से, किसी को यह याद रखना चाहिए कि सामग्री हस्तांतरण एक संग्रहीत सामग्री का सटीक प्रतिनिधित्व है और जो एक GET ऑपरेशन जारी करके प्राप्त की जाती है।

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

और हाँ JSON कुछ अपंग है लेकिन अंत में JSON स्वयं क्रिया है। और BASE64 के लिए मैपिंग का ओवरहेड छोटे का एक तरीका है।

मल्टी-पार्ट संदेशों का सही तरीके से उपयोग करने के लिए या तो भेजने के लिए ऑब्जेक्ट को विघटित करना पड़ता है, एक संपत्ति पथ का उपयोग करें स्वचालित संयोजन के लिए पैरामीटर नाम या केवल पेलोड को व्यक्त करने के लिए एक और प्रोटोकॉल / प्रारूप बनाने की आवश्यकता होगी।

BSON के दृष्टिकोण को पसंद करते हुए, यह व्यापक रूप से और आसानी से समर्थित नहीं है क्योंकि यह इसे पसंद करेगा।

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

— मार्टिन केर्स्टन
स्रोत

1

मैं थोड़ा और खोदता हूं ( बेस128 के कार्यान्वयन के दौरान ), और यह उजागर करता हूं कि जब हम ऐसे अक्षर भेजते हैं जो ascii कोड 128 से बड़े होते हैं तो ब्राउज़र (क्रोम) वास्तव में एक के बजाय TWO वर्ण (बाइट) भेजते हैं :( यही कारण है कि ISON डिफ़ॉल द्वारा utf8 वर्णों के लिए जिसके लिए 127 से ऊपर के कोडी कोड वाले वर्णों को दो बाइट्स द्वारा कोडित किया गया है, जो कि chmike उत्तर द्वारा उल्लिखित था । मैंने इस तरह से परीक्षण किया: क्रोम url बार क्रोम में टाइप करें : // net-export / , चुनें "कच्चा शामिल करें" बाइट्स ", कैप्चर करना शुरू करें, पोस्ट अनुरोध भेजें (तल पर स्निपेट का उपयोग करके), कैप्चर करना बंद करें और कच्चे अनुरोध डेटा के साथ जोंस फाइल को सहेजें। फिर हम उस जसन फाइल के अंदर देखें:

हम स्ट्रिंग का पता लगाकर अपना बेस 64 अनुरोध प्राप्त कर सकते हैं 4142434445464748494a4b4c4d4eयह हेक्स कोडिंग है ABCDEFGHIJKLMNऔर हम इसके लिए देखेंगे "byte_count": 639।
हम स्ट्रिंग को पाकर अपने उपरोक्त 127 अनुरोध को पा सकते हैं C2BCC2BDC380C381C382C383C384C385C386C387C388C389C38AC38Bयह वर्णों का अनुरोध-हेक्स utf8 कोड हैं ¼½ÀÁÂÃÄÅÆÇÈÉÊË(हालांकि इस वर्ण के ascii हेक्स कोड हैं c1c2c3c4c5c6c7c8c9cacbcccdce)। "byte_count": 703तो यह 64bytes अब बेस 64 से अनुरोध करता है क्योंकि 127 से ऊपर ascii कोड के साथ पात्रों अनुरोध में 2 बाइट्स से कोड हैं :(

इसलिए वास्तव में हमें कोड> 127 :( के साथ वर्ण भेजने के साथ लाभ नहीं है। बेस 64 स्ट्रिंग्स के लिए हम इस तरह के नकारात्मक व्यवहार का निरीक्षण नहीं करते हैं (शायद बेस 85 के लिए भी - मैं इसकी जांच नहीं करता हूं) - हालांकि इस समस्या का कुछ समाधान हो सकता है .lex उत्तर में वर्णित POST मल्टीपार्ट / फॉर्म-डेटा के बाइनरी भाग में डेटा भेजना ( (हालांकि आमतौर पर इस मामले में हमें किसी भी आधार कोडिंग का उपयोग करने की आवश्यकता नहीं है ...)।

वैकल्पिक दृष्टिकोण आधार द्वारा दो बाइट्स डेटा भाग को एक मान्य utf8 वर्ण में मैप करने पर भरोसा कर सकता है, जैसे कि यह base65280 / base65k का उपयोग करके कोड करता है, लेकिन संभवतः utf8 विनिर्देशन के कारण यह बेस 64 की तुलना में कम प्रभावी होगा ...

कोड स्निपेट दिखाएं

function postBase64() {
  let formData = new FormData();
  let req = new XMLHttpRequest();

  formData.append("base64ch", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/");
  req.open("POST", '/testBase64ch');
  req.send(formData);
}


function postAbove127() {
  let formData = new FormData();
  let req = new XMLHttpRequest();

  formData.append("above127", "¼½ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüý");
  req.open("POST", '/testAbove127');
  req.send(formData);
}

<button onclick=postBase64()>POST base64 chars</button>
<button onclick=postAbove127()>POST chars with codes>127</button>

स्निपेट का विस्तार करें

— कामिल कियॉलेजवस्की
स्रोत

0

डेटा प्रकार वास्तव में चिंता करता है। मैंने RESTful संसाधन से पेलोड भेजने पर विभिन्न परिदृश्यों का परीक्षण किया है। एन्कोडिंग के लिए मैंने बेस 64 (अपाचे) और संपीड़न जीजिप (java.utils.zip। *) का उपयोग किया है। पेलोड में फिल्म, एक छवि और एक ऑडियो फ़ाइल के बारे में जानकारी है। मैंने छवि और ऑडियो फ़ाइलों को संपीड़ित और एन्कोड किया है जिसने प्रदर्शन को बहुत कम कर दिया है। संपीड़न से पहले एन्कोडिंग अच्छी तरह से निकला। छवि और ऑडियो सामग्री को एन्कोडेड और संपीड़ित बाइट्स [] के रूप में भेजा गया था।

— कौशिक
स्रोत

0

देखें: http://snia.org/sites/default/files/Multi-part%20MIME%20Extension%20v1.0g.pdf

यह बाइनरी डेटा के बेस 64 रूपांतरण की आवश्यकता के बिना 'सीडीएमआई सामग्री प्रकार' संचालन का उपयोग करके सीडीएमआई क्लाइंट और सर्वर के बीच द्विआधारी डेटा को स्थानांतरित करने का एक तरीका बताता है।

यदि आप 'गैर-सीडीएमआई सामग्री प्रकार' ऑपरेशन का उपयोग कर सकते हैं, तो किसी वस्तु से 'डेटा' को / में स्थानांतरित करना आदर्श है। मेटाडेटा को बाद में 'सीडीएमआई सामग्री प्रकार' ऑपरेशन के रूप में / से वस्तु में / जोड़ा जा सकता है।

— धीरज संगमकर
स्रोत

-1

मेरा समाधान अब, XHR2 ArrayBuffer का उपयोग कर रहा है। बाइनरी अनुक्रम के रूप में ArrayBuffer में बहु-सामग्री, वीडियो, ऑडियो, ग्राफिक, पाठ और कई सामग्री-प्रकारों के साथ शामिल हैं। ऑल इन वन रिस्पांस।

आधुनिक ब्राउज़र में, अलग-अलग कंपोनेंट्स के लिए DataView, StringView और Blob हैं। यह भी देखें: अधिक जानकारी के लिए http://rolfrost.de/video.html

— रॉल्फ रुस्त
स्रोत

आप अपने डेटा को बाइट्स के एक सरणी को क्रमबद्ध करके + 100%

— बढ़ाएँगे

@Sharcoux wot ??

— मिहेल मलोस्तानिदिस

JSON में एक बाइट सरणी का क्रमांकन कुछ इस तरह है: [16, 2, 38, 89]जो बहुत ही अक्षम है।

— शार्क्सएक्स