यूटीएफ-32: Difference between revisions

From Vigyanwiki
(Created page with "{{Short description|Storing Unicode as 4 bytes per code point}} UTF-32 (32-अंश यूनिकोड ट्रांसफ़ॉर्मेशन फ़ॉर्...")
 
No edit summary
Line 2: Line 2:
UTF-32 (32-[[ अंश ]] यूनिकोड ट्रांसफ़ॉर्मेशन फ़ॉर्मेट) यूनिकोड [[ कोड बिंदु ]]्स को एनकोड करने के लिए उपयोग किया जाने वाला एक निश्चित-लंबाई वाला [[अक्षरों को सांकेतिक अक्षरों में बदलना]] है, जो प्रति कोड पॉइंट के ठीक 32 बिट्स (चार [[बाइट]]्स) का उपयोग करता है (लेकिन प्रमुख बिट्स की संख्या शून्य होनी चाहिए क्योंकि वहाँ बहुत 2 से कम<sup>32</sup> यूनिकोड कोड बिंदु, वास्तव में केवल 21 बिट्स की आवश्यकता है)।<ref name="4_or_3_bytes" />यूटीएफ -32 एक निश्चित-लंबाई एन्कोडिंग है, अन्य सभी यूनिकोड रूपांतरण प्रारूपों के विपरीत, जो चर-लंबाई वाले एन्कोडिंग हैं। UTF-32 में प्रत्येक 32-बिट मान एक यूनिकोड कोड बिंदु का प्रतिनिधित्व करता है और उस कोड बिंदु के संख्यात्मक मान के बिल्कुल बराबर होता है।
UTF-32 (32-[[ अंश ]] यूनिकोड ट्रांसफ़ॉर्मेशन फ़ॉर्मेट) यूनिकोड [[ कोड बिंदु ]]्स को एनकोड करने के लिए उपयोग किया जाने वाला एक निश्चित-लंबाई वाला [[अक्षरों को सांकेतिक अक्षरों में बदलना]] है, जो प्रति कोड पॉइंट के ठीक 32 बिट्स (चार [[बाइट]]्स) का उपयोग करता है (लेकिन प्रमुख बिट्स की संख्या शून्य होनी चाहिए क्योंकि वहाँ बहुत 2 से कम<sup>32</sup> यूनिकोड कोड बिंदु, वास्तव में केवल 21 बिट्स की आवश्यकता है)।<ref name="4_or_3_bytes" />यूटीएफ -32 एक निश्चित-लंबाई एन्कोडिंग है, अन्य सभी यूनिकोड रूपांतरण प्रारूपों के विपरीत, जो चर-लंबाई वाले एन्कोडिंग हैं। UTF-32 में प्रत्येक 32-बिट मान एक यूनिकोड कोड बिंदु का प्रतिनिधित्व करता है और उस कोड बिंदु के संख्यात्मक मान के बिल्कुल बराबर होता है।


UTF-32 का मुख्य लाभ यह है कि यूनिकोड कोड बिंदु सीधे अनुक्रमित होते हैं। कोड बिंदुओं के क्रम में Nth कोड बिंदु ढूँढना एक [[निरंतर समय]] है | निरंतर-समय संचालन। इसके विपरीत, एक चर-लंबाई कोड को स्ट्रिंग की शुरुआत से एन कोड बिंदुओं की गणना करने के लिए [[रैखिक समय]] | रैखिक-समय की आवश्यकता होती है। यह UTF-32 को कोड में एक साधारण प्रतिस्थापन बनाता है जो एक स्ट्रिंग में प्रत्येक स्थान की जांच करने के लिए एक द्वारा बढ़ाए गए पूर्णांक का उपयोग करता है, जैसा कि आमतौर पर [[ASCII]] के लिए किया जाता था। हालांकि, यूनिकोड कोड बिंदुओं को शायद ही कभी पूर्ण अलगाव में संसाधित किया जाता है, जैसे चरित्र अनुक्रमों का संयोजन और इमोजी के लिए।<ref name=":0">{{Cite web |title=FAQ - UTF-8, UTF-16, UTF-32 & BOM |url=http://unicode.org/faq/utf_bom.html#utf32-2 |access-date=2022-09-04 |website=unicode.org}}</ref>
UTF-32 का मुख्य लाभ यह है कि यूनिकोड कोड बिंदु सीधे अनुक्रमित होते हैं। कोड बिंदुओं के क्रम में Nth कोड बिंदु ढूँढना एक [[निरंतर समय]] है | निरंतर-समय संचालन। इसके विपरीत, एक चर-लंबाई कोड को स्ट्रिंग की शुरुआत से एन कोड बिंदुओं की गणना करने के लिए [[रैखिक समय]] | रैखिक-समय की आवश्यकता होती है। यह UTF-32 को कोड में एक साधारण प्रतिस्थापन बनाता है जो एक स्ट्रिंग में प्रत्येक स्थान की जांच करने के लिए एक द्वारा बढ़ाए गए पूर्णांक का उपयोग करता है, जैसा कि सामान्यतः [[ASCII]] के लिए किया जाता था। चूँकि, यूनिकोड कोड बिंदुओं को शायद ही कभी पूर्ण अलगाव में संसाधित किया जाता है, जैसे चरित्र अनुक्रमों का संयोजन और इमोजी के लिए।<ref name=":0">{{Cite web |title=FAQ - UTF-8, UTF-16, UTF-32 & BOM |url=http://unicode.org/faq/utf_bom.html#utf32-2 |access-date=2022-09-04 |website=unicode.org}}</ref>
UTF-32 का मुख्य नुकसान यह है कि यह अंतरिक्ष-अक्षम है, प्रति कोड बिंदु चार बाइट्स का उपयोग करता है, जिसमें 11 बिट्स शामिल हैं जो हमेशा शून्य होते हैं। मूल बहुभाषी स्तर से परे वर्ण अधिकांश पाठों में अपेक्षाकृत दुर्लभ हैं (उदाहरण के लिए कुछ लोकप्रिय इमोजी वाले पाठों को छोड़कर), और आमतौर पर अनुमानों को आकार देने के लिए अनदेखा किया जा सकता है। यह UTF-32 को UTF-16 के दोगुने आकार के करीब बनाता है। यह ASCII सबसेट में कितने वर्णों के आधार पर UTF-8 के आकार का चार गुना तक हो सकता है।<ref name=":0" />
UTF-32 का मुख्य नुकसान यह है कि यह अंतरिक्ष-अक्षम है, प्रति कोड बिंदु चार बाइट्स का उपयोग करता है, जिसमें 11 बिट्स सम्मिलित हैं जो हमेशा शून्य होते हैं। मूल बहुभाषी स्तर से परे वर्ण अधिकांश पाठों में अपेक्षाकृत दुर्लभ हैं (उदाहरण के लिए कुछ लोकप्रिय इमोजी वाले पाठों को छोड़कर), और सामान्यतः अनुमानों को आकार देने के लिए अनदेखा किया जा सकता है। यह UTF-32 को UTF-16 के दोगुने आकार के करीब बनाता है। यह ASCII सबसेट में कितने वर्णों के आधार पर UTF-8 के आकार का चार गुना तक हो सकता है।<ref name=":0" />




== इतिहास ==
== इतिहास ==
मूल ISO/IEC 10646 मानक 'UCS-4' नामक 32-बिट एन्कोडिंग फॉर्म को परिभाषित करता है, जिसमें यूनिवर्सल कैरेक्टर सेट (UCS) में प्रत्येक कोड बिंदु को 0x7FFFFFFF (साइन बिट) से 31-बिट मान द्वारा दर्शाया जाता है। अप्रयुक्त और शून्य था)। नवंबर 2003 में, यूनिकोड को RFC 3629 द्वारा UTF-16 एन्कोडिंग की बाधाओं से मेल खाने के लिए प्रतिबंधित किया गया था: स्पष्ट रूप से U+10FFFF (और उच्च और निम्न प्रतिनिधि U+D800 के माध्यम से U+DFFF) से अधिक कोड बिंदुओं को प्रतिबंधित करना। यह सीमित उपसमुच्चय UTF-32 को परिभाषित करता है।<ref>{{Cite web|title=<!--Publicly Available Standards--> ISO/IEC 10646:2020 |url=https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html|access-date=2021-10-12|website=standards.iso.org|quote=Clause 9.4: "Because surrogate code points are not UCS scalar values, UTF-32 code units in the range 0000 D800-0000 DFFF are ill-formed". Clause 4.57: "[UCS codespace] <!--doubt this is in any source, or then redundant previously: codespace--> consisting of the integers from 0 to 10 FFFF (hexadecimal)".<!--in an older(?) source like: "uses the UCS codespace which consists of the integers from 0 to 10FFFF."[http://std.dkuug.dk/JTC1/sc2/WG2/docs/n3967.zip/FCD-10646-00-Main.pdf]--> Clause 4.58: "[UCS scalar value] any UCS code point except high-surrogate and low-surrogate code points".}}</ref><ref name="4_or_3_bytes">{{Cite web |title=यूनिकोड एन्कोडिंग रूपों के लिए मैपिंग कोडपॉइंट्स|url=https://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-AppendixA |access-date=2022-10-03 |website=scripts.sil.org}</ref> हालांकि आईएसओ मानक (यूनिकोड 2.1 में 1998 तक) निजी उपयोग के लिए 0xE00000 से 0xFFFFFF, और 0x60000000 से 0x7FFFFFF के लिए आरक्षित था रेफरी>{{Cite web |title=यूनिवर्सल कैरेक्टर सेट (यूसीएस)|url=http://std.dkuug.dk/cen/tc304/guidecharactersets/guideannexb.html |access-date=2022-10-03 |website=std.dkuug.dk}}</ref> इन क्षेत्रों को बाद के संस्करणों में हटा दिया गया था। क्योंकि ISO/IEC JTC 1/SC 2 वर्किंग ग्रुप 2 के सिद्धांतों और प्रक्रियाओं के दस्तावेज़ में कहा गया है कि भविष्य में कोड पॉइंट के सभी असाइनमेंट यूनिकोड रेंज तक सीमित रहेंगे, UTF-32 सभी UCS कोड पॉइंट और UTF-32 का प्रतिनिधित्व करने में सक्षम होगा और UCS-4 समान हैं।
मूल ISO/IEC 10646 मानक 'UCS-4' नामक 32-बिट एन्कोडिंग फॉर्म को परिभाषित करता है, जिसमें यूनिवर्सल कैरेक्टर सेट (UCS) में प्रत्येक कोड बिंदु को 0x7FFFFFFF (साइन बिट) से 31-बिट मान द्वारा दर्शाया जाता है। अप्रयुक्त और शून्य था)। नवंबर 2003 में, यूनिकोड को RFC 3629 द्वारा UTF-16 एन्कोडिंग की बाधाओं से मेल खाने के लिए प्रतिबंधित किया गया था: स्पष्ट रूप से U+10FFFF (और उच्च और निम्न प्रतिनिधि U+D800 के माध्यम से U+DFFF) से अधिक कोड बिंदुओं को प्रतिबंधित करना। यह सीमित उपसमुच्चय UTF-32 को परिभाषित करता है।<ref>{{Cite web|title=<!--Publicly Available Standards--> ISO/IEC 10646:2020 |url=https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html|access-date=2021-10-12|website=standards.iso.org|quote=Clause 9.4: "Because surrogate code points are not UCS scalar values, UTF-32 code units in the range 0000 D800-0000 DFFF are ill-formed". Clause 4.57: "[UCS codespace] <!--doubt this is in any source, or then redundant previously: codespace--> consisting of the integers from 0 to 10 FFFF (hexadecimal)".<!--in an older(?) source like: "uses the UCS codespace which consists of the integers from 0 to 10FFFF."[http://std.dkuug.dk/JTC1/sc2/WG2/docs/n3967.zip/FCD-10646-00-Main.pdf]--> Clause 4.58: "[UCS scalar value] any UCS code point except high-surrogate and low-surrogate code points".}}</ref><ref name="4_or_3_bytes">{{Cite web |title=यूनिकोड एन्कोडिंग रूपों के लिए मैपिंग कोडपॉइंट्स|url=https://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-AppendixA |access-date=2022-10-03 |website=scripts.sil.org}</ref> चूँकि आईएसओ मानक (यूनिकोड 2.1 में 1998 तक) निजी उपयोग के लिए 0xE00000 से 0xFFFFFF, और 0x60000000 से 0x7FFFFFF के लिए आरक्षित था रेफरी>{{Cite web |title=यूनिवर्सल कैरेक्टर सेट (यूसीएस)|url=http://std.dkuug.dk/cen/tc304/guidecharactersets/guideannexb.html |access-date=2022-10-03 |website=std.dkuug.dk}}</ref> इन क्षेत्रों को बाद के संस्करणों में हटा दिया गया था। क्योंकि ISO/IEC JTC 1/SC 2 वर्किंग ग्रुप 2 के सिद्धांतों और प्रक्रियाओं के दस्तावेज़ में कहा गया है कि भविष्य में कोड पॉइंट के सभी असाइनमेंट यूनिकोड रेंज तक सीमित रहेंगे, UTF-32 सभी UCS कोड पॉइंट और UTF-32 का प्रतिनिधित्व करने में सक्षम होगा और UCS-4 समान हैं।


== विश्लेषण ==
== विश्लेषण ==
हालांकि प्रति कोड बिंदु बाइट्स की एक निश्चित संख्या सुविधाजनक लगती है, यह उतना उपयोगी नहीं है जितना लगता है। यह ट्रंकेशन को आसान बनाता है, लेकिन UTF-8 और UTF-16 की तुलना में महत्वपूर्ण नहीं है (दोनों अधिकतम 2-4 कोड इकाइयों को देखकर ट्रंकेट करने के लिए पीछे की ओर खोज सकते हैं)।{{efn|For UTF-8: Select point to truncate at. If the byte before it is 0-0x7F, or the byte after it is anything other than the continuation bytes 0x80-0xBF, the string can be truncated at that point. Otherwise search up to 3 bytes backwards for such a point and truncate at that. If not found, truncate at the original position. This works even if there are encoding errors in the UTF-8. UTF-16 is trivial and only has to back up one word at most.}}{{citation needed|date=January 2023}}
चूँकि प्रति कोड बिंदु बाइट्स की एक निश्चित संख्या सुविधाजनक लगती है, यह उतना उपयोगी नहीं है जितना लगता है। यह ट्रंकेशन को आसान बनाता है, लेकिन UTF-8 और UTF-16 की तुलना में महत्वपूर्ण नहीं है (दोनों अधिकतम 2-4 कोड इकाइयों को देखकर ट्रंकेट करने के लिए पीछे की ओर खोज सकते हैं)।{{efn|For UTF-8: Select point to truncate at. If the byte before it is 0-0x7F, or the byte after it is anything other than the continuation bytes 0x80-0xBF, the string can be truncated at that point. Otherwise search up to 3 bytes backwards for such a point and truncate at that. If not found, truncate at the original position. This works even if there are encoding errors in the UTF-8. UTF-16 is trivial and only has to back up one word at most.}}{{citation needed|date=January 2023}}


यह अत्यंत दुर्लभ है कि कोड इस स्थिति और स्ट्रिंग के एक छोर के बीच सभी वर्णों की जांच करके N की गणना किए बिना एक स्ट्रिंग में Nth वर्ण को खोजना चाहता है।<ref name=manishearth>{{Cite web|title=आइए कोड बिंदुओं का अर्थ बताना बंद करें - आलस्य की खोज में|url=https://manishearth.github.io/blog/2017/01/14/stop-ascribing-meaning-to-unicode-code-points/|access-date=2020-06-14|quote=लोग यह बताना शुरू करते हैं कि कोड बिंदुओं का मतलब कुछ है, और कोड बिंदु सीमाओं पर ओ (1) इंडेक्सिंग या स्लाइसिंग एक उपयोगी ऑपरेशन है।|website=manishearth.github.io}}</ref> उदाहरण के लिए किसी भी [[एलएएलआर]] पार्सर (जैसे एक्सएमएल के लिए) को एनएच कोड बिंदु के साथ कुछ भी करने में सक्षम होने से पहले पिछले सभी कोड बिंदुओं को देखने की जरूरत है। एक पूर्णांक सूचकांक जो प्रत्येक वर्ण के लिए 1 से बढ़ा हुआ है, को एक पूर्णांक ऑफ़सेट के साथ प्रतिस्थापित किया जा सकता है, जिसे कोड इकाइयों में मापा जाता है और कोड इकाइयों की संख्या में वृद्धि की जाती है क्योंकि प्रत्येक वर्ण की जांच की जाती है। यह UTF-32 के किसी भी गति लाभ को हटा देता है।{{citation needed|date=January 2023}}
यह अत्यंत दुर्लभ है कि कोड इस स्थिति और स्ट्रिंग के एक छोर के बीच सभी वर्णों की जांच करके N की गणना किए बिना एक स्ट्रिंग में Nth वर्ण को खोजना चाहता है।<ref name=manishearth>{{Cite web|title=आइए कोड बिंदुओं का अर्थ बताना बंद करें - आलस्य की खोज में|url=https://manishearth.github.io/blog/2017/01/14/stop-ascribing-meaning-to-unicode-code-points/|access-date=2020-06-14|quote=लोग यह बताना शुरू करते हैं कि कोड बिंदुओं का मतलब कुछ है, और कोड बिंदु सीमाओं पर ओ (1) इंडेक्सिंग या स्लाइसिंग एक उपयोगी ऑपरेशन है।|website=manishearth.github.io}}</ref> उदाहरण के लिए किसी भी [[एलएएलआर]] पार्सर (जैसे एक्सएमएल के लिए) को एनएच कोड बिंदु के साथ कुछ भी करने में सक्षम होने से पहले पिछले सभी कोड बिंदुओं को देखने की जरूरत है। एक पूर्णांक सूचकांक जो प्रत्येक वर्ण के लिए 1 से बढ़ा हुआ है, को एक पूर्णांक ऑफ़सेट के साथ प्रतिस्थापित किया जा सकता है, जिसे कोड इकाइयों में मापा जाता है और कोड इकाइयों की संख्या में वृद्धि की जाती है क्योंकि प्रत्येक वर्ण की जांच की जाती है। यह UTF-32 के किसी भी गति लाभ को हटा देता है।{{citation needed|date=January 2023}}
Line 18: Line 18:


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


Windows पर UTF-32 स्ट्रिंग्स का उपयोग (जहाँ {{mono|wchar_t}} 16 बिट्स है) लगभग न के बराबर है। यूनिक्स सिस्टम पर, यूटीएफ -32 तार कभी-कभी होते हैं, लेकिन शायद ही कभी, अनुप्रयोगों द्वारा आंतरिक रूप से उपयोग किए जाते हैं, प्रकार के कारण {{mono|[[wchar_t]]}} को 32 बिट के रूप में परिभाषित किया जा रहा है। 3.2 तक के [[पायथन (प्रोग्रामिंग भाषा)]] संस्करणों को UTF-16 के बजाय उनका उपयोग करने के लिए संकलित किया जा सकता है; संस्करण 3.3 से आगे सभी यूनिकोड स्ट्रिंग्स को UTF-32 में संग्रहीत किया जाता है, लेकिन प्रमुख शून्य बाइट्स को [कोड बिंदु] के आधार पर सबसे बड़े यूनिकोड क्रमसूचक (1, 2, या 4 बाइट्स) के आधार पर अनुकूलित किया जाता है ताकि सभी कोड बिंदुओं को आकार दिया जा सके।<ref>{{cite web|last1=Löwis|first1=Martin|title=PEP 393 -- Flexible String Representation|url=https://legacy.python.org/dev/peps/pep-0393/|website=python.org|publisher=Python|access-date=26 October 2014}}</ref> [[सही]]<ref>{{cite web|url=http://seed7.sourceforge.net/faq.htm#unicode|title=The usage of UTF-32 has several advantages}}</ref> और कमंद (प्रोग्रामिंग भाषा){{Citation needed|date=June 2017}[[जूलिया (प्रोग्रामिंग भाषा)]] UTF-32 के साथ सभी स्ट्रिंग्स को एनकोड करती हैं, इस विश्वास में कि डायरेक्ट इंडेक्सिंग महत्वपूर्ण है, जबकि जूलिया (प्रोग्रामिंग लैंग्वेज) प्रोग्रामिंग लैंग्वेज अपने 1.0 रिलीज के साथ बिल्ट-इन UTF-32 सपोर्ट से दूर चली गई, केवल UTF होने के लिए भाषा को सरल बनाना- 8 स्ट्रिंग्स (अन्य सभी एनकोडिंग को लीगेसी माना जाता है और मानक लाइब्रेरी से पैकेज<ref>{{Citation|title=JuliaStrings/LegacyStrings.jl: Legacy Unicode string types|date=2019-05-17|url=https://github.com/JuliaStrings/LegacyStrings.jl|publisher=JuliaStrings|access-date=2019-10-15}}</ref>) UTF-8 एवरीवेयर मेनिफेस्टो का पालन कर रहा हूं।<ref>{{cite web |url=http://utf8everywhere.org/ |title=UTF-8 Everywhere Manifesto}}</ref>
Windows पर UTF-32 स्ट्रिंग्स का उपयोग (जहाँ {{mono|wchar_t}} 16 बिट्स है) लगभग न के बराबर है। यूनिक्स सिस्टम पर, यूटीएफ -32 तार कभी-कभी होते हैं, लेकिन शायद ही कभी, अनुप्रयोगों द्वारा आंतरिक रूप से उपयोग किए जाते हैं, प्रकार के कारण {{mono|[[wchar_t]]}} को 32 बिट के रूप में परिभाषित किया जा रहा है। 3.2 तक के [[पायथन (प्रोग्रामिंग भाषा)]] संस्करणों को UTF-16 के अतिरिक्त  उनका उपयोग करने के लिए संकलित किया जा सकता है; संस्करण 3.3 से आगे सभी यूनिकोड स्ट्रिंग्स को UTF-32 में संग्रहीत किया जाता है, लेकिन प्रमुख शून्य बाइट्स को [कोड बिंदु] के आधार पर सबसे बड़े यूनिकोड क्रमसूचक (1, 2, या 4 बाइट्स) के आधार पर अनुकूलित किया जाता है जिससे कि सभी कोड बिंदुओं को आकार दिया जा सके।<ref>{{cite web|last1=Löwis|first1=Martin|title=PEP 393 -- Flexible String Representation|url=https://legacy.python.org/dev/peps/pep-0393/|website=python.org|publisher=Python|access-date=26 October 2014}}</ref> [[सही]]<ref>{{cite web|url=http://seed7.sourceforge.net/faq.htm#unicode|title=The usage of UTF-32 has several advantages}}</ref> और कमंद (प्रोग्रामिंग भाषा){{Citation needed|date=June 2017}[[जूलिया (प्रोग्रामिंग भाषा)]] UTF-32 के साथ सभी स्ट्रिंग्स को एनकोड करती हैं, इस विश्वास में कि डायरेक्ट इंडेक्सिंग महत्वपूर्ण है, जबकि जूलिया (प्रोग्रामिंग लैंग्वेज) प्रोग्रामिंग लैंग्वेज अपने 1.0 रिलीज के साथ बिल्ट-इन UTF-32 सपोर्ट से दूर चली गई, केवल UTF होने के लिए भाषा को सरल बनाना- 8 स्ट्रिंग्स (अन्य सभी एनकोडिंग को लीगेसी माना जाता है और मानक लाइब्रेरी से पैकेज<ref>{{Citation|title=JuliaStrings/LegacyStrings.jl: Legacy Unicode string types|date=2019-05-17|url=https://github.com/JuliaStrings/LegacyStrings.jl|publisher=JuliaStrings|access-date=2019-10-15}}</ref>) UTF-8 एवरीवेयर मेनिफेस्टो का पालन कर रहा हूं।<ref>{{cite web |url=http://utf8everywhere.org/ |title=UTF-8 Everywhere Manifesto}}</ref>




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


== यह भी देखें ==
== यह भी देखें ==

Revision as of 19:14, 3 May 2023

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

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


इतिहास

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

विश्लेषण

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

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

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


प्रयोग

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

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


वेरिएंट

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

यह भी देखें

टिप्पणियाँ

  1. ↑ For UTF-8: Select point to truncate at. If the byte before it is 0-0x7F, or the byte after it is anything other than the continuation bytes 0x80-0xBF, the string can be truncated at that point. Otherwise search up to 3 bytes backwards for such a point and truncate at that. If not found, truncate at the original position. This works even if there are encoding errors in the UTF-8. UTF-16 is trivial and only has to back up one word at most.


संदर्भ

  1. ↑ 1.0 1.1 {{Cite web |title=यूनिकोड एन्कोडिंग रूपों के लिए मैपिंग कोडपॉइंट्स|url=https://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-AppendixA |access-date=2022-10-03 |website=scripts.sil.org}
  2. ↑ 2.0 2.1 "FAQ - UTF-8, UTF-16, UTF-32 & BOM". unicode.org. Retrieved 2022-09-04.
  3. ↑ "ISO/IEC 10646:2020". standards.iso.org. Retrieved 2021-10-12. Clause 9.4: "Because surrogate code points are not UCS scalar values, UTF-32 code units in the range 0000 D800-0000 DFFF are ill-formed". Clause 4.57: "[UCS codespace] consisting of the integers from 0 to 10 FFFF (hexadecimal)". Clause 4.58: "[UCS scalar value] any UCS code point except high-surrogate and low-surrogate code points".
  4. ↑ 4.0 4.1 "आइए कोड बिंदुओं का अर्थ बताना बंद करें - आलस्य की खोज में". manishearth.github.io. Retrieved 2020-06-14. लोग यह बताना शुरू करते हैं कि कोड बिंदुओं का मतलब कुछ है, और कोड बिंदु सीमाओं पर ओ (1) इंडेक्सिंग या स्लाइसिंग एक उपयोगी ऑपरेशन है।
  5. ↑ "↔️ Emoji ZWJ (Zero Width Joiner) Sequences". emojipedia.org. Retrieved 2021-10-12.
  6. ↑ "👨‍🦲 Man: Bald Emoji". Emojipedia (in English). Retrieved 2021-10-12.
  7. ↑ "👩‍🦰 Woman: Red Hair Emoji". Emojipedia (in English). Retrieved 2021-10-12.
  8. ↑ Löwis, Martin. "PEP 393 -- Flexible String Representation". python.org. Python. Retrieved 26 October 2014.
  9. ↑ "The usage of UTF-32 has several advantages".
  10. ↑ JuliaStrings/LegacyStrings.jl: Legacy Unicode string types, JuliaStrings, 2019-05-17, retrieved 2019-10-15
  11. ↑ "UTF-8 Everywhere Manifesto".


बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=यूटीएफ-32&oldid=157227’