यदि हमारे पास सरोगेट जोड़े हैं तो यूटीएफ -16 के बजाय यूटीएफ -32 क्यों?

Question

यदि मैं सही ढंग से समझता हूं, तो यूटीएफ -32 ब्रह्मांड में प्रत्येक चरित्र को संभाल सकता है। तो सरोगेट जोड़े के उपयोग के माध्यम से यूटीएफ -16 कर सकते हैं। तो यूटीएफ -16 के बजाय यूटीएफ -32 का उपयोग करने का कोई अच्छा कारण है?

Answer 1

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

Answer 2

संक्षिप्त उत्तर: नहीं।

लंबा उत्तर: हां, अन्य चीजों के साथ संगतता के लिए जो ज्ञापन नहीं मिला।

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

Answer 3

यूटीएफ -8 किसी भी यूनिकोड चरित्र का भी प्रतिनिधित्व कर सकता है!

यदि आपका टेक्स्ट अधिकतर अंग्रेजी है, तो आप utf-8 का उपयोग कर बहुत सारी जगह बचा सकते हैं, लेकिन अनुक्रमणित वर्ण O (1) नहीं हैं, क्योंकि कुछ वर्ण केवल एक बाइट से अधिक लेते हैं।

तो अंतरिक्ष अपनी स्थिति के लिए के रूप में महत्वपूर्ण गति के रूप में नहीं है, UTF-32 तो आप बेहतर, सूट होगा क्योंकि अनुक्रमण हे है (1)

UTF-16 गैर अंग्रेजी के लिए UTF-8 की तुलना में बेहतर हो सकता है पाठ क्योंकि utf-8 में आपके पास ऐसी स्थिति है जहां कुछ वर्ण 3 बाइट्स लेते हैं, जहां utf16 में वे केवल दो बाइट लेते हैं।

Answer 4

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

यदि यूटीएफ -32 की बढ़ी हुई स्मृति उपयोग कोई मुद्दा नहीं है, तो कम जटिलता इसे चुनने के लिए पर्याप्त लाभ हो सकती है।

Answer 5

शायद कुछ अच्छे कारण हैं, लेकिन एक सूचकांक/खोज को तेज करना होगा, यानी डेटाबेस और इसी तरह।

यूटीएफ -32 के साथ आप जानते हैं कि प्रत्येक वर्ण 4 बाइट्स है। यूटीएफ -16 के साथ आप नहीं जानते कि कोई विशेष चरित्र कितनी लंबाई होगी।

उदाहरण के लिए, यदि आप एक समारोह है कि एक स्ट्रिंग के n वें चार रिटर्न है:

char getChar(int index, String s); 

आप प्रत्यक्ष स्मृति पहुँच गया है कि एक भाषा में कोडिंग रहे हैं, तो सी, तो UTF-32 इस समारोह में कहते हैं कुछ पॉइंटर अंकगणितीय (s+(4*index)) जितना आसान हो सकता है, जो कुछ मात्रा ओ (1) होगा।

यदि आप यूटीएफ -16 का उपयोग कर रहे हैं, तो आपको स्ट्रिंग, डिकोडिंग चलना होगा, जैसा कि आप गए थे, जो ओ (एन) होगा।

Answer 6

यहां यूनिकोड कंसोर्टियम से भी एक अच्छा दस्तावेज है।

Comparison of the Advantages of UTF-32, UTF-16, and UTF-8

कॉपीराइट © 1991-2009 यूनिकोड, Inc. यूनिकोड स्टैंडर्ड, संस्करण 5.2

इसे चेहरे पर, UTF-32 यूनिकोड एन्कोडिंग रूपों में से स्पष्ट विकल्प होना प्रतीत होता है एक आंतरिक प्रसंस्करण कोड के लिए क्योंकि यह एक निश्चित चौड़ाई एन्कोडिंग फॉर्म है। यह सी और सी ++ wchar_t के अनुरूप हो सकता है, जिसका अर्थ है कि ऐसी प्रोग्रामिंग भाषाएं अंतर्निहित समर्थन और तैयार किए गए स्ट्रिंग एपीआई की पेशकश कर सकती हैं जो प्रोग्रामर सलाह ले सकते हैं। हालांकि, यूटीएफ -16 में कई प्रतिकूल फायदे हैं जो कार्यान्वयनकर्ताओं को आंतरिक प्रसंस्करण कोड के रूप में चुनने के लिए प्रेरित कर सकते हैं। जबकि सभी तीन एन्कोडिंग फॉर्मों को प्रत्येक चरित्र के लिए अधिकतम 4 बाइट्स (या 32 बिट्स) डेटा की आवश्यकता होती है, वस्तुतः वास्तविक डेटा सेट के लिए लगभग सभी मामलों में यूटीएफ -32 में यूटीएफ -16 की आवश्यकता होती है। इसलिए, एक सामान्य रणनीति आंतरिक स्ट्रिंग स्टोरेज यूटीएफ -16 या यूटीएफ -8 का उपयोग करना है, लेकिन अलग-अलग पात्रों में हेरफेर करते समय यूटीएफ -32 का उपयोग करना है।

यूटीएफ -32 बनाम यूटीएफ -16। औसतन, सभी यूटीएफ -16 डेटा का 99 प्रतिशत से अधिक डेटा एकल कोड इकाइयों का उपयोग करके व्यक्त किया जाता है। इसमें लगभग सभी सामान्य वर्ण शामिल हैं जिन्हें सॉफ़्टवेयर को टेक्स्ट पर विशेष संचालन के साथ संभालने की आवश्यकता होती है - उदाहरण के लिए, प्रारूप नियंत्रण वर्ण। नतीजतन, अधिकांश टेक्स्ट स्कैनिंग ऑपरेशंस को यूटीएफ -16 सरोगेट जोड़े को अनपैक करने की आवश्यकता नहीं है, बल्कि उन्हें चरित्र स्ट्रिंग के अपारदर्शी हिस्से के रूप में सुरक्षित रूप से इलाज कर सकते हैं। कई परिचालनों के लिए, यूटीएफ -16 यूटीएफ -32 के रूप में संभालना आसान है, और प्रोटीन कोड के रूप में यूटीएफ -16 का प्रदर्शन काफी अच्छा होता है। यूटीएफ -16 यूनिकोड का समर्थन करने वाले अधिकांश कार्यान्वयन के लिए पसंद का आंतरिक प्रसंस्करण कोड है। यूनिक्स प्लेट-फॉर्म के अलावा, यूटीएफ -16 बीएमपी के बाहर मौलिक चरित्र को संभालने की क्षमता के साथ कॉम्पैक्ट आकार का सही मिश्रण प्रदान करता है। यूटीएफ -32 में कुछ हद तक लाभ होता है जब सॉफ्टवेयर कोडिंग डिज़ाइन और रखरखाव की सादगी की बात आती है। चूंकि चरित्र हैंडलिंग निश्चित चौड़ाई है, यूटीएफ -32 प्रसंस्करण को यूटीएफ -16 द्वारा अनुपूरक पात्रों के लिए आवश्यक डबल कोड इकाई तत्वों का परीक्षण और संसाधित करने के लिए सॉफ़्टवेयर में शाखाओं को बनाए रखने की आवश्यकता नहीं होती है। इसके विपरीत, बड़ी तालिका में 32-बिट सूचकांक विशेष रूप से स्मृति कुशल नहीं होते हैं। ऐसे सूचकांक की बड़ी मेमोरी दंड से बचने के लिए, यूनिकोड टेबल को अक्सर मल्टीस्टेज टेबल के रूप में संभाला जाता है (धारा 5.1 में "मल्टीस्टेज टेबल्स" देखें, अन्य मानकों में ट्रांसकोडिंग)। ऐसे मामलों में, 32-बिट कोड पॉइंट मानों को तालिकाओं तक विभाजित पहुंच की अनुमति देने के लिए छोटी श्रेणियों में काटा जाता है। यह सामान्य यूटीएफ -32 कार्यान्वयन में भी सच है। यूटीएफ -32 का प्रसंस्करण कोड के रूप में प्रदर्शन वास्तव में उसी डेटा के लिए यूटीएफ -16 के छिद्र से भी बदतर हो सकता है, क्योंकि अतिरिक्त मेमोरी ओवरहेड का मतलब है कि कैश की सीमा अधिक बार पार हो जाएगी और मेमोरी पेजिंग अधिक बार हो जाएगी । प्रोसेसर डिज़ाइन वाले सिस्टम के लिए जो 16-बिट गठबंधन पहुंच के लिए जुर्माना लगाते हैं लेकिन बहुत बड़ी यादें हैं, यह प्रभाव कम ध्यान देने योग्य हो सकता है। किसी भी घटना में, यूनिकोड कोड बिंदु आवश्यक रूप से "वर्णों" के लिए उपयोगकर्ता अपेक्षाओं से मेल नहीं खाते हैं। उदाहरण के लिए, निम्नलिखित को एक कोड बिंदु द्वारा प्रदर्शित नहीं किया जाता है: एक संयोजन वर्ण अनुक्रम जैसे; कोरियाई के लिए एक संयोजन jamo अनुक्रम; या देवनागरी संयोजन "क्ष।" क्योंकि कुछ यूनिकोड टेक्स्ट प्रोसेसिंग को अक्षरों के ऐसे अनुक्रमों के बारे में अवगत होना चाहिए और पाठ तत्वों के रूप में वर्णित होना चाहिए, यूटीएफ -32 का निश्चित-चौड़ाई एन्कोडिंग फॉर्म लाभ कुछ हद तक भिन्न रूप से भिन्न है- पाठ तत्वों को संसाधित करने की चौड़ाई प्रकृति। एक उदाहरण के लिए यूनिकोड तकनीकी मानक # 18, "यूनी-कोड नियमित अभिव्यक्तियां" देखें, जहां आमतौर पर कार्यान्वित प्रक्रियाएं "चरित्र" की पहचान की उपयोगकर्ता अपेक्षाओं के कारण अंतर्निहित परिवर्तनीय-चौड़ाई वाले टेक्स्ट तत्वों से निपटती हैं। यूटीएफ -8। यूटीएफ -8 उपयोग किए गए बाइट्स की संख्या के संदर्भ में उचित रूप से कॉम्पैक्ट है। यह वास्तव में केवल एक महत्वपूर्ण आकार के नुकसान पर होता है जब ची-नेज़, जापानी और कोरियाई जैसे पूर्वी एशियाई कार्यान्वयन के लिए उपयोग किया जाता है, जो हान विचारधाराओं या हैंगुल अक्षरों का उपयोग करते हैं जो यूटीएफ -8 में तीन-बाइट कोड यूनिट अनुक्रमों की आवश्यकता होती है। अन्य एन्कोडिंग फॉर्मों की तुलना में प्रोटीसिंग के मामले में यूटीएफ -8 भी काफी कम कुशल है। बाइनरी सॉर्टिंग।यूटीएफ -8 तारों का एक द्विआधारी प्रकार यूनिकोड कोड बिंदुओं के द्विआधारी प्रकार के समान क्रम देता है। यह स्पष्ट रूप से यूटीएफ -32 तारों के बाइनरी प्रकार के लिए एक ही आदेश है।

जनरल संरचना

तीनों एन्कोडिंग रूपों बाइनरी स्ट्रिंग तुलना या स्ट्रिंग sort- आईएनजी जब केवल बीएमपी पात्रों के साथ काम कर (रेंज U + 0000..U + FFFF में) के लिए एक ही परिणाम देती है। हालांकि, पूरक पात्रों (श्रेणी U + 10000..U + 10FFFF में) से निपटने पर, यूटीएफ -16 बाइनरी ऑर्डर यूनिकोड कोड पॉइंट ऑर्डर से मेल नहीं खाता है। बाइनरी सॉर्टेड सूचियों के साथ अंतःक्रिया करने की कोशिश करते समय यह जटिलताओं का कारण बन सकता है - उदाहरण के लिए, यूटीएफ -16 sys-tems और यूटीएफ -8 या यूटीएफ -32 सिस्टम के बीच। हालांकि, बाइनरी ऑर्डर का उपयोग करने के बजाए किसी विशिष्ट भाषा या लोकेल के रूपांतरणों के अनुसार सॉर्ट किए गए डेटा के लिए, एन्कोडिंग फ़ॉर्म के बावजूद डेटा को वही आदेश दिया जाएगा।

Answer 7

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

अगर मैं दुनिया को फिर से शुरू करना चाहता हूं, तो शायद मैं यूटीएफ -32 के लिए जाऊंगा क्योंकि यह केवल कम से कम जटिल एन्कोडिंग है, लेकिन जैसा कि यह खड़ा है कि मतभेद व्यावहारिक चिंता के लिए बहुत छोटे हैं।