कई यूनिकोड एनकोडिंग क्यों हैं?


41

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

फिर इतने सारे यूनिकोड एनकोडिंग क्यों हैं? यहां तक ​​कि (अनिवार्य रूप से) एक ही के कई संस्करण, जैसे यूटीएफ -8, यूटीएफ -16, आदि।


11
UTF-8, UTF-16 के समान नहीं है। जैसे ही हम पृथ्वी जैसे ग्रहों के साथ अन्य सौर प्रणालियों का सामना करेंगे, सूची बढ़ती जाएगी।
सेटज़ामोरा

1
@ जोसेट: हमारे पास पहले से ही क्लिंगन है। हमारे पास बीएमपी पर अधिकांश पृथ्वी की भाषाएं हैं, जो कि मैदानी क्षेत्र में मामूली फैलाव के साथ 1,2 हैं। यदि वर्तमान थ्रेशर सही हैं और आकाशगंगा में केवल 42 संवेदनशील प्रजातियां हैं जो एक बिंदु तक पहुंचती हैं जहां वे अंतरिक्ष यात्रा का उपयोग कर सकते हैं (इस प्रकार पहले संपर्क की अनुमति दें) हमें सभी भाषाओं में सभी पात्रों को UNICODE में निचोड़ने में सक्षम होना चाहिए (यह मानते हुए कि हम विस्तार कर सकते हैं 64 मैदानों को अनुमति देने के लिए 21 से 22 बिट्स तक)। यहां तक ​​कि अगर हम आदिम प्रजातियों को शामिल करना चाहते हैं जो अंतरिक्ष उड़ान को प्राप्त नहीं करना चाहते हैं तो बफर स्पेस के 10 बिट्स को छोड़ देता है।
मार्टिन यॉर्क

7
@ केविन ह्सु: UTF-7,8,16LE, 16BE, 32LE, 32BE। तो, कम से कम 6 वास्तविक एनकोडिंग मौजूद हैं। UTF-9 और UTF-18 अप्रैल फूल हैं।
MSalters

9
मानकों के बारे में अच्छी बात यह है कि उनमें से बहुत सारे हैं
होमडे

1
देखें कि यूनिकोड और एन्कोडिंग पर स्पॉलस्की का क्या कहना था ।
MPelletier

जवाबों:


29

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

तो मूल रूप से, हां, हम एक एकल सार्वभौमिक एन्कोडिंग के साथ-साथ एक एकल सार्वभौमिक चरित्र चार्ट को परिभाषित कर सकते थे, लेकिन बाजार ने इसे स्वीकार नहीं किया होगा।


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

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

2
वास्तव में सच भी नहीं है। चूंकि संपीड़ित प्रारूप वास्तव में केवल परिवहन और भंडारण के लिए उपयोग किए जाते हैं। किसी एप्लिकेशन के भीतर आमतौर पर UCS-2 या UCS-4 का उपयोग करना अधिक होता है क्योंकि ये निश्चित चौड़ाई के होते हैं, लेकिन ये प्रति वर्ण 2 या 4 बाइट लेते हैं। इसलिए एप्लिकेशन उपयोग की आसानी के लिए जगह देने को तैयार हैं।
मार्टिन यॉर्क

but it is less useful for European languages, and of little use for Asian languages- यह सिर्फ गलत है। "उपयोगिता" द्वारा आप संपीड़न का मतलब है? खैर, तब UTF-8 यूरोपीय भाषाओं के लिए बेहतर संपीड़न प्रदान करता है क्योंकि हर पाठ में रिक्त स्थान और विराम चिह्न होते हैं जो केवल एक बाइट लेते हैं।
निक वोल्किन

37

यूनिकोड एक 21 बिट कैरेक्टर है जो विशिष्ट कोड "कोड पॉइंट" को एन्कोडिंग करता है, प्रत्येक कोड बिंदुओं को एए ग्लिफ़ (एक ग्राफिकल प्रतिनिधित्व) द्वारा दर्शाया जाता है।

  • एक विमान में कोड बिंदु की पहचान करने के लिए उपयोग किए जाने वाले 16 बिट्स (अधिकांश कोड बिंदु विमान 0 पर हैं)।
  • विमान की पहचान करने के लिए 5 बिट्स।

समर्थित एन्कोडिंग निम्न हैं:

  • UTF-8 (8 बिट मानों का उपयोग करके प्रत्येक बिंदु को सांकेतिक शब्दों में बदलना)
  • UTF-16 (16 बिट मानों का उपयोग करके प्रत्येक बिंदु को सांकेतिक शब्दों में बदलना)
  • UTF-32 (32 बिट मानों का उपयोग करके प्रत्येक बिंदु को सांकेतिक शब्दों में बदलना)

लेकिन कोई फर्क नहीं पड़ता कि जब आप इनकोडिंग करते हैं, तो वे सभी एक विशिष्ट कोडपॉइंट पर वापस जाते हैं जिसका एक ही अर्थ होता है (यही कारण है कि यह अच्छा है)।

UTF-8

यह एक चर आकार का प्रारूप है। जहां प्रत्येक कोडपॉइंट को 1 से 4 बाइट्स द्वारा दर्शाया जाता है।

UTF-16

यह एक चर आकार का प्रारूप है। "बेसिक बहुभाषी विमान" (BMP या विमान 0) पर कोड अंक 1 एकल 16 बिट मान द्वारा दर्शाए जा सकते हैं। अन्य विमानों पर कोड अंक एक सरोगेट जोड़ी (2 16 बिट मान) द्वारा दर्शाए जाते हैं।

UTF-32

यह एक निश्चित आकार का प्रारूप है। सभी कोड बिंदुओं को एक एकल 32 बिट मान द्वारा दर्शाया गया है।


2
मुझे भी यह जवाब पसंद है। एक समान लिख रहा था, लेकिन यह एक स्पष्ट है। मैं यह भी कहना चाहता हूं कि UTF-8 भी उपयोगी है कि ASCII तार स्वचालित रूप से UTF-8 हैं।
केविन ह्सु

4
कृपया, यह मूल बहुभाषी विमान है , एक मैदान नहीं है ।
जेएसबी JS

3
यह एक अच्छा उत्तर है, लेकिन मुझे लगता है कि यह अभी भी सवाल पूछ रहा है, "क्यों?", हालांकि यह उत्तर स्पष्ट रूप से उस पर छूता है। विस्तृत करने के लिए: यूटीएफ -32 एक अधिक प्रत्यक्ष (कुछ आसान कहेंगे) यूनिकोड पात्रों को एन्कोडिंग करने का दृष्टिकोण है, लेकिन यह भी बहुत सारे स्थान बर्बाद करता है, क्योंकि प्रत्येक चरित्र में 4 बाइट्स होते हैं। UTF-8 ASCII के साथ बहुत अधिक कॉम्पैक्ट और बैकवर्ड-संगत है, लेकिन यह नियमित नहीं है: एक चरित्र कहीं भी 1 से 4 बाइट्स से सांकेतिक शब्दों में बदलना में ले सकता है, जिसके साथ काम करना मुश्किल हो जाता है। UTF-16 दोनों के बीच एक प्रकार का संकर दृष्टिकोण है, जिसमें से प्रत्येक के पेशेवरों और विपक्षों के साथ है।
मिपाड़ी

4
मेमोरी उपयोग के बीच एक ट्रेडऑफ है (जहां UTF-8 सबसे अच्छा है, क्योंकि सबसे आम अक्षर सिंगल-बाइट हैं) और प्रोसेसिंग स्पीड (जहां UTF-32 सबसे अच्छा है, क्योंकि सभी वर्ण समान आकार के हैं, कुछ अनुकूलन के लिए अनुमति देते हैं और सही देते हैं स्मृति में 32-बिट संरेखण)। परिणामस्वरूप, नेटवर्क प्रोटोकॉल और फ़ाइल प्रारूप आमतौर पर UTF-8 (बैंडविड्थ / स्टोरेज स्पेस को बचाने के लिए) का उपयोग करते हैं, जबकि स्क्रिप्ट दुभाषियों और भाषा रनटाइम UTF-16 या UTF-32 पसंद कर सकते हैं।
tdammers

2
@ मार्सेल: एक "कोडपॉइंट" एक "कोडप्वाइंट" है न कि एक character(जैसा कि एक चरित्र कई "कोड पॉइंट्स" से निर्मित किया जा सकता है)। दो शब्दों को भ्रमित मत करो। लेकिन आप सही हैं "कोड पॉइंट" ग्लिफ़ का संदर्भ नहीं देते हैं। एक ग्लिफ़ एक कोड बिंदु का एक चित्रमय प्रतिनिधित्व है। एक सूक्ष्म लेकिन महत्वपूर्ण अंतर।
मार्टिन यॉर्क

25

मुझे लगता है कि 2 विचारों को अलग करना उपयोगी है:

  1. यूनिकोड - कोड बिंदुओं के लिए दुनिया भर के पात्रों की मैपिंग।
  2. एन्कोडिंग - बिट पॉइंट्स (UTF-8, UTF-16, आदि) के लिए कोड पॉइंट्स की मैपिंग।

UTF-8, UTF-16, और अन्य एन्कोडिंग के अपने फायदे और नुकसान हैं। इसके बारे में विकिपीडिया से बेहतर सलाह लें ।


@jfs: यूनिकोड क्यों है हालांकि अगर अभी भी एक दर्जन या अधिक विभिन्न एन्कोडिंग होने जा रहे हैं जो सभी तार पर अलग-अलग हैं? वैश्विक मानचित्रण होने से क्या उपयोग होता है?
मैथ्यू शेर्ले

10
@ मैथ्यू शार्ले: आप इसे गलत देख रहे हैं। UNICODE एक UNIQUE ID (कोडपॉइंट) के लिए सभी भाषाओं के सभी अक्षर (क्लिंगन सहित) से मैप करता है । एन्कोडिंग केवल डिस्क पर या नेटवर्क पर एक स्ट्रीम कोड कोड को संपीड़ित करने का एक तरीका है। UTF "UNICODE परिवहन प्रारूप" के लिए है। आपको हमेशा एक UNICODE कोडपॉइंट को 21 बिट मान के रूप में सोचना चाहिए। अन्य प्रारूपों पर लाभ यह है कि सभी वर्ण विशिष्ट रूप से पहचाने जाते हैं और ओवरलैप नहीं करते हैं (लैटिन -1, लैटिन -2 आदि के विपरीत)।
मार्टिन यॉर्क

@ मैथ्यू शेर्ले ने वैश्विक मैपिंग क्यों की? वास्तव में हर किसी की अतीत में अपनी खुद की मैपिंग थी (कोड पृष्ठों को याद रखें?)। मुझे लगता है कि एक मूर्खतापूर्ण उदाहरण चीजों को साफ कर देगा। प्यार के विचार की कल्पना करें। आप इसे किसी का प्रतिनिधित्व कैसे करेंगे? फूल देना? कहो कि मैं तुमसे प्यार करता हूं"? इसे व्यक्त करने का हर किसी का अपना तरीका होता है। प्रेम (जो एक अमूर्त विचार है) कोड बिंदुओं की तरह है। इसे व्यक्त करना एनकोडिंग की तरह है। :)
JFS

4
यूनिकोड वैश्विक वर्णमाला है। UTF-x कंप्यूटरों द्वारा पहुँचाया जाने वाला तरीका है, क्योंकि तारों के माध्यम से कागज को चमकाना मुश्किल है।
मेल

1
@ मॉर्टिन, क्लिंगन ने वास्तव में इसे नहीं बनाया। न ही टेंगवार या सिरिथ, का उपयोग टोलकेन की सहायक जीभ लिखने के लिए किया गया था।
टीआरआईजी

9

UTF-7, UTF-8, UTF-16 और UTF-32 पात्रों के समान कोडिंग (कोडपॉइंट्स) के एल्गोरिथम रूपांतरण प्रारूप हैं । वे वर्णों के संहिताकरण की एक प्रणाली के एनकोडिंग हैं ।

वे 256 से अधिक वर्णों वाले वर्ण सेट से निपटने के लिए पिछली योजनाओं की तुलना में आगे और पीछे नेविगेट करने के लिए एल्गोरिदमिक रूप से आसान हैं।

यह आम तौर पर देश की तुलना में बहुत अलग है- और कभी-कभी ग्लिफ्स के विक्रेता-विशिष्ट कोडिफिकेशन। केवल जापानी में, अकेले JIS की विविधताओं का एक टन था, जिसमें EUC-JP और JIS के कोडपेज-उन्मुख परिवर्तन का उल्लेख नहीं किया गया था कि DOS / Windows मशीनों का उपयोग Shift-JIS कहा जाता था। (कुछ हद तक, इनमें से एल्गोरिथम परिवर्तन थे, लेकिन वे विशेष रूप से सरल नहीं थे और उन पात्रों में विक्रेता-विशिष्ट अंतर थे जो उपलब्ध थे। एक दो सौ देशों द्वारा इसे गुणा करें और अधिक परिष्कृत फ़ॉन्ट सिस्टम के क्रमिक विकास (पोस्ट ग्रीनस्क्रीन) युग), और आपके पास एक वास्तविक दुःस्वप्न था।

आपको यूनिकोड के इन परिवर्तन रूपों की आवश्यकता क्यों होगी? क्योंकि बहुत सारी विरासत प्रणालियों ने एएससीआईआई-श्रेणी के 7 बिट पात्रों के अनुक्रमों को ग्रहण किया, इसलिए आपको उन प्रणालियों के माध्यम से अनियंत्रित डेटा को सुरक्षित रूप से पारित करने के लिए 7-बिट स्वच्छ समाधान की आवश्यकता थी, इसलिए आपको UTF-7 की आवश्यकता थी। तब अधिक आधुनिक प्रणालियां थीं जो 8-बिट कैरेक्टर सेट से निपट सकती थीं, लेकिन अशक्त लोगों के लिए आमतौर पर उनके विशेष अर्थ होते थे, इसलिए UTF-16 उनके लिए काम नहीं करता था। 2 बाइट्स यूनिकोड के पूरे बुनियादी बहुभाषी विमान को उसके पहले अवतार में सांकेतिक शब्दों में बदलना कर सकते हैं, इसलिए UCS-2 उन प्रणालियों के लिए एक उचित दृष्टिकोण की तरह लग रहा था जो "यूनिकोड को जमीन से अवगत कराने वाले थे" (जैसे विंडोज़ एनटी और जावा वीएम); उसके बाद जो एक्सटेंशन अतिरिक्त वर्णों की आवश्यकता होती है, जिसके परिणामस्वरूप यूनिकोड मानक द्वारा आरक्षित किए गए एन्कोडिंग्स के 21 बिट्स के एल्गोरिदम का रूपांतरण हुआ, और सरोगेट जोड़े पैदा हुए; जरूरी है कि UTF-16 यदि आपके पास कुछ एप्लिकेशन थे जहां स्टोरेज की दक्षता की तुलना में चरित्र की चौड़ाई की स्थिरता अधिक महत्वपूर्ण थी, तो UTF-32 (जिसे यूसीएस -4 कहा जाता है) एक विकल्प था।

UTF-16 एकमात्र ऐसी चीज़ है, जिससे निपटने के लिए दूर से जटिल है, और इस परिवर्तन से प्रभावित होने वाले पात्रों की छोटी रेंज से आसानी से कम हो जाता है और तथ्य यह है कि लीड 16-बिट सीक्वेंस बड़े करीने से ट्रेलिंग से पूरी तरह से अलग रेंज में हैं 16-बिट सीक्वेंस। यह कई प्रारंभिक पूर्वी एशियाई एनकोडिंग में आगे और पीछे जाने की कोशिश से भी आसान दुनिया है, जहां आपको भागने के दृश्यों से निपटने के लिए या तो एक राज्य मशीन (JIS और EUC) की आवश्यकता थी, या संभावित रूप से कई पात्रों को वापस ले जाएं जब तक कि आपको कुछ ऐसा न मिल जाए, जिसकी गारंटी थी केवल एक लीड बाइट (Shift-JIS) बनें। UTF-16 में सिस्टम पर कुछ फायदे थे जो 16-बिट दृश्यों के माध्यम से कुशलतापूर्वक, साथ ही साथ चुग सकते थे।

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


1
विभिन्न JIS और EUC राज्य मशीनें वास्तव में बहुत खराब हैं, और दोगुना इसलिए यदि आप उनके बीच रूपांतरण के साथ काम कर रहे हैं। यूनिकोड बेहद सरलता से बताता है। यूनिकोड के साथ एकमात्र बड़ी समस्या यह है कि आपको बाइट्स को पात्रों के रूप में सोचना बंद कर दिया गया है, आप ASCII- छोटे-चरित्र-बसा हुआ चाउनिस्ट का उपयोग कर रहे हैं!
डोनल फेलो

6

यूनिकोड को बहुत सारे अलग-अलग एन्कोडिंग होने के पूरे मुद्दे के बारे में जानने के लिए डिज़ाइन नहीं किया गया था।

यूनिकोड को उपयोग में कोड पेज के आधार पर कई अलग-अलग चीजों का प्रतिनिधित्व करने वाले एक नंबर के पूरे अंक के आसपास पाने के लिए डिज़ाइन किया गया था। नंबर 0 - 127 किसी भी Ansi कोड पेज में एक ही अक्षर का प्रतिनिधित्व करते हैं। यह वह है जिसे ASCII चार्ट या वर्ण सेट के रूप में भी जाना जाता है। Ansi कोड पृष्ठों में, जो 256 वर्णों के लिए अनुमति देता है, संख्या 128 - 255 विभिन्न कोड पृष्ठों में विभिन्न वर्णों का प्रतिनिधित्व करता है।

उदाहरण के लिए

  • संख्या $ 57 सभी कोड पृष्ठों में एक पूंजी डब्ल्यू का प्रतिनिधित्व करता है, लेकिन
  • संख्या $ EC कोड पृष्ठ 437 (यूएस) में इनफिनिटी प्रतीक का प्रतिनिधित्व करता है, लेकिन कोड पृष्ठ 775 (बाल्टिक) में "LATIN SMALL LETTER N WITH CEDILLA"
  • कोड पेज 437 में द सेंट साइन $ 9 बी है, लेकिन कोड पेज 775 में यह संख्या 96 है

यूनिकोड ने क्या किया, यह सब उल्टा हो गया। यूनिकोड में "पुन: उपयोग" नहीं है। प्रत्येक संख्या एक एकल अद्वितीय चरित्र का प्रतिनिधित्व करती है। यूनिकोड में संख्या $ 00A2 सेंट साइन है और सेंट साइन साइन यूनिकोड परिभाषा में कहीं और दिखाई देता है।

फिर इतने सारे यूनिकोड एनकोडिंग क्यों हैं? यहां तक ​​कि (अनिवार्य रूप से) एक ही के कई संस्करण, जैसे यूटीएफ -8, यूटीएफ -16, आदि।

एक ही एन्कोडिंग के कई संस्करण नहीं हैं। एक ही यूनिकोड के चरित्र परिभाषा मानचित्र के कई एनकोडिंग हैं और ये "आविष्कार" किए गए हैं जो यूनिकोड में मौजूद विभिन्न लिंगीय विमानों के विभिन्न उपयोगों के लिए भंडारण आवश्यकताओं को प्रशासित करते हैं।

यूनिकोड परिभाषित करता है (या परिभाषित करने के लिए स्थान है) 4.294.967.295 अद्वितीय वर्ण। यदि आप किसी भी एल्गोरिथम रूपांतरण किए बिना डिस्क / मेमोरी स्टोरेज में इनका मैप करना चाहते हैं, तो आपको प्रति वर्ण 4 बाइट्स की आवश्यकता होगी। यदि आपको सभी भाषिक विमानों के पात्रों के साथ ग्रंथों को संग्रहीत करने की आवश्यकता है, तो यूटीएफ -32 (जो मूल रूप से एक सीधा 1 वर्ण - यूनिकोड परिभाषा का 4 बाइट भंडारण एन्कोडिंग है) संभवतः वह है जो आपको चाहिए।

लेकिन शायद ही कोई ग्रंथ सभी भाषिक विमानों के पात्रों का उपयोग करता है। और फिर प्रति चरित्र 4 बाइट्स का उपयोग करना एक बड़ा बेकार लगता है। विशेष रूप से जब आप इस बात को ध्यान में रखते हैं कि पृथ्वी पर अधिकांश भाषाओं को मूल मल्टी-लिंगुअल प्लेन (बीएमपी) के रूप में जाना जाता है: यूनिकोड परिभाषा के पहले 65536 नंबर।

और जहाँ UTF-16 आए, वहीं यदि आप केवल BMP से वर्णों का उपयोग करते हैं, तो UTF-16 उस चरित्र को केवल दो बाइट्स प्रति वर्ण का उपयोग करके बहुत ही कुशलतापूर्वक संग्रहीत करेगा। यह केवल BMP के बाहर के वर्णों के लिए अधिक बाइट्स का उपयोग करेगा। UTF-16LE (लिटिल एंडियन) और UTF-16BE (बिग एंडियन) के बीच अंतर वास्तव में केवल कंप्यूटर मेमोरी (बाइट पैटर्न A0अर्थ हेक्स $ ए 0 या अर्थ $ 0 ए) के भीतर कैसे दर्शाया जाता है, के साथ कुछ करना है ।

यदि आपका पाठ पश्चिमी यूरोपीय भाषाओं के अधिकांश पाठों की तरह भी कम भिन्न वर्णों का उपयोग करता है, तो आप अपने पाठों के लिए संग्रहण आवश्यकताओं को और भी अधिक सीमित करना चाहेंगे। इसलिए UTF-8, जो ASCII चार्ट (पहले 128 नंबर) में मौजूद वर्णों को संग्रहीत करने के लिए एक एकल बाइट का उपयोग करता है और एएनएसआई पात्रों (विभिन्न कोड पृष्ठों का दूसरा 128 नंबर) से चयन होता है। यह केवल "सबसे अधिक उपयोग किए जाने वाले वर्ण" सेट के बाहर वर्णों के लिए अधिक बाइट्स का उपयोग करेगा।

तो फिर से बनाने के लिए:

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

2
"नंबर 0 - 127 किसी भी कोड पृष्ठ में समान वर्णों का प्रतिनिधित्व करते हैं।" - ठीक है, जब तक आप EBCDIC की बात नहीं कर रहे हैं, उस स्थिति $57में W
MSalters 20'11

@ दलाल: आप बिलकुल सही हैं। EBCDIC अलग है (और अन्य EBCDIC हैं)। मुझे लगता है कि मेरे मेनफ्रेम दिन मेरे पीछे इतने लंबे हैं कि मुझे याद नहीं था, या मैंने इन यादों को बहुत कठिन और बहुत लंबा दबा दिया है ... :-)
मार्जन वेनमा

"नंबर 0 - 127 किसी भी कोड पृष्ठ में समान वर्णों का प्रतिनिधित्व करते हैं।" बाइनरीसिग्निटिंग के रूप में वास्तव में एनकोडिंग हैं, जो एएससीआईआई के सुपरसेट नहीं हैं। बाइनरीसाइनग्रीटिंग, वास्तव में, किसी भी ASCII वर्ण को शामिल नहीं करता है।
टीआरआईजी

@TRiG: इसीलिए मैंने विशेष रूप से Ansi कोड पृष्ठों के बारे में अपने बयान को संपादित किया। आपके द्वारा रिफ्रेश करने से पहले ऐसा किया जाना चाहिए ...
Marjan Venema

हाँ। जब मैं अपनी टिप्पणी लिख रहा था तब एक अतिरिक्त टिप्पणी और एक पोस्ट अपडेट किया गया था। फिर भी, BinarySignWriting दिलचस्प है।
टीआरआईजी

2

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


2

UTF-32 के पीछे तर्क सरल है: यह यूनिकोड कोड बिंदुओं का सबसे सीधा प्रतिनिधित्व है। तो UTF-32 में सब कुछ क्यों नहीं है? दो मुख्य कारण:

एक का आकार है । UTF-32 को हर वर्ण के लिए 4 बाइट की आवश्यकता होती है। मूल बहुभाषी स्थान में केवल वर्णों का उपयोग करने वाले पाठ के लिए, यह UTF-16 की तुलना में दोगुना है। अंग्रेजी पाठ के लिए, यह यूएस-एएससीआईआई की तुलना में 4 गुना अधिक है।

बड़ा कारण बैकवर्ड संगतता है । "यूनेकोडेड" यूटीएफ -32 के अलावा प्रत्येक यूनिकोड एन्कोडिंग को एक पूर्व मानक के साथ पीछे की संगतता के लिए डिज़ाइन किया गया था।

  • UTF-8: US-ASCII के साथ पश्चगामी संगतता।
  • UTF-16: UCS-2 के साथ पीछे की संगतता (बीएमपी से परे विस्तारित होने से पहले 16-बिट यूनिकोड)।
  • UTF-7: नॉन-8-बिट-क्लीन मेल सर्वर के साथ पश्चगामी संगतता।
  • GB18030: चीनी के लिए GB2312 और GBK एन्कोडिंग के साथ पश्चगामी संगतता।
  • UTF-EBCDIC: EBCDIC के मूल लैटिन सबसेट के साथ पश्चगामी संगतता।

मैंने सोचा कि यूनिकोड को विभिन्न एन्कोडिंग के बहुत सारे होने के पूरे मुद्दे के लिए तैयार किया गया था

यह था, और यह किया। यूटीएफ -8, -16 और -32 के बीच रूपांतरण करना बहुत आसान है, विभिन्न भाषाओं और विभिन्न ओएस के लिए सैकड़ों अलग-अलग चरित्र एन्कोडिंग की पुरानी प्रणाली से निपटने के लिए ।


1

आप जानते हैं कि ज़िप-फ़ाइल एक फ़ाइल को बहुत छोटा (विशेष रूप से पाठ) संपीड़ित कर सकती है और फिर इसे मूल फ़ाइल की एक समान प्रतिलिपि के लिए खोल सकती है।

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

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


ørn: ज़िप फ़ाइल के साथ अंतर यह है कि एक हेडर है जो आपको बताता है कि संपीड़न क्या प्रभाव में है। पाठ फ़ाइलों के साथ, हमें अभी भी अनुमान लगाने की आवश्यकता नहीं है कि हम नहीं?
मैथ्यू शारले

एक विशेष क्रम है जो वास्तव में बताता है। ASCII के साथ पिछड़े संगतता के कारण यह वैकल्पिक है।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.