2010-12-03 18 views
25

क्या सामग्री प्रकार एप्लिकेशन/जेसन का उपयोग करने का कोई प्रदर्शन लाभ टेक्स्ट/सादे पर जेसन को क्रमबद्ध ऑब्जेक्ट भेज रहा है? मुझे पता है कि कई ढांचे (जैसे वसंत) सामग्री प्रकार के आधार पर डेटा को मानचित्र और क्रमबद्ध कर सकते हैं, लेकिन आम तौर पर मुझे लगता है कि यह प्रक्रिया इतना आसान है कि JSON ऑब्जेक्ट्स के लिए टेक्स्ट/सादे पर एप्लिकेशन/जेसन का उपयोग करने के लिए यह एक अनिवार्य कारण नहीं है ।टेक्स्ट/सादे पर एप्लिकेशन/जेसन का उपयोग करने के लाभ?

+0

जिनके बारे में आप जो माइम प्रकार निर्दिष्ट किया जाता है बात कर रहे हैं, या json का उपयोग कर के बारे में? – CodesInChaos

+0

दोनों। मैं किसी ऑब्जेक्ट का जेसन प्रतिनिधित्व एक सादे पाठ सामग्री प्रकार या एप्लिकेशन जेसन सामग्री प्रकार के साथ भेज सकता था। – stevebot

+1

मैं dissapointed हूं क्योंकि किसी ने जवाब नहीं दिया कि मैं "टेक्स्ट/सादा" के बजाय सामग्री-प्रकार के रूप में "एप्लिकेशन/जेसन" का चयन क्यों करूंगा, हालांकि जेसन स्वयं वास्तव में एक सादा पाठ है।मैं सब के बाद "एप्लिकेशन/एचटीएमएल" या "एप्लिकेशन/सीएसएस" नहीं चुनता, है ना? – Gherman

उत्तर

22

मान लें कि आप एक कस्टम संरचित डेटा पारित करने के लिए (MIME प्रकार text/plain का प्रयोग करके) प्रारूप बनाम JSON का उपयोग कर के बारे में बात कर रहे हैं।

प्रदर्शन विभिन्न घटकों में बांटा जा सकता है; जैसे

  • रिश्तेदार समय प्रारूप में सामग्री सांकेतिक शब्दों में बदलना करने के लिए लिया,
  • रिश्तेदार समय प्रारूप को डिकोड करने के यदि आप मूल सामग्री देने के लिए ले लिया है, और
  • एन्कोडेड सामग्री के सापेक्ष आकार।

सिद्धांत रूप में, हम कह सकते हैं कि एक काल्पनिक बेहतर बनाया गया है और कार्यान्वित कस्टम प्रारूप कोई धीमी या JSON से कम नहीं घने हो जाएगा। ("सबूत" स्पष्ट है। जेएसओएन का इष्टतम कार्यान्वयन चुनें और प्रारूप में कुछ मामूली परिवर्तन करें जो प्रदर्शन को प्रभावित नहीं करता है।)

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

यह कस्टम प्रारूपों से अधिक JSON (और XML) का असली लाभ के लिए हमें लाता है।

  • JSON और एक्सएमएल के साथ

    , वहाँ किसी भी मुख्य धारा भाषा आप एन्कोडिंग और डिकोडिंग सामग्री में सहायता करने के लिए उपयोग करने के लिए चुना है के लिए उपलब्ध पुस्तकालय हैं। कस्टम प्रारूप के साथ, आपको क्लाइंट और सर्वर पक्षों के लिए अपना स्वयं का एन्कोडिंग/डिकोडिंग रोल करना होगा।

  • JSON और एक्सएमएल के साथ

    , वहाँ मानकों का कहना है कि क्या अच्छी तरह से बनाई है कि अन्य लोगों को एनकोडर/डिकोडर लागू करने के लिए अनुमति देते हैं। कस्टम प्रारूप के साथ, यदि आप अन्य लोगों को अपना प्रारूप लागू करने में सक्षम होना चाहते हैं तो आपको खुद को विनिर्देश लिखना होगा।

  • JSON और XML में डेटासेट में वर्णित वर्णमाला एन्कोडिंग और "मेटा" वर्ण जैसे मुद्दों से निपटने के मानक तरीके हैं। एक कस्टम के साथ आपको इन मुद्दों को स्वयं समझना और संबोधित करना होगा। (और यदि आप नहीं करते हैं, तो आपको ट्रैक में कठिनाई हो सकती है।)

  • परिवर्तन की आसानी। यह जेएसओएन/एक्सएमएल आधारित प्रारूप विकसित करने के लिए अपेक्षाकृत सरल मामला है। लेकिन एक कस्टम प्रारूप के साथ, आपके पास (कम से कम) काम करने के लिए और अधिक काम है, और आपके डिजाइन विकल्पों के आधार पर, यह बहुत मुश्किल हो सकता है।

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

अनुसरण करे

लेकिन क्या होगा अगर इसके बजाय आप को लगता है कि मैं एक कस्टम कार्यान्वयन का उपयोग नहीं कर रहा हूँ और पाठ का एक माइम प्रकार/माइम प्रकार आवेदन/json की है कि सादा के साथ JSON भेजने की तुलना?

तो जवाब यह है कि यह लगभग कोईप्रदर्शन फर्क नहीं पड़ता है।

  • आप HTTP अनुरोध या प्रतिक्रिया शीर्षलेख में 6 बाइट्स को सहेजते हैं क्योंकि माइम प्रकार स्ट्रिंग कम है, लेकिन यह सामान्य HTTP संदेशों के लिए महत्वहीन है जिनके आकार हजारों बाइट्स में मापा जाता है।
  • "टेक्स्ट/सादा" सामग्री प्रकार का उपयोग करने से अनुरोध या प्रतिक्रिया संदेशों को एन्कोड/डीकोड करने के लिए किए जाने वाले कार्यों में कोई फर्क नहीं पड़ता ... 6 अतिरिक्त बाइट्स की तुलना/प्रतिलिपि बनाने के लिए लिया गया समय के अलावा, शायद मापने के लिए बहुत छोटा है।

इसके अलावा, एक गलत एमआईएम प्रकार का उपयोग (तर्कसंगत) HTTP चश्मे का उल्लंघन है। यदि आप ऐसा करते हैं:

  • यह अधिक संभावना है कि रिसीवर प्रतिक्रिया को मिट जाएगा; जैसे इसे डीकोड करने में विफल रहता है, या इसे ब्राउज़र विंडो में दिखाता है, और

  • आप HTTP सामग्री प्रकार वार्ता को तोड़ सकते हैं, यह मानते हुए कि आपका ग्राहक या सर्वर इसका उपयोग करता है।

संक्षेप में, मैं यह करने के लिए कोई अच्छा कारण के बारे में सोच सकते हैं, और कुछ अच्छा कारणों यह करने के लिए नहीं।

+0

लेकिन अगर आप मानते हैं कि मैं कस्टम कार्यान्वयन का उपयोग नहीं कर रहा हूं और जेमॉन को माइम प्रकार के टेक्स्ट/सादे के साथ माइम प्रकार एप्लिकेशन/जेसन के साथ भेजने की तुलना कर रहा हूं? – stevebot

+0

मैंने देखा है कि Google txt प्रारूप में JSON के रूप में स्वत: पूर्ण सुझाव देता है। मुझे आश्चर्य है कि वे इससे क्या प्राप्त कर रहे हैं – lfender6445

+0

संभवतः यह कुछ ब्राउज़रों को जेएसओएन को "प्रतिपादन" से संदर्भित करता है जहां यह हानिकारक होगा। संभवतः एक 6 बाइट बचत महत्वपूर्ण है जब अरबों अनुरोधों से गुणा किया जाता है। संभवतः वे कम/कुछ भी प्राप्त कर रहे हैं ... –

10

JSON मूल रूप से सादे पाठ का एक स्वरूप है। जैसे कि यह सबसे अच्छा सादा पाठ प्रारूप से तेज़ नहीं हो सकता है। (यह खराब चुने हुए सादे पाठ प्रारूप से तेज़ हो सकता है) जेएसओएन का उपयोग किया जाता है क्योंकि यह एन्कोडिंग और डिकोडिंग को आसान बनाता है और कई प्रकार के डेटा, एएसपी जटिल लोगों के लिए काफी मानव पठनीय है।

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

+0

मैं एक विकल्प की तलाश नहीं कर रहा हूं, जैसा कि आपने कहा था, जेसन सादा पाठ का एक प्रारूप है, इसलिए इसे सादे पाठ के रूप में भेजा जा सकता है। मुझे विश्वास नहीं है कि क्या अभ्यास अधिक कुशल है या नहीं। – stevebot

3

JSON शायद तेजी क्योंकि प्रमुख अनुकूलन के (सी कोड) JSON-इंजन के लिए होने जा रहा है। उदाहरण के लिए वी 8 का JSON.parse() बेहद तेज़ है।

4

JSON अंततः एक्सएमएल के साथ व्यापक रूप से स्वीकार प्रारूप बन जाएगा। जेएसओएन की स्वीकृति बहुत तेजी से बढ़ रही है, जो भविष्य में दिमाग को ध्यान में रखकर पाठ पर एक बेहतर विकल्प बनाती है।

1

अन्य फायदों से स्ट्रिंग जेएसओएन स्वरूपित समान जावास्क्रिप्ट ऑब्जेक्ट घोषणा है इसलिए वे सरल और तेज पार्सिंग की अनुमति देते हैं।

JSON स्ट्रिंग: {नाम: मूल्य NAME2: मूल्य}

बहुत आसान जावास्क्रिप्ट वस्तु को tranform करने के लिए।

3

यहां जेसन है।org वर्णन (LOL) और मैं और अधिक सहमत नहीं हो सके:

JSON: एक्सएमएल

यहाँ आप पाते हैं कि लगभग सभी भाषाओं के लिए Json पुस्तकालय हैं करने के लिए वसा रहित वैकल्पिक।

http://www.json.org/

Json मैं क्योंकि JSON serializing और की प्रयोजन के लिए डिजाइन किया गया था Json http://ascherconsulting.com/what/are/the/advantages/of/using/json/

के बारे में मिल गया है तो Jquery http://api.jquery.com/jQuery.getJSON/

सबसे अच्छा ग्रंथों में से एक के साथ आसान है अनसुलझा डेटा को जावास्क्रिप्ट अनुप्रयोगों से पर भेजा जा रहा है, JSON का उपयोग करने के फायदे क्रमिकरण के अन्य माध्यमों पर JSON के फायदे। सबसे प्रसिद्ध वर्तमान में के लिए डेटा को क्रमबद्ध करने का माध्यम है अनुप्रयोगों के लिए और वर्तमान में एक्सएमएल है। फिर भी, एक्सएमएल क्रमिकरण के बोझिल साधन है। सबसे पहले, प्राप्तकर्ता समझता है कि प्रेषक को को पर आधारित दस्तावेज़ प्रकार परिभाषा पर डेटा को एन्कोड किया जाना चाहिए। ऐसा करने से वास्तविक डेटा के आसपास अतिरिक्त पैडिंग का एक बड़ा सौदा बनाता है इससे कोई फर्क नहीं पड़ता कि डीटीडी का उपयोग किया जाता है। इसलिए, में XML दस्तावेज़ों का आकार अक्सर मानों के वास्तविक सेट के साथ तुलना में काफी बड़ा होता है। दूसरा, प्राप्तकर्ता को एक्सएमएल की स्ट्रीम प्राप्त करनी होगी और पर डेटा को डीकोड करना होगा, फिर उस डेटा को स्मृति में रखें। इसकी तुलना में, डेटा प्रेषक द्वारा JSON का उपयोग करने का क्रमबद्धता अपेक्षाकृत त्वरित और कॉम्पैक्ट है, क्योंकि JSON के संरचना प्रकार मानक प्रोग्रामिंग डेटा की संरचना को दर्शाता है और एन्कोडिंग प्रणाली केवल अक्षर आवश्यक की न्यूनतम संख्या कहते हैं डेटा का मूल्य और मान इंगित करने के लिए। जब प्राप्तकर्ता तो JSON धारावाहिक डेटा, प्राप्त करता है, केवल प्रसंस्करण करने की जरूरत के लिए किया जाना का उपयोग कर स्ट्रिंग के पाठ का मूल्यांकन करना है या तो JavaScript की निर्मित eval समारोह या किसी अन्य भाषा में एक संगत कार्य करते हैं। अन्य मानक तुलना YAML, है जो डीटीडी पर भरोसा किए बिना जटिल डेटा सेट को क्रमबद्ध करने में सक्षम है और दोनों को XML से पढ़ने और लिखने के लिए एक सरल पार्सर की आवश्यकता है। हालांकि, भी सरलीकृत YAML पारसर्स आम तौर पर अधिक समय की आवश्यकता और बड़ा धारावाहिक डेटा JSON से धाराओं उत्पन्न करते हैं।

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