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

From Vigyanwiki
(Created page with "{{Short description|Data structure}} {{Redirect|CString|the garment|Thong}} {{see also|String (computer science)#Null-terminated}} {{Use dmy dates|date=August 2021}} कं...")
 
No edit summary
Line 1: Line 1:
{{Short description|Data structure}}
{{Short description|Data structure}}
{{Redirect|CString|the garment|Thong}}
{{Redirect|CString|the garment|Thong}}
{{see also|String (computer science)#Null-terminated}}
{{see also|स्ट्रिंग (कंप्यूटर विज्ञान)#अशक्त-समाप्त
{{Use dmy dates|date=August 2021}}
}}
[[कंप्यूटर प्रोग्रामिंग]] में, एक अशक्त-समाप्त स्ट्रिंग एक [[वर्ण स्ट्रिंग]] है जिसे एक [[सरणी डेटा संरचना]] के रूप में संग्रहीत किया जाता है जिसमें वर्ण होते हैं और एक अशक्त वर्ण (शून्य के मान वाला एक वर्ण, जिसे इस लेख में NUL कहा जाता है) के साथ समाप्त होता है। वैकल्पिक नाम [[सी स्ट्रिंग]] हैं, जो [[सी (प्रोग्रामिंग भाषा)]] और एएससीआईआईजेड को संदर्भित करता है{{citation needed|date=November 2021}} (हालाँकि C ASCII के अलावा अन्य एन्कोडिंग का उपयोग कर सकता है)।


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


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


उस समय सी (और जिन भाषाओं से इसे प्राप्त किया गया था) विकसित किया गया था, मेमोरी बेहद सीमित थी, इसलिए एक स्ट्रिंग की लंबाई को स्टोर करने के लिए ओवरहेड के केवल एक बाइट का उपयोग करना आकर्षक था। उस समय का एकमात्र लोकप्रिय विकल्प, जिसे आमतौर पर पास्कल स्ट्रिंग कहा जाता है (एक अधिक आधुनिक शब्द है स्ट्रिंग (कंप्यूटर विज्ञान) #Length-prefixed|length-prefixed), स्ट्रिंग की लंबाई को स्टोर करने के लिए एक अग्रणी बाइट का उपयोग करता है। यह स्ट्रिंग को एनयूएल रखने की अनुमति देता है और पहले से संग्रहीत स्ट्रिंग की लंबाई को खोजने के लिए केवल एक मेमोरी एक्सेस ((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 (और जिन भाषाओं से इसे प्राप्त किया गया था) का विकास हुआ था, मेमोरी बेहद सीमित थी, इसलिए स्ट्रिंग की लंबाई को संग्रहीत करने के लिए ओवरहेड के केवल एक बाइट का उपयोग करना आकर्षक था। उस समय का एकमात्र लोकप्रिय विकल्प, जिसे सामान्यतः "पास्कल स्ट्रिंग" कहा जाता है (एक अधिक आधुनिक शब्द "लंबाई-उपसर्ग" है), स्ट्रिंग की लंबाई को संग्रहीत करने के लिए एक अग्रणी बाइट का उपयोग करता था। यह स्ट्रिंग को 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>
सीपीयू [[ निर्देश समुच्चय ]] डिज़ाइन पर इसका कुछ प्रभाव पड़ा। 1970 और 1980 के दशक में कुछ CPU, जैसे कि [[Zilog Z80]] और [[ डिजिटल उपकरण निगम ]] [[VAX]], ने लंबाई-प्रीफिक्स्ड स्ट्रिंग्स को संभालने के लिए समर्पित निर्देश दिए थे। हालांकि, जैसे-जैसे अशक्त-टर्मिनेटेड स्ट्रिंग ने कर्षण प्राप्त किया, सीपीयू डिजाइनरों ने इसे ध्यान में रखना शुरू कर दिया, जैसा कि उदाहरण के लिए IBM के 1992 में IBM ES/9000 परिवार | ES/9000 520 में लॉजिकल स्ट्रिंग असिस्ट निर्देश जोड़ने के निर्णय में देखा गया था। 2015 में [[IBM z13 (माइक्रोप्रोसेसर)]] को वेक्टर स्ट्रिंग निर्देश।<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>


इसका सीपीयू अनुदेश सेट डिज़ाइन पर कुछ प्रभाव पड़ा। 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>


[[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> एक स्ट्रिंग के बीच में डाला गया एक एनयूएल इसे अप्रत्याशित रूप से छोटा कर देगा।<ref>{{Cite web|url=https://security.stackexchange.com/questions/48187/null-byte-injection-on-php|title = Null byte injection on PHP?}}</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] एक सामान्य बग एनयूएल के लिए अतिरिक्त स्थान आवंटित नहीं करना था, इसलिए इसे आसन्न मेमोरी पर लिखा गया था। दूसरा यह था कि एनयूएल बिल्कुल न लिखा जाए, जिसे अक्सर परीक्षण के दौरान पता नहीं लगाया जा सका क्योंकि मेमोरी के ब्लॉक में पहले से ही शून्य था। लंबाई खोजने के खर्च के कारण कई प्रोग्राम किसी स्ट्रिंग को एक निश्चित आकार के [[डेटा बफ़र]] में कॉपी करने से पहले परेशान नहीं होते थे, जिससे अगर यह बहुत लंबा होता तो बफर ओवरफ्लो हो जाता।


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


लंबाई खोजने के साथ गति की समस्याओं को आम तौर पर ओ (एन) जैसे किसी अन्य ऑपरेशन के साथ जोड़कर कम किया जा सकता है, जैसे कि <code>[[strlcpy]]</code>. हालांकि, यह हमेशा एक सहज ज्ञान युक्त [[एपीआई]] में परिणत नहीं होता है।
लंबाई खोजने में गति की समस्याओं को सामान्यतः किसी अन्य ऑपरेशन के साथ जोड़कर कम किया जा सकता है जो कि O(n) है, जैसे कि <code>[[strlcpy]]</code> में। हालाँकि, इसका परिणाम हमेशा एक सहज [[एपीआई]] नहीं होता है।


== कैरेक्टर एनकोडिंग ==
== कैरेक्टर एनकोडिंग ==
अशक्त-समाप्त स्ट्रिंग्स के लिए आवश्यक है कि एन्कोडिंग कहीं भी शून्य बाइट (0x00) का उपयोग न करे; इसलिए हर संभव [[ASCII]] या [[UTF-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 या UTF-8 के सबसेट को स्टोर करना आम है - NUL को छोड़कर हर कैरेक्टर - नल-टर्मिनेटेड स्ट्रिंग्स में। कुछ प्रणालियाँ [[संशोधित UTF-8]] का उपयोग करती हैं जो NUL को दो गैर-शून्य बाइट्स (0xC0, 0x80) के रूप में एन्कोड करता है और इस प्रकार सभी संभावित स्ट्रिंग्स को संग्रहीत करने की अनुमति देता है। UTF-8 मानक द्वारा इसकी अनुमति नहीं है, क्योंकि यह UTF-8#Overlong एन्कोडिंग है, और इसे सुरक्षा जोखिम के रूप में देखा जाता है। इसके बजाय स्ट्रिंग के अंत के रूप में कुछ अन्य बाइट का उपयोग किया जा सकता है, जैसे 0xFE या 0xFF, जिनका उपयोग UTF-8 में नहीं किया जाता है।
अशक्त-समाप्त स्ट्रिंग के लिए आवश्यक है कि एन्कोडिंग कहीं भी शून्य बाइट (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 में नहीं किया जाता है।


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


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


अधिकांश आधुनिक पुस्तकालय सी स्ट्रिंग्स को एक 32-बिट या बड़े लंबाई मान (लंबाई-प्रीफ़िक्स्ड स्ट्रिंग्स के लिए पहले से कहीं अधिक माना जाता है) वाली संरचना के साथ प्रतिस्थापित करते हैं, और रूपांतरण को गति देने के लिए अक्सर एक अन्य सूचक, एक संदर्भ गणना और यहां तक ​​​​कि एक एनयूएल जोड़ते हैं। सी स्ट्रिंग पर वापस। मेमोरी अब बहुत बड़ी है, जैसे कि यदि प्रत्येक स्ट्रिंग में 3 (या 16, या अधिक) बाइट्स का जोड़ एक वास्तविक समस्या है, तो सॉफ़्टवेयर को इतने छोटे स्ट्रिंग्स से निपटना होगा कि कुछ अन्य स्टोरेज विधि और भी मेमोरी बचा लेगी (उदाहरण के लिए इतने सारे डुप्लीकेट हो सकते हैं कि [[ हैश तालिका ]] कम मेमोरी का उपयोग करेगी)। उदाहरणों में [[C++]] [[मानक टेम्पलेट लाइब्रेरी]] शामिल है <code>[[String (C++)|std::string]]</code>[[क्यूटी (टूलकिट)]] <code>QString</code>, [[माइक्रोसॉफ्ट फाउंडेशन क्लास लाइब्रेरी]] <code>CString</code>, और सी-आधारित कार्यान्वयन <code>CFString</code> [[कोर फाउंडेशन]] के साथ-साथ इसके [[ उद्देश्य सी ]] सिबलिंग से <code>NSString</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 10:08, 24 June 2023

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

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

इतिहास

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

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

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

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

सीमाएं

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

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

शून्य को संग्रहीत करने में असमर्थता के लिए आवश्यक है कि पाठ और बाइनरी डेटा को अलग-अलग रखा जाए और विभिन्न कार्यों द्वारा नियंत्रित किया जाए (बाद वाले को डेटा की लंबाई भी प्रदान करने की आवश्यकता होती है)। गलत फ़ंक्शन का उपयोग करने पर इससे कोड अतिरेक और त्रुटियां हो सकती हैं।

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

कैरेक्टर एनकोडिंग

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

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

सुधार

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

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

यह भी देखें

संदर्भ

  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.