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

From Vigyanwiki
m (20 revisions imported from alpha:यूटीएफ-32)
(No difference)

Revision as of 12:32, 16 May 2023

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

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

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


इतिहास

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

विश्लेषण

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

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

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


प्रयोग

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

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


वेरिएंट

चूँकि तकनीकी रूप से अमान्य, सरोगेट भागों को प्रायः एन्कोड किया जाता है और अनुमति दी जाती है। यह अमान्य यूटीएफ-16 (जैसे विंडोज फ़ाइल नाम) को यूटीएफ-32 में अनुवाद करने की अनुमति देता है, उसी प्रकार जैसे यूटीएफ-8 का डब्ल्यूटीएफ-8 संस्करण कार्य करता है। कभी-कभी सीईएसयू-8 के समान, गैर-बीएमपी वर्णों के अतिरिक्त युग्मित सरोगेट्स को एन्कोड किया जाता है। बड़ी संख्या में अप्रयुक्त 32-बिट मानों के कारण, यूटीएफ-8 त्रुटियों को एन्कोड करने के लिए गैर-यूनिकोड मानों का उपयोग करके अमान्य यूटीएफ-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".


बाहरी संबंध