यूटीएफ-32

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

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

इतिहास
मूल ISO/IEC 10646 मानक 'UCS-4' नामक 32-बिट एन्कोडिंग फॉर्म को परिभाषित करता है, जिसमें यूनिवर्सल कैरेक्टर सेट (UCS) में प्रत्येक कोड बिंदु को 0x7FFFFFFF (साइन बिट) से 31-बिट मान द्वारा दर्शाया जाता है। अप्रयुक्त और शून्य था)। नवंबर 2003 में, यूनिकोड को RFC 3629 द्वारा UTF-16 एन्कोडिंग की बाधाओं से मेल खाने के लिए प्रतिबंधित किया गया था: स्पष्ट रूप से U+10FFFF (और उच्च और निम्न प्रतिनिधि U+D800 के माध्यम से U+DFFF) से अधिक कोड बिंदुओं को प्रतिबंधित करना। यह सीमित उपसमुच्चय UTF-32 को परिभाषित करता है। हालांकि आईएसओ मानक (यूनिकोड 2.1 में 1998 तक) निजी उपयोग के लिए 0xE00000 से 0xFFFFFF, और 0x60000000 से 0x7FFFFFF के लिए आरक्षित था रेफरी> इन क्षेत्रों को बाद के संस्करणों में हटा दिया गया था। क्योंकि ISO/IEC JTC 1/SC 2 वर्किंग ग्रुप 2 के सिद्धांतों और प्रक्रियाओं के दस्तावेज़ में कहा गया है कि भविष्य में कोड पॉइंट के सभी असाइनमेंट यूनिकोड रेंज तक सीमित रहेंगे, UTF-32 सभी UCS कोड पॉइंट और UTF-32 का प्रतिनिधित्व करने में सक्षम होगा और UCS-4 समान हैं।

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

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

एक निश्चित चौड़ाई वाले फ़ॉन्ट के साथ भी कोड बिंदुओं की गिनती से स्ट्रिंग की चौड़ाई का पता लगाना असंभव है। दो कोड बिंदुओं 'e' + '́' (और बहु-कोड-बिंदु इमोजी, Miscellaneous_Symbols_and_Pictographs#Emoji_modifiers और इमोजी शून्य-चौड़ाई जॉइनर अनुक्रमों के कारण व्यक्त किए गए 'é' जैसे संयोजन वर्ण हैं, उदाहरण के लिए ये दोनों इमोजी 3 कोड पॉइंट हैं: 👨‍🦲 आदमी: गंजा और 👩‍🦰 महिला: लाल बाल . ). साथ ही निश्चित चौड़ाई CJK वर्णों को 2 की चौड़ाई प्रदान कर सकती है, और कुछ कोड बिंदु प्रति कोड बिंदु (CJK के लिए ग्रैफेम क्लस्टर) में कई वर्ण स्थिति लेते हैं।

प्रयोग
UTF-32 का मुख्य उपयोग आंतरिक एपीआई में होता है जहां डेटा वर्णों के तार के बजाय एकल कोड बिंदु या ग्लिफ़ होता है। उदाहरण के लिए, आधुनिक टेक्स्ट रेंडरिंग में, यह सामान्य है कि अंतिम चरण संरचनाओं की एक सूची बनाने के लिए है जिसमें प्रत्येक समन्वय प्रणाली | निर्देशांक (x, y), विशेषताएँ, और एक एकल UTF-32 कोड बिंदु है जो ग्लिफ़ को आकर्षित करने की पहचान करता है। अक्सर गैर-यूनिकोड जानकारी प्रत्येक शब्द के अप्रयुक्त 11 बिट्स में संग्रहीत होती है।

Windows पर UTF-32 स्ट्रिंग्स का उपयोग (जहाँ wchar_t 16 बिट्स है) लगभग न के बराबर है। यूनिक्स सिस्टम पर, यूटीएफ -32 तार कभी-कभी होते हैं, लेकिन शायद ही कभी, अनुप्रयोगों द्वारा आंतरिक रूप से उपयोग किए जाते हैं, प्रकार के कारण wchar_t को 32 बिट के रूप में परिभाषित किया जा रहा है। 3.2 तक के पायथन (प्रोग्रामिंग भाषा) संस्करणों को UTF-16 के बजाय उनका उपयोग करने के लिए संकलित किया जा सकता है; संस्करण 3.3 से आगे सभी यूनिकोड स्ट्रिंग्स को UTF-32 में संग्रहीत किया जाता है, लेकिन प्रमुख शून्य बाइट्स को [कोड बिंदु] के आधार पर सबसे बड़े यूनिकोड क्रमसूचक (1, 2, या 4 बाइट्स) के आधार पर अनुकूलित किया जाता है ताकि सभी कोड बिंदुओं को आकार दिया जा सके। सही और कमंद (प्रोग्रामिंग भाषा){{Citation needed|date=June 2017}जूलिया (प्रोग्रामिंग भाषा) UTF-32 के साथ सभी स्ट्रिंग्स को एनकोड करती हैं, इस विश्वास में कि डायरेक्ट इंडेक्सिंग महत्वपूर्ण है, जबकि जूलिया (प्रोग्रामिंग लैंग्वेज) प्रोग्रामिंग लैंग्वेज अपने 1.0 रिलीज के साथ बिल्ट-इन UTF-32 सपोर्ट से दूर चली गई, केवल UTF होने के लिए भाषा को सरल बनाना- 8 स्ट्रिंग्स (अन्य सभी एनकोडिंग को लीगेसी माना जाता है और मानक लाइब्रेरी से पैकेज ) UTF-8 एवरीवेयर मेनिफेस्टो का पालन कर रहा हूं।

वेरिएंट
हालांकि तकनीकी रूप से अमान्य, सरोगेट हिस्सों को अक्सर एन्कोड किया जाता है और अनुमति दी जाती है। यह अमान्य UTF-16 (जैसे Windows फ़ाइल नाम) को UTF-32 में अनुवाद करने की अनुमति देता है, ठीक उसी तरह जैसे UTF-8 का WTF-8 संस्करण काम करता है। कभी-कभी सीईएसयू-8 -8 के समान, गैर-बीएमपी वर्णों के बजाय युग्मित सरोगेट्स को एन्कोड किया जाता है। बड़ी संख्या में अप्रयुक्त 32-बिट मानों के कारण, UTF-8 त्रुटियों को एन्कोड करने के लिए गैर-यूनिकोड मानों का उपयोग करके अमान्य UTF-8 को संरक्षित करना भी संभव है, हालांकि इसके लिए कोई मानक नहीं है।

यह भी देखें

 * यूनिकोड एनकोडिंग की तुलना

बाहरी संबंध

 * The Unicode Standard 5.0.0, chapter 3 – formally defines UTF-32 in § 3.9, D90 (PDF page 40) and § 3.10, D99-D101 (PDF page 45)
 * Unicode Standard Annex #19 – formally defined UTF-32 for Unicode 3.x (March 2001; last updated March 2002)
 * Registration of new charsets: UTF-32, UTF-32BE, UTF-32LE – announcement of UTF-32 being added to the IANA charset registry (April 2002)