क्या UTF-8 लाखों नए पात्रों के साथ एक विशाल विदेशी भाषा को शामिल करने में सक्षम होगा?


86

इस घटना में एक विदेशी आक्रमण हुआ और हम अपने सभी मौजूदा कंप्यूटर सिस्टम में उनकी भाषाओं का समर्थन करने के लिए मजबूर हो गए, क्या यूटीएफ -8 को उनके संभवतः विशाल मात्रा में वर्णों की अनुमति देने के लिए डिज़ाइन किया गया है?

(बेशक, हम नहीं जानते कि क्या वास्तव में एलियंस के पास भाषाएं हैं, अगर या वे कैसे संवाद करते हैं, लेकिन तर्क के लिए, कृपया कल्पना करें कि वे करते हैं।)

उदाहरण के लिए, यदि उनकी भाषा में लाखों न्यूफ़ाउंड ग्लिफ़, प्रतीक और / या वर्णों का संयोजन होता है , तो क्या इन नए ग्लिफ़ को शामिल करने के लिए गैर-ब्रेकिंग तरीके से UTF-8 को सैद्धांतिक रूप से विस्तारित किया जा सकता है और अभी भी सभी मौजूदा सॉफ़्टवेयर का समर्थन कर सकता है?

मुझे अधिक दिलचस्पी है अगर ग्लिफ़ ने वर्तमान आकार की सीमाओं को दूर कर दिया और एकल ग्लिफ़ का प्रतिनिधित्व करने के लिए अधिक बाइट्स की आवश्यकता है। घटना में UTF-8 का विस्तार नहीं किया जा सका , क्या यह साबित होता है कि UTF-32 पर एकल लाभ केवल निचले वर्णों का आकार है?


16
"उनकी भाषाओं का समर्थन करें " (मेरा जोर) ... कितने? क्या हमें यकीन है कि भाषाओं को पात्रों से तोड़ा जा सकता है? हो सकता है कि भाषा स्थानिक संबंधों पर आधारित हो। - टेड चियांग "स्टोरी ऑफ योर लाइफ", स्टोरी ऑफ योर लाइफ एंड अदर्स देखें । सबसे अच्छे रूप में, यह केवल एक अधिकतम-चीज़-इन-एक्स-बाइट्स प्रश्न (ऑफ-टॉपिक) है। सबसे कम, यह अटकलबाजी बकवास है। (यह स्पष्ट नहीं है कि आप क्या पूछ रहे हैं)
Scant Roger

6
@ScantRoger स्वीकृत उत्तर प्रश्न का उत्तर देने के लिए एक अच्छा काम करता है जैसा कि इसका उद्देश्य था।
Qix

11
स्वीकृत उत्तर हमें UTF-8, UTF-16 और UTF-32 के तथ्य बताने का एक अच्छा काम करता है। आप इसे विकिपीडिया पर देख सकते हैं। "विदेशी आक्रमण" के रूप में, मैं यह नहीं देखता कि उत्तर इसे कैसे संबोधित करता है।
स्कैंट रोजर


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

जवाबों:


109

यूनिकोड मानक में बहुत सारी जगह है। यूनिकोड कोडपॉइंट "विमानों" और "ब्लॉक" में आयोजित किए जाते हैं। कुल 17 विमानों में से वर्तमान में 11 अप्रकाशित हैं । प्रत्येक विमान में 65,536 वर्ण होते हैं, इसलिए एक विदेशी भाषा के लिए अतिरिक्त रूप से आधा मिलियन कोडपॉइंट्स हैं (जब तक कि हम पहले संपर्क से पहले अधिक इमोजी के साथ सभी को भर नहीं देते)। यूनिकोड 8.0 के रूप में, केवल 120,737 कोड पॉइंट कुल (लगभग कुल क्षमता का 10%) में असाइन किए गए हैं, लगभग एक ही राशि अप्रभावित लेकिन निजी, एप्लिकेशन-विशिष्ट उपयोग के लिए आरक्षित है। कुल में, 974,530 कोडपॉइंट अनसाइन किए गए हैं।

यूटीएफ -8 यूनिकोड का एक विशिष्ट एन्कोडिंग है, और वर्तमान में प्रति कोड बिंदु पर चार ऑक्टेट (बाइट्स) तक सीमित है, जो यूटीएफ -16 की सीमाओं से मेल खाता है। विशेष रूप से, यूटीएफ -16 केवल 17 विमानों का समर्थन करता है। इससे पहले, यूटीएफ -8 ने 6 ऑक्टेट प्रति कोड पॉइंट का समर्थन किया था, और 32768 विमानों का समर्थन करने के लिए डिज़ाइन किया गया था। सिद्धांत रूप में इस 4 बाइट की सीमा को उठाया जा सकता है, लेकिन यह यूनिकोड की वर्तमान संगठन संरचना को तोड़ देगा, और इसके लिए UTF-16 को चरणबद्ध करना होगा - निकट भविष्य में ऐसा होने की संभावना नहीं है, यह देखते हुए कि यह कुछ ऑपरेटिंग सिस्टम और प्रोग्रामिंग में कितना उलझा हुआ है भाषाओं।

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


7
दरअसल, UTF-16 के मिलान के लिए UTF-8 केवल 4-बाइट की सीमा तक ही सीमित है। विशेष रूप से, इसमें से 17/32 तक, आधे से थोड़ा अधिक।
Deduplicator

5
विंडोज के बाहर मुझे कोई अन्य ओएस नहीं पता है जहां या तो ओएस या ओएस पर अधिकांश प्रोग्राम UTF16 का उपयोग करते हैं। OSX प्रोग्राम आमतौर पर UTF8 हैं, Android प्रोग्राम आमतौर पर UTF8 हैं, लिनक्स आमतौर पर UTF8 हैं। तो हम सभी की जरूरत है विंडोज मरने के लिए है (यह पहले से ही मोबाइल अंतरिक्ष में मृत की तरह है)
slebetman

23
जब तक कि हम पहले संपर्क से पहले अधिक इमोजी के साथ उस सभी को नहीं भरते ... वहां आपके पास है। एलियंस के साथ शांतिपूर्ण बातचीत के लिए सबसे महत्वपूर्ण खतरा इमोजी है। हम बर्बाद हो गये।
रिक्टरस्टर 25'15

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

5
@Kaiserludi "अधिकांश लिनक्स कोड यूनिकोड के लिए UTF32 का उपयोग करता है", हाँ, नहीं। गंभीरता से कि आपको यह विचार कहाँ से मिला? वहाँ भी एक wfopen syscall या कुछ और नहीं है, यह सब तरह से UTF8 है। नरक भी पायथन और जावा - जो दोनों ऐतिहासिक कारणों के कारण यूटीएफ -16 के रूप में तार को परिभाषित करते हैं - जब आवश्यक हो तब सिवाय UTF-16 के स्ट्रिंग को स्टोर न करें .. बड़े मेमोरी लाभ और कोई प्रदर्शन हिट (और अतिरिक्त कोड के बावजूद रूपांतरण को संभालने के लिए - मेमोरी महंगी है, CPU सस्ता है)। समान एंड्रॉइड के लिए जाता है - NDK का JString UTF8 है, ज्यादातर इसलिए कि Google इंजीनियर पागल नहीं हैं।
वू

30

यदि UTF-8 को वास्तव में विस्तारित किया जाना है, तो हमें उस निरपेक्ष अधिकतम को देखना चाहिए जिसका वह प्रतिनिधित्व कर सकता है। UTF-8 इस तरह संरचित है:

Char. number range  |        UTF-8 octet sequence
   (hexadecimal)    |              (binary)
--------------------+---------------------------------------------
0000 0000-0000 007F | 0xxxxxxx
0000 0080-0000 07FF | 110xxxxx 10xxxxxx
0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

(बेशर्मी से RFC से कॉपी किया गया है ।) हम देखते हैं कि पहला बाइट हमेशा यह नियंत्रित करता है कि कितने फॉलो-अप बाइट्स करंट कैरेक्टर बनाते हैं।

यदि हम इसे 8 बाइट्स तक की अनुमति देने के लिए बढ़ाते हैं तो हमें अतिरिक्त गैर-यूनिकोड अभ्यावेदन मिलते हैं

111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
11111110 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
11111111 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

इस तकनीक की अनुमति देता है कि अधिकतम संभव अभ्यावेदन की गणना

  10000000₂
+ 00100000₂ * 01000000₂
+ 00010000₂ * 01000000₂^2
+ 00001000₂ * 01000000₂^3
+ 00000100₂ * 01000000₂^4
+ 00000010₂ * 01000000₂^5
+ 00000001₂ * 01000000₂^6
+ 00000001₂ * 01000000₂^7

या आधार 10 में:

  128
+  32 * 64
+  16 * 64^2
+   8 * 64^3
+   4 * 64^4
+   2 * 64^5
+   1 * 64^6
+   1 * 64^7

जो हमें 4,468,982,745,216 के रूप में प्रतिनिधित्व की अधिकतम राशि देता है।

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


8
वर्तमान में UTF-8 0x10FFFF तक केवल कोड बिंदु तक सीमित है - लेकिन यह केवल UTF-16 के साथ संगतता के लिए है। यदि इसे विस्तारित करने की आवश्यकता थी, तो 0x7FFFFFFF (यह 2 0-1) तक कोड बिंदुओं के साथ इसे विस्तारित करने के तरीके के बारे में कोई अस्पष्टता नहीं है। लेकिन इससे परे मैंने परस्पर विरोधी परिभाषाएं देखी हैं। मैंने जो एक परिभाषा देखी है, 111111xxवह संभवत: पहली बाइट के रूप में है, जिसके बाद अधिकतम 2³² कोड अंकों के लिए पांच एक्सटेंशन बाइट्स हैं। लेकिन यह केवल पहले 2 that कोड बिंदुओं के लिए आपके द्वारा बताई गई परिभाषा के अनुकूल है।
कास्परड

2
हां, विकिपीडिया UTF-16 के बारे में कुछ कहता है, जब वास्तव में उनका मतलब यूनिकोड या आईएसओ 10646 (संदर्भ के आधार पर) होता है। वास्तव में, आरएफसी 3629 के बाद से, UTF-8 है U + 10FFFF परे (या अपरिभाषित F4 8F BF BFUTF-8 बाइट में)। इसलिए, जो कुछ मैं यहां बताता हूं, वह शुद्ध अटकलें हैं। बेशक, कोई अन्य एक्सटेंशन के बारे में सोच सकता है, जहां एक उच्च पहली बाइट निम्नलिखित कुछ अन्य संरचना का संकेत देती है (और उम्मीद है कि प्रक्रिया में आत्म सिंक को नष्ट नहीं कर रही है)। मैंने बाइट योजना को वास्तविक UTF-8 के जितना संभव हो, पूरा करने की कोशिश की, हालाँकि।
बोल्डवेन एनवाई

4
वह 4 ट्रिलियन है, क्वाड्रिलियन नहीं।
यपनीपैन

1
निम्नलिखित बाइट्स की संख्या के लिए यह कड़ाई से आवश्यक नहीं है कि पहले बाइट में अग्रणी लोगों की संख्या से कम हो। पर्ल वास्तव में (2000 से) यूटीएफ -8 के एक आंतरिक संस्करण का समर्थन करता है, जहां 5, 6 और 7 बाइट फॉर्म इस उत्तर के समान हैं, लेकिन FFएक 13-बाइट कोड इकाई का परिचय देता है जो 72 बिट्स को संग्रहीत करने में सक्षम है। 2 ^ 36 से अधिक कुछ भी समान रूप से बहुत महंगा है, लेकिन यह 64-बिट इंट और फिर कुछ को एन्कोडिंग करने की अनुमति देता है।
hobbs

7

RFC3629 UTF-8 को प्रति वर्ण अधिकतम चार बाइट्स तक सीमित करता है, जिसमें अधिकतम 0x10FFFF का मान होता है, जिससे अधिकतम 1,112,064 कोड अंक प्राप्त होते हैं। जाहिर है कि इस प्रतिबंध को हटाया जा सकता है और मानक बढ़ाया जा सकता है, लेकिन यह मौजूदा कोड के लिए एक ब्रेकिंग परिवर्तन साबित होगा जो उस सीमा तक काम करता है।

डेटा-फ़ाइल के दृष्टिकोण से, यह एक ब्रेकिंग परिवर्तन नहीं होगा क्योंकि मानक इस आधार पर काम करता है कि यदि प्रत्येक बाइट का सबसे महत्वपूर्ण बिट (MSB) सेट है, तो अगला बाइट एन्कोडिंग का हिस्सा है। RFC3629 से पहले भी, मानक 31 बिट्स तक सीमित था, जिससे चौथे बाइट का MSB परेशान हो गया था।

मानक को 0x10FFFF से आगे बढ़ाने पर UTF-16 के साथ UTF-8 की आंशिक डेटा संगतता टूट जाएगी।


5
तो सिद्धांत रूप में, डेटा पीछे की ओर संगत होगा, लेकिन कोड स्वाभाविक रूप से मानक के अनुरूप नहीं होगा?
क्यूएक्स

2
@Qix, यह एक मान्य बिंदु है। कोई भी मौजूदा UTF-8 फ़ाइल स्वाभाविक रूप से उदाहरण के लिए अधिकतम 6 बाइट्स के साथ संगत होगी ताकि लाखों और कोड बिंदु समायोजित किए जा सकें, लेकिन UTF-8 को संभालने के लिए डिज़ाइन किए गए कई मौजूदा पुस्तकालय संभवतः उस एक्सटेंशन को संभाल नहीं पाएंगे।
डेविड अरनो

4
UTF-16 वसा रूप से टूट जाएगा। यह स्वाभाविक रूप से केवल 0x10FFFF तक के कोड पॉइंट्स को सपोर्ट करता है।
gnasher729 15

1
@ gnasher729: इतना बड़ा मुद्दा नहीं जितना आप सोचते हैं। प्री-यूनिकोड ने इसे शिफ्ट वैल्यू (जापानी के लिए शिफ्ट JIS) के माध्यम से हल किया। वे केवल एक "शिफ्ट कैरेक्टर" के रूप में एक आरक्षित / अप्रयुक्त चरित्र (0xFFFD?) को चिह्नित करेंगे, जो एन्कोडिंग को अधिक विस्तारित रूप में बदलता है। शायद UTF32।
मूविंग डक

4

वास्तव में, केवल 2 यूनिकोड कोड-पॉइंट कोड अनंत रूप से कई ग्लिफ़ के लिए खड़े होते हैं, अगर वे वर्णों का संयोजन कर रहे थे।

तुलना करें, उदाहरण के लिए, दो तरीके जो यूनिकोड कोरियाई हंगुल वर्णमाला के लिए एन्कोड करते हैं: हंगुल सिलेबल्स और हंगुल जैमो । चरित्र 웃 में Hangul Syllabelsएक कोड-बिंदु है C6C3जबकि Hangul Jamoयह है तीन कोड-अंक 110B(ㅇ) 116E(ㅜ) 11B9(ㅅ)। जाहिर है, वर्णों के संयोजन का उपयोग बहुत कम कोड-पॉइंट करता है, लेकिन लेखन के लिए कम कुशल है क्योंकि प्रत्येक चरित्र को लिखने के लिए अधिक बाइट्स की आवश्यकता होती है।

इस चाल के साथ, कोड-बिंदुओं की संख्या से परे जाने की आवश्यकता नहीं है जो वर्तमान में UTF-8 या UTF-16 में एन्कोड किए जा सकते हैं।

मुझे लगता है कि यह नीचे आता है कि अगर उनकी भाषा सांसारिक भाषाओं की तुलना में प्रति संदेश कई बाइट्स की आवश्यकता होती है, तो एलियन कितना नाराज होंगे। यदि वे बुरा न मानें, तो अपने प्रत्येक लाखों पात्रों का प्रतिनिधित्व करते हुए, 100k संयोजन वर्णों का उपयोग करते हुए कहें, तो कोई समस्या नहीं है; दूसरी तरफ अगर धरती से अधिक बाइट्स का उपयोग करने के लिए मजबूर किया जा रहा है, तो वे उन्हें द्वितीय श्रेणी के नागरिकों की तरह महसूस करते हैं, हम कुछ संघर्ष के लिए हो सकते हैं ( इसके विपरीत जो हम पहले से ही यूटीएफ -8 के साथ निरीक्षण करते हैं )।


यह केवल मामला है अगर विदेशी भाषा में वर्ण वास्तव में अंगूर के अधिक सीमित सेट से बना है। यह मामला नहीं हो सकता है।
जैक्सबी

1
जहां तक ​​मुझे पता है कि कोई आवश्यकता नहीं है कि पात्रों को संयोजित करने के लिए व्यक्तिगत अंगूर से संबंधित होना आवश्यक है। यूनिकोड एफएक्यू इस पर चुप है, लेकिन मेरी धारणा यह है कि यह एक लेआउट इंजन के लिए कोई भी कठिन नहीं होगा जो कॉम्पेक्टिंग कॉम्पेक्ट का समर्थन करेगा जो कि अंगूर के अनुक्रम नहीं हैं, क्योंकि किसी भी मामले में एक पूर्वगामी ग्लिफ़ की आवश्यकता होगी।
ओवेन

ये एलियन कितने समय तक जीवित रहते हैं, और कितने पात्रों को अंगूरों में सड़ने नहीं देते हैं, क्या वे बचपन में सीख सकते हैं? और क्या प्रीज़म्पोज़्ड हंगुल गज़िप के बाद भी हंगुल हंगुल पर अपने बाइट लाभ को बरकरार रखता है?
दामियन येरिक

-2

संपादित करें: सवाल अब "लाखों नए पात्रों" का कहना है। इससे उत्तर देना आसान हो जाता है:

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


मूल प्रश्न का उत्तर देने के लिए:

यूनिकोड भाषाओं का समर्थन नहीं करता है, यह पात्रों का समर्थन करता है - लिखित रूप में भाषा का प्रतिनिधित्व करने के लिए उपयोग किए जाने वाले प्रतीक।

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

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

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

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

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

वर्तमान एन्कोडिंग के विस्तार या संशोधन, या नए एन्कोडिंग की शुरूआत से इसका समाधान नहीं होगा, क्योंकि सीमा यूनिकोड द्वारा समर्थित कोड बिंदुओं की संख्या में है।

तो जवाब सबसे अधिक संभावना नहीं है।


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

3
इस उत्तर के भाग अच्छे हैं, लेकिन यह कहने के लिए "न केवल इसका लिखित रूप नहीं है, यह संभवतः लिखित रूप में प्रस्तुत नहीं किया जा सकता है" केवल स्पष्ट गलत है। जो कुछ भी जानकारी देता है उसे बिट्स तक कम किया जा सकता है, और बिट्स के लिए कम की गई चीजों को आपके द्वारा पसंद किए जाने वाले पात्रों की बहुत अधिक धारा में बदला जा सकता है।
स्टीवन बर्नैप

2
@StevenBurnap सच है, लेकिन यूनिकोड बिट्स के एक क्रम से अधिक है। यह उन बिट्स की व्याख्या करने का एक तरीका है, जो काफी कठोर है। हाँ, यूनिकोड वर्ण सेट का विस्तार छवियों से लेकर सीएनसी निर्देशों तक किसी भी चीज़ को दर्शाने के लिए किया जा सकता है, लेकिन यह एक बहुत ही अलग प्राणी होगा।
ओवेन

4
ध्यान रखें कि यूनिकोड प्रतीकों का वर्णन (अधिकांश भाषाओं में) हवा के दबाव की भिन्नता में पैटर्न है, और अधिकांश भाषाओं के लिए यह वास्तव में उन पैटर्नों से मेल खाते हुए काफी भद्दा काम करता है।
स्टीवन बर्नैप

3
तो आपका मतलब है कि "सूर्य के साथ 45 सेकंड अपने 15 डिग्री पर उड़ान भरें, फिर 10 सेकंड सूरज के साथ 10 डिग्री अपने दाईं ओर उड़ान भरें" असंभव है? यह निश्चित रूप से संदर्भ के रूप में उस समय सूर्य की स्थिति की आवश्यकता होती है।
स्टीवन बर्नैप
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.