अशक्त-समाप्त स्ट्रिंग (नल्ल-टर्मिनेटेड स्ट्रिंग): Difference between revisions

From Vigyanwiki
No edit summary
No edit summary
Line 4: Line 4:
}}
}}


[[कंप्यूटर प्रोग्रामिंग]] में, एक '''रिक्त-टर्मिनेटेड स्ट्रिंग''' एक [[वर्ण स्ट्रिंग]] है जिसे वर्णों वाले एक [[सरणी डेटा संरचना]] के रूप में संग्रहीत किया जाता है और एक शून्य वर्ण (शून्य के मान वाला एक वर्ण, जिसे इस आलेख में एनयूएल कहा जाता है) के साथ समाप्त किया जाता है। वैकल्पिक नाम C स्ट्रिंग हैं, जो C प्रोग्रामिंग भाषा और ASCIIZ को संदर्भित करता है हालाँकि [[सी (प्रोग्रामिंग भाषा)]] और एएससीआईआईजेड के अलावा अन्य एन्कोडिंग का उपयोग कर सकता है।{{citation needed|date=November 2021}}
[[कंप्यूटर प्रोग्रामिंग]] में '''रिक्त-सीमित स्ट्रिंग''' एक [[वर्ण स्ट्रिंग]] है जिसे वर्णों की [[सरणी डेटा संरचना]] के रूप में संग्रहीत किया जाता है। एक शून्य वर्ण (शून्य के मान वाला एक वर्ण, जिसे इस आलेख में एनयूएल कहा जाता है) के साथ समाप्त किया जाता है। इसका वैकल्पिक नाम सी-स्ट्रिंग हैं, जो C प्रोग्रामिंग भाषा और एएससीआईआईजेड भाषा को संदर्भित करती है। हालाँकि [[सी (प्रोग्रामिंग भाषा)]] और एएससीआईआईजेड भाषा के अतिरिक्त यह अन्य एन्कोडिंग का उपयोग कर सकती है।{{citation needed|date=November 2021}}


एक स्ट्रिंग की लंबाई (प्रथम) एनयूएल की खोज करके पाई जाती है। यह धीमा हो सकता है क्योंकि इसमें स्ट्रिंग की लंबाई के संबंध में O(n) (रैखिक समय) लगता है। इसका यह भी अर्थ है कि एक स्ट्रिंग में NUL नहीं हो सकता (मेमोरी में एक NUL है, लेकिन यह अंतिम वर्ण के बाद है जो स्ट्रिंग में "नहीं" है)।
एक स्ट्रिंग की लंबाई (प्रथम) एनयूएल की खोज करके पाई जाती है। यह अपेक्षाकृत धीमी हो सकती है क्योंकि इसमें स्ट्रिंग की लंबाई के संबंध में O(n) रैखिक समय लगता है। इसका यह भी अर्थ है कि एक स्ट्रिंग में रिक्त नहीं हो सकती है, क्योकि यह स्ट्रिंग में <nowiki>''नहीं''</nowiki> अंतिम वर्ण के बाद है।


== इतिहास ==
== इतिहास ==
शून्य-समाप्त स्ट्रिंग्स को [[पीडीपी-11]] असेंबली भाषाओं के <code>.ASCIZ</code> निर्देश और [[PDP-10]] के लिए मैक्रो-10 मैक्रो असेंबली भाषा के <code>ASCIZ</code> निर्देश द्वारा निर्मित किया गया था। ये सी प्रोग्रामिंग भाषा के विकास से पहले के हैं, लेकिन स्ट्रिंग के अन्य रूपों का अक्सर उपयोग किया जाता था।
रिक्त-सीमित स्ट्रिंग को [[पीडीपी-11]] असेंबली भाषाओं के <code>ASCIZ</code> निर्देश और [[PDP-10|पीडीपी]][[PDP-10|-10]] के लिए मैक्रो-10 और मैक्रो असेंबली भाषा के <code>ASCIZ</code> निर्देश द्वारा निर्मित किया गया था। ये सी प्रोग्रामिंग भाषा के विकास से पहले के हैं, लेकिन इनमे स्ट्रिंग के अन्य रूपों का प्रायः उपयोग किया जाता था।


जिस समय C (और जिन भाषाओं से इसे प्राप्त किया गया था) का विकास हुआ था, मेमोरी बेहद सीमित थी, इसलिए स्ट्रिंग की लंबाई को संग्रहीत करने के लिए ओवरहेड के केवल एक बाइट का उपयोग करना आकर्षक था। उस समय का एकमात्र लोकप्रिय विकल्प, जिसे सामान्यतः "पास्कल स्ट्रिंग" कहा जाता है (एक अधिक आधुनिक शब्द "लंबाई-उपसर्ग" है), स्ट्रिंग की लंबाई को संग्रहीत करने के लिए एक अग्रणी बाइट का उपयोग करता था। यह स्ट्रिंग को NUL रखने की अनुमति देता है और पहले से संग्रहीत स्ट्रिंग की लंबाई खोजने के लिए केवल एक मेमोरी एक्सेस (O(1) (स्थिर) समय) की आवश्यकता होती है, लेकिन स्ट्रिंग की लंबाई 255 वर्णों तक सीमित होती है (8-बिट बाइट्स का उपयोग करने वाली मशीन पर) . सी डिजाइनर [[डेनिस रिची]] ने एक स्ट्रिंग की लंबाई पर सीमा से बचने के लिए नल-टर्मिनेशन के सम्मेलन का पालन करना चुना और क्योंकि गिनती बनाए रखना, उनके अनुभव में, टर्मिनेटर का उपयोग करने से कम सुविधाजनक लगता था।<ref>{{cite conference | first = Dennis M. | last = Ritchie | date = April 1993 | location = Cambridge, MA  | title = सी भाषा का विकास| conference = Second History of Programming Languages conference | url = https://www.bell-labs.com/usr/dmr/www/chist.html  }}</ref><ref>{{cite book | first = Dennis M. | last =  Ritchie |  article = The development of the C language | title  = History of Programming Languages | edition = 2 | editor-first1= Thomas J. | editor-last1= Bergin, Jr. | editor-first2 = Richard G. | editor-last2 = Gibson, Jr. | publisher = ACM Press | location = New York | via = Addison-Wesley (Reading, Mass) | year = 1996 | isbn =  0-201-89502-1 }}</ref>
जिस समय C को जिन भाषाओं से इसे प्राप्त किया गया था उनका विकास हुआ क्योकि वे मेमोरी अपेक्षाकृत सीमित थी। इसलिए स्ट्रिंग की लंबाई को संग्रहीत करने के लिए ओवरहेड के केवल एक बाइट का उपयोग करना उपयुक्त था। उस समय का एकमात्र लोकप्रिय विकल्प, जिसे सामान्यतः "पास्कल स्ट्रिंग" कहा जाता है। एक अत्यधिक आधुनिक शब्द "लंबाई-उपसर्ग" है। यह स्ट्रिंग की लंबाई को संग्रहीत करने के लिए एक अग्रणी बाइट का उपयोग करता था। यह स्ट्रिंग को रिक्त रखने की स्वीकृति देता है और पहले से संग्रहीत स्ट्रिंग की लंबाई खोजने के लिए केवल एक मेमोरी नियंत्रण (O(1) स्थिर समय की आवश्यकता होती है, लेकिन स्ट्रिंग की लंबाई 255 वर्णों तक सीमित होती है। 8-बिट का उपयोग करने वाली मशीन पर सी विकासक [[डेनिस रिची]] ने एक स्ट्रिंग की लंबाई पर सीमा से बचने के लिए रिक्त-सीमित स्ट्रिंग के फंक्शन का अनुसरण करना चुना और क्योंकि गणना बनाए रखना उनके अनुभव में परिवर्तक का उपयोग करने से कम सुविधाजनक लगता था।<ref>{{cite conference | first = Dennis M. | last = Ritchie | date = April 1993 | location = Cambridge, MA  | title = सी भाषा का विकास| conference = Second History of Programming Languages conference | url = https://www.bell-labs.com/usr/dmr/www/chist.html  }}</ref><ref>{{cite book | first = Dennis M. | last =  Ritchie |  article = The development of the C language | title  = History of Programming Languages | edition = 2 | editor-first1= Thomas J. | editor-last1= Bergin, Jr. | editor-first2 = Richard G. | editor-last2 = Gibson, Jr. | publisher = ACM Press | location = New York | via = Addison-Wesley (Reading, Mass) | year = 1996 | isbn =  0-201-89502-1 }}</ref>


इसका सीपीयू अनुदेश सेट डिज़ाइन पर कुछ प्रभाव पड़ा। 1970 और 1980 के दशक में कुछ सीपीयू, जैसे ज़िलॉग ज़ेड80 और डीईसी [[VAX]], में लंबाई-उपसर्ग स्ट्रिंग को संभालने के लिए समर्पित निर्देश थे। हालाँकि, जैसे-जैसे नल-टर्मिनेटेड स्ट्रिंग ने कर्षण प्राप्त किया, सीपीयू डिजाइनरों ने इसे ध्यान में रखना शुरू कर दिया, जैसा कि उदाहरण के लिए आईबीएम के 1992 में ईएस/9000 520 में "लॉजिकल स्ट्रिंग असिस्ट" निर्देशों और 2015 में [[IBM z13 (माइक्रोप्रोसेसर)]] के लिए वेक्टर स्ट्रिंग निर्देशों को जोड़ने के निर्णय में देखा गया था। <ref name="pop">[http://publibfp.dhe.ibm.com/epubs/pdf/a227832c.pdf IBM z/Architecture Principles of Operation]</ref>
इसका सीपीयू अनुदेश समूह डिज़ाइन पर अत्यधिक प्रभाव पड़ा था। 1970 और 1980 के दशक में कुछ सीपीयू, जैसे ज़िलॉग ज़ेड-80 और डीईसी वीएएक्स में लंबाई-उपसर्ग स्ट्रिंग को संभालने के लिए समर्पित निर्देश थे। हालाँकि, जैसे-जैसे रिक्त सीमित स्ट्रिंग ने कर्षण प्राप्त किया, सीपीयू निर्माताओ ने इसे ध्यान में रखना प्रारम्भ कर दिया था जैसा कि उदाहरण के लिए आईबीएम के 1992 में ईएस/9000 520 में "तार्किक स्ट्रिंग सहायता" निर्देशों और 2015 में [[IBM z13 (माइक्रोप्रोसेसर)|आईबीएम जेड-13 (माइक्रोप्रोसेसर)]] के लिए सदिश स्ट्रिंग निर्देशों को जोड़ने के निर्णय में देखा गया था। <ref name="pop">[http://publibfp.dhe.ibm.com/epubs/pdf/a227832c.pdf IBM z/Architecture Principles of Operation]</ref>


[[FreeBSD|फ्रीबीएसडी]] डेवलपर [[Poul-Henning Kamp|पॉल-हेनिंग काम्प]] ने [[ACM Queue|एसीएम क्यू]] में लिखते हुए, 2-बाइट (एक-बाइट नहीं) लंबाई पर नल-टर्मिनेटेड स्ट्रिंग्स की जीत को "अब तक की सबसे महंगी एक-बाइट गलती" के रूप में संदर्भित किया है।<ref>{{citation |last=Kamp |first=Poul-Henning |date=25 July 2011 |title=The Most Expensive One-byte Mistake |journal=ACM Queue |volume=9 |number=7 |pages=40–43 |doi=10.1145/2001562.2010365 |s2cid=30282393 |issn=1542-7730|url=http://queue.acm.org/detail.cfm?id=2010365 |doi-access=free }}</ref>
[[FreeBSD|फ्रीबीएसडी]] विकासक [[Poul-Henning Kamp|पॉल-हेनिंग काम्प]] ने [[ACM Queue|एसीएमक्यू]] में लिखते हुए, 2-बाइट लंबाई पर रिक्त-सीमित स्ट्रिंग्स की जीत को "अब तक की सबसे कीमती एक-बाइट गलती" के रूप में संदर्भित किया है।<ref>{{citation |last=Kamp |first=Poul-Henning |date=25 July 2011 |title=The Most Expensive One-byte Mistake |journal=ACM Queue |volume=9 |number=7 |pages=40–43 |doi=10.1145/2001562.2010365 |s2cid=30282393 |issn=1542-7730|url=http://queue.acm.org/detail.cfm?id=2010365 |doi-access=free }}</ref>
== सीमाएं ==
== सीमाएं ==
प्रयुक्त करने में सरल होने के बावजूद, यह प्रतिनिधित्व त्रुटियों और प्रदर्शन समस्याओं से ग्रस्त रहा है।
प्रयुक्त करने में सरल होने के अतिरिक्त यह प्रतिनिधित्व त्रुटियों और प्रदर्शन समस्याओं से ग्रस्त रहा है।


अशक्त-समाप्ति ने ऐतिहासिक रूप से सुरक्षा समस्याएँ पैदा की हैं।<ref>{{cite journal|url= http://insecure.org/news/P55-07.txt |author=Rain Forest Puppy |title=पर्ल सीजीआई समस्याएं|journal=Phrack Magazine |publisher=artofhacking.com |date=9 September 1999 |volume=9 |issue=55 |page=7 |access-date=3 January 2016}}</ref> स्ट्रिंग के बीच में डाला गया NUL इसे अप्रत्याशित रूप से छोटा कर देगा।[6] एक सामान्य बग एनयूएल के लिए अतिरिक्त स्थान आवंटित नहीं करना था, इसलिए इसे आसन्न मेमोरी पर लिखा गया था। दूसरा यह था कि एनयूएल बिल्कुल न लिखा जाए, जिसे अक्सर परीक्षण के दौरान पता नहीं लगाया जा सका क्योंकि मेमोरी के ब्लॉक में पहले से ही शून्य था। लंबाई खोजने के खर्च के कारण कई प्रोग्राम किसी स्ट्रिंग को एक निश्चित आकार के [[डेटा बफ़र]] में कॉपी करने से पहले परेशान नहीं होते थे, जिससे अगर यह बहुत लंबा होता तो बफर ओवरफ्लो हो जाता।
रिक्त-सीमित स्ट्रिंग ने ऐतिहासिक रूप से सुरक्षा समस्याएँ उत्पन्न की हैं।<ref>{{cite journal|url= http://insecure.org/news/P55-07.txt |author=Rain Forest Puppy |title=पर्ल सीजीआई समस्याएं|journal=Phrack Magazine |publisher=artofhacking.com |date=9 September 1999 |volume=9 |issue=55 |page=7 |access-date=3 January 2016}}</ref> स्ट्रिंग के बीच में प्रयुक्त किया गया <code>NUL</code> इसे अप्रत्याशित रूप से छोटा कर देता है। एक सामान्य बग एनयूएल के लिए अतिरिक्त स्थान आवंटित नहीं करना था। इसलिए इसे आसन्न मेमोरी पर लिखा गया था। दूसरा यह था कि एनयूएल बिल्कुल न लिखा जाए, जिसका प्रायः परीक्षण के समय पता नहीं लगाया जा सका था क्योंकि मेमोरी के ब्लॉक में पहले से ही शून्य था। लंबाई खोजने के कारण कई प्रोग्राम किसी स्ट्रिंग को एक निश्चित आकार के [[डेटा बफ़र]] में अनुकरण करने से पहले चिंतित नहीं होते थे। जिससे यह बहुत लंबा होता है तो बफर अतिरेक हो जाता है। शून्य को संग्रहीत करने में असमर्थता के लिए आवश्यक है कि टेक्स्ट और बाइनरी डेटा को अलग-अलग रखा जाए और विभिन्न फंक्शनों द्वारा नियंत्रित किया जाए क्योकि बाद वाले डेटा को लंबाई प्रदान करने की आवश्यकता होती है। गलत फ़ंक्शन का उपयोग करने पर इसमे कोड अतिरेक और त्रुटियां हो सकती हैं।


शून्य को संग्रहीत करने में असमर्थता के लिए आवश्यक है कि पाठ और बाइनरी डेटा को अलग-अलग रखा जाए और विभिन्न कार्यों द्वारा नियंत्रित किया जाए (बाद वाले को डेटा की लंबाई भी प्रदान करने की आवश्यकता होती है)। गलत फ़ंक्शन का उपयोग करने पर इससे कोड अतिरेक और त्रुटियां हो सकती हैं।
लंबाई खोजने में गति की समस्याओं को सामान्यतः किसी अन्य ऑपरेशन के साथ जोड़कर अपेक्षाकृत कम किया जा सकता है जो कि O(n) है, जैसे कि <code>[[strlcpy]]</code> में इसका परिणाम सदैव एक सहज [[एपीआई]] नहीं होता है।


लंबाई खोजने में गति की समस्याओं को सामान्यतः किसी अन्य ऑपरेशन के साथ जोड़कर कम किया जा सकता है जो कि O(n) है, जैसे कि <code>[[strlcpy]]</code> में। हालाँकि, इसका परिणाम हमेशा एक सहज [[एपीआई]] नहीं होता है।
== अक्षरों को सांकेतिक अक्षरों में परिवर्तित करना ==
रिक्त-सीमित स्ट्रिंग के लिए आवश्यक है कि एन्कोडिंग कहीं भी शून्य बाइट (0x00) का उपयोग न करे क्योकि प्रत्येक संभव [[ASCII|एएससीआईआई]] या [[UTF-8|यूटीएफ-8]] स्ट्रिंग को संग्रहीत करना संभव नहीं है।<ref>{{cite web|title=UTF-8, a transformation format of ISO 10646|url=http://tools.ietf.org/html/rfc3629#section-3|access-date=19 September 2013}}</ref><ref><!-- This is the encoding table provided as a resource by the Unicode consortium: http://www.unicode.org/resources/utf8.html -->{{cite web|title=Unicode/UTF-8-character table|url=http://www.utf8-chartable.de/|access-date=13 September 2013}}</ref><ref>{{cite web|last=Kuhn|first=Markus|title=UTF-8 and Unicode FAQ|url=http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8|access-date=13 September 2013}}</ref> हालाँकि, एएससीआईआई या यूटीएफ-8 के उपसमूह <code>NUL</code> को छोड़कर प्रत्येक वर्ण को रिक्त-सीमित स्ट्रिंग में संग्रहीत करना सामान्य है। कुछ सिस्टम "[[संशोधित UTF-8|संशोधित यूटीएफ-8]]" का उपयोग करते हैं जो एनयूएल को दो गैर-शून्य बाइट्स (0xC0, 0x80) के रूप में एन्कोड करता है और इस प्रकार सभी संभावित स्ट्रिंग्स को संग्रहीत करने की स्वीकृति देता है। यूटीएफ-8 मानक द्वारा इसकी स्वीकृति नहीं है, क्योंकि यह एक लंबी एन्कोडिंग है, और इसे सुरक्षा जोखिम के रूप में देखा जाता है। इसके अतिरिक्त कुछ अन्य बाइट को स्ट्रिंग के अंत के रूप में उपयोग किया जा सकता है, जैसे 0xFE या 0xFF, जिनका उपयोग यूटीएफ-8 में नहीं किया जाता है।


== कैरेक्टर एनकोडिंग ==
यूटीएफ-16 2-बाइट पूर्णांकों का उपयोग करती है चूँकि कोई भी बाइट शून्य हो सकती है और वास्तव में प्रत्येक दूसरी बाइट जब एएससीआईआई टेक्स्ट का प्रतिनिधित्व करती है तब इसको रिक्त-सीमित बाइट स्ट्रिंग में संग्रहीत नहीं किया जा सकता है। हालाँकि कुछ भाषाएँ 16-बिट यूटीएफ-16 वर्णों की एक स्ट्रिंग प्रयुक्त करती हैं, जो 16-बिट एनयूएल (0x0000) द्वारा समाप्त होती हैं।
अशक्त-समाप्त स्ट्रिंग के लिए आवश्यक है कि एन्कोडिंग कहीं भी शून्य बाइट (0x00) का उपयोग न करे; इसलिए हर संभव [[ASCII]] या [[UTF-8|यूटीएफ-8]] स्ट्रिंग को संग्रहीत करना संभव नहीं है।<ref>{{cite web|title=UTF-8, a transformation format of ISO 10646|url=http://tools.ietf.org/html/rfc3629#section-3|access-date=19 September 2013}}</ref><ref><!-- This is the encoding table provided as a resource by the Unicode consortium: http://www.unicode.org/resources/utf8.html -->{{cite web|title=Unicode/UTF-8-character table|url=http://www.utf8-chartable.de/|access-date=13 September 2013}}</ref><ref>{{cite web|last=Kuhn|first=Markus|title=UTF-8 and Unicode FAQ|url=http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8|access-date=13 September 2013}}</ref> हालाँकि, ASCII या यूटीएफ-8 के उपसमुच्चय - NUL को छोड़कर प्रत्येक वर्ण - को शून्य-समाप्त स्ट्रिंग में संग्रहीत करना आम बात है। कुछ सिस्टम "[[संशोधित UTF-8|संशोधित यूटीएफ-8]]" का उपयोग करते हैं जो एनयूएल को दो गैर-शून्य बाइट्स (0xC0, 0x80) के रूप में एन्कोड करता है और इस प्रकार सभी संभावित स्ट्रिंग्स को संग्रहीत करने की अनुमति देता है। यूटीएफ-8 मानक द्वारा इसकी अनुमति नहीं है, क्योंकि यह एक लंबी एन्कोडिंग है, और इसे सुरक्षा जोखिम के रूप में देखा जाता है। इसके अतिरिक्त कुछ अन्य बाइट को स्ट्रिंग के अंत के रूप में उपयोग किया जा सकता है, जैसे 0xFE या 0xFF, जिनका उपयोग यूटीएफ-8 में नहीं किया जाता है।


यूटीएफ-16 2-बाइट पूर्णांकों का उपयोग करता है और चूँकि कोई भी बाइट शून्य हो सकती है (और वास्तव में हर दूसरा बाइट, जब एएससीआईआई पाठ का प्रतिनिधित्व करता है), शून्य-समाप्त बाइट स्ट्रिंग में संग्रहीत नहीं किया जा सकता है। हालाँकि, कुछ भाषाएँ 16-बिट यूटीएफ-16 वर्णों की एक स्ट्रिंग प्रयुक्त करती हैं, जो 16-बिट एनयूएल (0x0000) द्वारा समाप्त होती है।
== संशोधन ==
सी-स्ट्रिंग नियंत्रण को अपेक्षाकृत कम त्रुटि प्रवृत्त बनाने के लिए कई प्रयास किए गए हैं। जैसे कि <code>[[strdup]]</code> और <code>[[strlcpy]]</code> सुरक्षित फंक्शनों को जोड़ना है जबकि <code>[[gets() |gets]]</code> जैसे असुरक्षित फंक्शनों के उपयोग को अस्वीकृत करना है। दूसरा सी-स्ट्रिंग्स के चारों ओर एक वस्तु-उन्मुख आवरण जोड़ना ताकि केवल सुरक्षित कॉल ही की जा सके। हालाँकि असुरक्षित फ़ंक्शंस को कॉल करना वैसे भी संभव होता है।


== सुधार ==
अधिकांश आधुनिक लाइब्रेरी सी-स्ट्रिंग्स को 32-बिट या बड़ी लंबाई मान वाली संरचना के साथ प्रतिस्थापित करती हैं। लंबाई-उपसर्ग स्ट्रिंग्स के लिए पहले से कहीं अधिक माना जाता था और प्रायः रूपांतरण को तीव्र करने के लिए एक और पॉइंटर, संदर्भ गणना और यहां तक ​​कि एक एनयूएल भी जोड़ते हैं। सी-स्ट्रिंग पर वापस जाएँ क्योकि मेमोरी अब बहुत बड़ी है जैसे कि यदि प्रत्येक स्ट्रिंग में 3 या 16 से अधिक बाइट्स जोड़ना एक वास्तविक समस्या है, तो सॉफ़्टवेयर को इतने छोटे स्ट्रिंग्स से बचना होगा कि कोई अन्य भंडारण विधि और भी अधिक मेमोरी बचा सकती है। उदाहरण के लिए इतनी प्रतिलिपि स्ट्रिंग हो सकती हैं कि एक [[ हैश तालिका |हैश तालिका]] अपेक्षाकृत कम मेमोरी का उपयोग करती है। उदाहरणों में [[C++|सी++]] [[मानक टेम्पलेट लाइब्रेरी]] <code>[[String (C++)|std::string]]</code>[[क्यूटी (टूलकिट)|Qt QString]] <code>QString</code>, [[माइक्रोसॉफ्ट फाउंडेशन क्लास लाइब्रेरी]] <code>CString</code> और <code>Core_Foundation</code> से सी-आधारित कार्यान्वयन <code>CFString</code> और साथ ही एप्पल द्वारा <code>Foundation</code> से इसके वैकल्पिक सिबलिंग मे <code>SString</code> सम्मिलित हैं। [[रस्सी (कंप्यूटर विज्ञान)]] जैसे तारों को संग्रहीत करने के लिए अधिक जटिल संरचनाओं का भी उपयोग किया जा सकता है।
सी स्ट्रिंग हैंडलिंग को कम त्रुटि प्रवण बनाने के लिए कई प्रयास किए गए हैं। एक रणनीति <code>[[strdup]]</code> और <code>[[strlcpy]]</code> जैसे सुरक्षित कार्यों को जोड़ना है, जबकि <code>[[gets() | gets]]</code> जैसे असुरक्षित कार्यों के उपयोग को अस्वीकार करना है। दूसरा है सी स्ट्रिंग्स के चारों ओर एक ऑब्जेक्ट-ओरिएंटेड रैपर जोड़ना ताकि केवल सुरक्षित कॉल ही की जा सके। हालाँकि, असुरक्षित फ़ंक्शंस को कॉल करना वैसे भी संभव है।
 
अधिकांश आधुनिक लाइब्रेरी सी स्ट्रिंग्स को 32-बिट या बड़ी लंबाई मान वाली संरचना के साथ प्रतिस्थापित करती हैं (लंबाई-उपसर्ग स्ट्रिंग्स के लिए पहले से कहीं अधिक माना जाता था), और अक्सर रूपांतरण को तेज करने के लिए एक और पॉइंटर, एक संदर्भ गिनती और यहां तक ​​कि एक एनयूएल भी जोड़ते हैं। C स्ट्रिंग पर वापस जाएँ। मेमोरी अब बहुत बड़ी है, जैसे कि यदि प्रत्येक स्ट्रिंग में 3 (या 16, या अधिक) बाइट्स जोड़ना एक वास्तविक समस्या है, तो सॉफ़्टवेयर को इतने सारे छोटे स्ट्रिंग्स से निपटना होगा कि कोई अन्य भंडारण विधि और भी अधिक मेमोरी बचाएगी। (उदाहरण के लिए, इतने सारे डुप्लिकेट हो सकते हैं कि एक [[ हैश तालिका |हैश तालिका]] कम मेमोरी का उपयोग करेगी)। उदाहरणों में [[C++]] [[मानक टेम्पलेट लाइब्रेरी]] <code>[[String (C++)|std::string]]</code>[[क्यूटी (टूलकिट)|Qt QString]] <code>QString</code>, [[माइक्रोसॉफ्ट फाउंडेशन क्लास लाइब्रेरी]] <code>CString</code> और कोर फाउंडेशन से C-आधारित कार्यान्वयन <code>CFString</code> और साथ ही एप्पल द्वारा फाउंडेशन से इसके ऑब्जेक्टिव-सी सहोदर <code>NSString</code> सम्मिलित हैं। [[रस्सी (कंप्यूटर विज्ञान)]] जैसे तारों को संग्रहीत करने के लिए अधिक जटिल संरचनाओं का भी उपयोग किया जा सकता है।


== यह भी देखें ==
== यह भी देखें ==
*[[खाली स्ट्रिंग]]
*[[खाली स्ट्रिंग|रिक्त स्ट्रिंग]]
* [[प्रहरी मूल्य]]
* [[प्रहरी मूल्य|गुप्त मान]]


==संदर्भ==
==संदर्भ==

Revision as of 08:49, 25 June 2023

कंप्यूटर प्रोग्रामिंग में रिक्त-सीमित स्ट्रिंग एक वर्ण स्ट्रिंग है जिसे वर्णों की सरणी डेटा संरचना के रूप में संग्रहीत किया जाता है। एक शून्य वर्ण (शून्य के मान वाला एक वर्ण, जिसे इस आलेख में एनयूएल कहा जाता है) के साथ समाप्त किया जाता है। इसका वैकल्पिक नाम सी-स्ट्रिंग हैं, जो C प्रोग्रामिंग भाषा और एएससीआईआईजेड भाषा को संदर्भित करती है। हालाँकि सी (प्रोग्रामिंग भाषा) और एएससीआईआईजेड भाषा के अतिरिक्त यह अन्य एन्कोडिंग का उपयोग कर सकती है।[citation needed]

एक स्ट्रिंग की लंबाई (प्रथम) एनयूएल की खोज करके पाई जाती है। यह अपेक्षाकृत धीमी हो सकती है क्योंकि इसमें स्ट्रिंग की लंबाई के संबंध में O(n) रैखिक समय लगता है। इसका यह भी अर्थ है कि एक स्ट्रिंग में रिक्त नहीं हो सकती है, क्योकि यह स्ट्रिंग में ''नहीं'' अंतिम वर्ण के बाद है।

इतिहास

रिक्त-सीमित स्ट्रिंग को पीडीपी-11 असेंबली भाषाओं के ASCIZ निर्देश और पीडीपी-10 के लिए मैक्रो-10 और मैक्रो असेंबली भाषा के ASCIZ निर्देश द्वारा निर्मित किया गया था। ये सी प्रोग्रामिंग भाषा के विकास से पहले के हैं, लेकिन इनमे स्ट्रिंग के अन्य रूपों का प्रायः उपयोग किया जाता था।

जिस समय C को जिन भाषाओं से इसे प्राप्त किया गया था उनका विकास हुआ क्योकि वे मेमोरी अपेक्षाकृत सीमित थी। इसलिए स्ट्रिंग की लंबाई को संग्रहीत करने के लिए ओवरहेड के केवल एक बाइट का उपयोग करना उपयुक्त था। उस समय का एकमात्र लोकप्रिय विकल्प, जिसे सामान्यतः "पास्कल स्ट्रिंग" कहा जाता है। एक अत्यधिक आधुनिक शब्द "लंबाई-उपसर्ग" है। यह स्ट्रिंग की लंबाई को संग्रहीत करने के लिए एक अग्रणी बाइट का उपयोग करता था। यह स्ट्रिंग को रिक्त रखने की स्वीकृति देता है और पहले से संग्रहीत स्ट्रिंग की लंबाई खोजने के लिए केवल एक मेमोरी नियंत्रण (O(1) स्थिर समय की आवश्यकता होती है, लेकिन स्ट्रिंग की लंबाई 255 वर्णों तक सीमित होती है। 8-बिट का उपयोग करने वाली मशीन पर सी विकासक डेनिस रिची ने एक स्ट्रिंग की लंबाई पर सीमा से बचने के लिए रिक्त-सीमित स्ट्रिंग के फंक्शन का अनुसरण करना चुना और क्योंकि गणना बनाए रखना उनके अनुभव में परिवर्तक का उपयोग करने से कम सुविधाजनक लगता था।[1][2]

इसका सीपीयू अनुदेश समूह डिज़ाइन पर अत्यधिक प्रभाव पड़ा था। 1970 और 1980 के दशक में कुछ सीपीयू, जैसे ज़िलॉग ज़ेड-80 और डीईसी वीएएक्स में लंबाई-उपसर्ग स्ट्रिंग को संभालने के लिए समर्पित निर्देश थे। हालाँकि, जैसे-जैसे रिक्त सीमित स्ट्रिंग ने कर्षण प्राप्त किया, सीपीयू निर्माताओ ने इसे ध्यान में रखना प्रारम्भ कर दिया था जैसा कि उदाहरण के लिए आईबीएम के 1992 में ईएस/9000 520 में "तार्किक स्ट्रिंग सहायता" निर्देशों और 2015 में आईबीएम जेड-13 (माइक्रोप्रोसेसर) के लिए सदिश स्ट्रिंग निर्देशों को जोड़ने के निर्णय में देखा गया था। [3]

फ्रीबीएसडी विकासक पॉल-हेनिंग काम्प ने एसीएमक्यू में लिखते हुए, 2-बाइट लंबाई पर रिक्त-सीमित स्ट्रिंग्स की जीत को "अब तक की सबसे कीमती एक-बाइट गलती" के रूप में संदर्भित किया है।[4]

सीमाएं

प्रयुक्त करने में सरल होने के अतिरिक्त यह प्रतिनिधित्व त्रुटियों और प्रदर्शन समस्याओं से ग्रस्त रहा है।

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

लंबाई खोजने में गति की समस्याओं को सामान्यतः किसी अन्य ऑपरेशन के साथ जोड़कर अपेक्षाकृत कम किया जा सकता है जो कि O(n) है, जैसे कि strlcpy में इसका परिणाम सदैव एक सहज एपीआई नहीं होता है।

अक्षरों को सांकेतिक अक्षरों में परिवर्तित करना

रिक्त-सीमित स्ट्रिंग के लिए आवश्यक है कि एन्कोडिंग कहीं भी शून्य बाइट (0x00) का उपयोग न करे क्योकि प्रत्येक संभव एएससीआईआई या यूटीएफ-8 स्ट्रिंग को संग्रहीत करना संभव नहीं है।[6][7][8] हालाँकि, एएससीआईआई या यूटीएफ-8 के उपसमूह NUL को छोड़कर प्रत्येक वर्ण को रिक्त-सीमित स्ट्रिंग में संग्रहीत करना सामान्य है। कुछ सिस्टम "संशोधित यूटीएफ-8" का उपयोग करते हैं जो एनयूएल को दो गैर-शून्य बाइट्स (0xC0, 0x80) के रूप में एन्कोड करता है और इस प्रकार सभी संभावित स्ट्रिंग्स को संग्रहीत करने की स्वीकृति देता है। यूटीएफ-8 मानक द्वारा इसकी स्वीकृति नहीं है, क्योंकि यह एक लंबी एन्कोडिंग है, और इसे सुरक्षा जोखिम के रूप में देखा जाता है। इसके अतिरिक्त कुछ अन्य बाइट को स्ट्रिंग के अंत के रूप में उपयोग किया जा सकता है, जैसे 0xFE या 0xFF, जिनका उपयोग यूटीएफ-8 में नहीं किया जाता है।

यूटीएफ-16 2-बाइट पूर्णांकों का उपयोग करती है चूँकि कोई भी बाइट शून्य हो सकती है और वास्तव में प्रत्येक दूसरी बाइट जब एएससीआईआई टेक्स्ट का प्रतिनिधित्व करती है तब इसको रिक्त-सीमित बाइट स्ट्रिंग में संग्रहीत नहीं किया जा सकता है। हालाँकि कुछ भाषाएँ 16-बिट यूटीएफ-16 वर्णों की एक स्ट्रिंग प्रयुक्त करती हैं, जो 16-बिट एनयूएल (0x0000) द्वारा समाप्त होती हैं।

संशोधन

सी-स्ट्रिंग नियंत्रण को अपेक्षाकृत कम त्रुटि प्रवृत्त बनाने के लिए कई प्रयास किए गए हैं। जैसे कि strdup और strlcpy सुरक्षित फंक्शनों को जोड़ना है जबकि gets जैसे असुरक्षित फंक्शनों के उपयोग को अस्वीकृत करना है। दूसरा सी-स्ट्रिंग्स के चारों ओर एक वस्तु-उन्मुख आवरण जोड़ना ताकि केवल सुरक्षित कॉल ही की जा सके। हालाँकि असुरक्षित फ़ंक्शंस को कॉल करना वैसे भी संभव होता है।

अधिकांश आधुनिक लाइब्रेरी सी-स्ट्रिंग्स को 32-बिट या बड़ी लंबाई मान वाली संरचना के साथ प्रतिस्थापित करती हैं। लंबाई-उपसर्ग स्ट्रिंग्स के लिए पहले से कहीं अधिक माना जाता था और प्रायः रूपांतरण को तीव्र करने के लिए एक और पॉइंटर, संदर्भ गणना और यहां तक ​​कि एक एनयूएल भी जोड़ते हैं। सी-स्ट्रिंग पर वापस जाएँ क्योकि मेमोरी अब बहुत बड़ी है जैसे कि यदि प्रत्येक स्ट्रिंग में 3 या 16 से अधिक बाइट्स जोड़ना एक वास्तविक समस्या है, तो सॉफ़्टवेयर को इतने छोटे स्ट्रिंग्स से बचना होगा कि कोई अन्य भंडारण विधि और भी अधिक मेमोरी बचा सकती है। उदाहरण के लिए इतनी प्रतिलिपि स्ट्रिंग हो सकती हैं कि एक हैश तालिका अपेक्षाकृत कम मेमोरी का उपयोग करती है। उदाहरणों में सी++ मानक टेम्पलेट लाइब्रेरी std::stringQt QString QString, माइक्रोसॉफ्ट फाउंडेशन क्लास लाइब्रेरी CString और Core_Foundation से सी-आधारित कार्यान्वयन CFString और साथ ही एप्पल द्वारा Foundation से इसके वैकल्पिक सिबलिंग मे SString सम्मिलित हैं। रस्सी (कंप्यूटर विज्ञान) जैसे तारों को संग्रहीत करने के लिए अधिक जटिल संरचनाओं का भी उपयोग किया जा सकता है।

यह भी देखें

संदर्भ

  1. Ritchie, Dennis M. (April 1993). सी भाषा का विकास. Second History of Programming Languages conference. Cambridge, MA.
  2. Ritchie, Dennis M. (1996). "The development of the C language". In Bergin, Jr., Thomas J.; Gibson, Jr., Richard G. (eds.). History of Programming Languages (2 ed.). New York: ACM Press. ISBN 0-201-89502-1 – via Addison-Wesley (Reading, Mass).
  3. IBM z/Architecture Principles of Operation
  4. Kamp, Poul-Henning (25 July 2011), "The Most Expensive One-byte Mistake", ACM Queue, 9 (7): 40–43, doi:10.1145/2001562.2010365, ISSN 1542-7730, S2CID 30282393
  5. Rain Forest Puppy (9 September 1999). "पर्ल सीजीआई समस्याएं". Phrack Magazine. artofhacking.com. 9 (55): 7. Retrieved 3 January 2016.
  6. "UTF-8, a transformation format of ISO 10646". Retrieved 19 September 2013.
  7. "Unicode/UTF-8-character table". Retrieved 13 September 2013.
  8. Kuhn, Markus. "UTF-8 and Unicode FAQ". Retrieved 13 September 2013.