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

Latest revision as of 13:54, 30 June 2023

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

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

इतिहास

अशक्त-समाप्त स्ट्रिंग को पीडीपी-11 असेंबली भाषाओं के एएससीआईजेड निर्देश और पीडीपी -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 सम्मिलित हैं। रस्सी (कंप्यूटर विज्ञान) जैसे तारों को संग्रहीत करने के लिए अधिक जटिल संरचनाओं का भी उपयोग किया जा सकता है।

यह भी देखें

संदर्भ

↑ Ritchie, Dennis M. (April 1993). सी भाषा का विकास. Second History of Programming Languages conference. Cambridge, MA.
↑ 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).
↑ IBM z/Architecture Principles of Operation
↑ 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
↑ Rain Forest Puppy (9 September 1999). "पर्ल सीजीआई समस्याएं". Phrack Magazine. artofhacking.com. 9 (55): 7. Retrieved 3 January 2016.
↑ "UTF-8, a transformation format of ISO 10646". Retrieved 19 September 2013.
↑ "Unicode/UTF-8-character table". Retrieved 13 September 2013.
↑ Kuhn, Markus. "UTF-8 and Unicode FAQ". Retrieved 13 September 2013.

[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).

[pop-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.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

@@ Line 1: / Line 1: @@
 {{Short description|Data structure}}
 {{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 प्रोग्रामिंग भाषा और एएससीआईआईजेड भाषा को संदर्भित करती है। हालाँकि [[सी (प्रोग्रामिंग भाषा)]] और एएससीआईआईजेड भाषा के अतिरिक्त यह अन्य एन्कोडिंग का उपयोग कर सकती है।{{citation needed|date=November 2021}}
+एक स्ट्रिंग की लंबाई (प्रथम) एनयूएल की खोज करके पाई जाती है। यह अपेक्षाकृत धीमी हो सकती है क्योंकि इसमें स्ट्रिंग की लंबाई के संबंध में O(n) रैखिक समय लगता है। इसका यह भी अर्थ है कि एक स्ट्रिंग मे यह रिक्त नहीं हो सकती है क्योकि यह स्ट्रिंग में <nowiki>''नहीं''</nowiki> अंतिम वर्ण के बाद है।
 == इतिहास ==
-अशक्त-समाप्त स्ट्रिंग्स द्वारा निर्मित किए गए थे <code>.ASCIZ</code> [[पीडीपी-11]] विधानसभा भाषाओं के निर्देश और <code>ASCIZ</code> [[PDP-10]] के लिए [[MACRO-10]] मैक्रो असेंबली लैंग्वेज का निर्देश। ये सी प्रोग्रामिंग भाषा के विकास से पहले के हैं, लेकिन तार के अन्य रूपों का अक्सर उपयोग किया जाता था।
+अशक्त-समाप्त स्ट्रिंग को [[पीडीपी-11]] असेंबली भाषाओं के एएससीआईजेड निर्देश और [[PDP-10|पीडीपी]][[PDP-10|-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 को जिन भाषाओं से इसे प्राप्त किया गया था उनका विकास हुआ क्योकि वे मेमोरी अपेक्षाकृत सीमित थी। इसलिए स्ट्रिंग की लंबाई को संग्रहीत करने के लिए ओवरहेड के केवल एक बाइट का उपयोग करना उपयुक्त था। उस समय का एकमात्र लोकप्रिय विकल्प, जिसे सामान्यतः "पास्कल स्ट्रिंग" कहा जाता है। एक अत्यधिक आधुनिक शब्द "लंबाई-उपसर्ग" है। यह स्ट्रिंग की लंबाई को संग्रहीत करने के लिए एक अग्रणी बाइट का उपयोग करता था। यह स्ट्रिंग को रिक्त रखने की स्वीकृति देता है और पहले से संग्रहीत स्ट्रिंग की लंबाई खोजने के लिए केवल एक मेमोरी नियंत्रण (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 और डीईसी वीएएक्स में लंबाई-उपसर्ग स्ट्रिंग को संभालने के लिए समर्पित निर्देश थे। हालाँकि, जैसे-जैसे रिक्त सीमित स्ट्रिंग ने कर्षण प्राप्त किया, सीपीयू निर्माताओ ने इसे ध्यान में रखना प्रारम्भ कर दिया था जैसा कि उदाहरण के लिए आईबीएम के 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>
 == सीमाएं ==
-लागू करने में सरल होने के बावजूद, यह प्रतिनिधित्व त्रुटियों और प्रदर्शन समस्याओं से ग्रस्त रहा है।
+प्रयुक्त करने में सरल होने के अतिरिक्त यह प्रतिनिधित्व त्रुटियों और प्रदर्शन समस्याओं से ग्रस्त रहा है।
-अशक्त-समाप्ति ने ऐतिहासिक रूप से [[कंप्यूटर असुरक्षा]] पैदा की है।<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> स्ट्रिंग के बीच में प्रयुक्त किया गया <code>NUL</code> इसे अप्रत्याशित रूप से छोटा कर देता है। एक सामान्य बग एनयूएल के लिए अतिरिक्त स्थान आवंटित नहीं करना था। इसलिए इसे आसन्न मेमोरी पर लिखा गया था। दूसरा यह था कि एनयूएल बिल्कुल न लिखा जाए, जिसका प्रायः परीक्षण के समय पता नहीं लगाया जा सका था क्योंकि मेमोरी के ब्लॉक में पहले से ही शून्य था। लंबाई खोजने के कारण कई प्रोग्राम किसी स्ट्रिंग को एक निश्चित आकार के [[डेटा बफ़र]] में अनुकरण करने से पहले चिंतित नहीं होते थे। जिससे यह बहुत लंबा होता है तो बफर अतिरेक हो जाता है। शून्य को संग्रहीत करने में असमर्थता के लिए आवश्यक है कि टेक्स्ट और बाइनरी डेटा को अलग-अलग रखा जाए और विभिन्न फंक्शनों द्वारा नियंत्रित किया जाए क्योकि बाद वाले डेटा को लंबाई प्रदान करने की आवश्यकता होती है। गलत फ़ंक्शन का उपयोग करने पर इसमे कोड अतिरेक और त्रुटियां हो सकती हैं।
-लंबाई खोजने के साथ गति की समस्याओं को आम तौर पर ओ (एन) जैसे किसी अन्य ऑपरेशन के साथ जोड़कर कम किया जा सकता है, जैसे कि <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> हालाँकि, एएससीआईआई या यूटीएफ-8 के उपसमूह <code>NUL</code> को छोड़कर प्रत्येक वर्ण को अशक्त-समाप्त स्ट्रिंग में संग्रहीत करना सामान्य है। कुछ सिस्टम "[[संशोधित 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-बिट या बड़ी लंबाई मान वाली संरचना के साथ प्रतिस्थापित करती हैं। लंबाई-उपसर्ग स्ट्रिंग्स के लिए पहले से कहीं अधिक माना जाता था और प्रायः रूपांतरण को तीव्र करने के लिए एक और पॉइंटर, संदर्भ गणना और यहां तक कि एक एनयूएल भी जोड़ते हैं। सी-स्ट्रिंग पर वापस जाएँ क्योकि मेमोरी अब बहुत बड़ी है जैसे कि यदि प्रत्येक स्ट्रिंग में 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> सम्मिलित हैं। [[रस्सी (कंप्यूटर विज्ञान)]] जैसे तारों को संग्रहीत करने के लिए अधिक जटिल संरचनाओं का भी उपयोग किया जा सकता है।
 == यह भी देखें ==
-*[[खाली स्ट्रिंग]]
+*[[खाली स्ट्रिंग|रिक्त स्ट्रिंग]]
-* [[प्रहरी मूल्य]]
+* [[प्रहरी मूल्य|गुप्त मान]]
 ==संदर्भ==
@@ Line 43: / Line 42: @@
 {{CProLang}}
 {{Data types}}
-[[Category: स्ट्रिंग डेटा संरचनाएं]]
 [[es:C string]]
+[[Category:All articles with unsourced statements]]
+[[Category:Articles with hatnote templates targeting a nonexistent page]]
-[[Category: Machine Translated Page]]
+[[Category:Articles with unsourced statements from November 2021]]
+[[Category:Collapse templates]]
 [[Category:Created On 14/06/2023]]
+[[Category:Lua-based templates]]
+[[Category:Machine Translated Page]]
+[[Category:Missing redirects]]
+[[Category:Navigational boxes| ]]
+[[Category:Navigational boxes without horizontal lists]]
+[[Category:Pages with script errors]]
+[[Category:Sidebars with styles needing conversion]]
+[[Category:Template documentation pages|Documentation/doc]]
+[[Category:Templates Vigyan Ready]]
+[[Category:Templates generating microformats]]
+[[Category:Templates that add a tracking category]]
+[[Category:Templates that are not mobile friendly]]
+[[Category:Templates that generate short descriptions]]
+[[Category:Templates using TemplateData]]
+[[Category:Wikipedia metatemplates]]
+[[Category:स्ट्रिंग डेटा संरचनाएं]]

v t e C programming language
ANSI C C99 C11 C17 C2x Embedded C MISRA C
Features	Functions Header files Operators String Syntax Preprocessor Data types
Standard library	Char File I/O Math Dynamic memory String Time Variadic POSIX
Standard library implementations	Bionic libhybris dietlibc glibc EGLIBC klibc Windows CRT musl Newlib uClibc
Compilers	ACK Borland Turbo C Clang GCC ICC LCC Norcroft C PCC SDCC TCC Visual Studio / Express / C++ Watcom C/C++
IDEs	Anjuta CLion Code::Blocks CodeLite Eclipse Geany GNOME Builder KDevelop Visual Studio NetBeans
Comparison with other languages	Compatibility of C and C++ Comparison with Pascal
Descendant languages	C++ C# D Objective-C Alef Limbo Go Vala
Category

v t e Data types
Uninterpreted	Bit Byte Trit Tryte Word Bit array
Numeric	Arbitrary-precision or bignum Complex Decimal Fixed point Floating point Reduced precision Minifloat Half precision bfloat16 Single precision Double precision Quadruple precision Octuple precision Extended precision Long double Integer signedness Interval Rational
Pointer	Address physical virtual Reference
Text	Character String null-terminated
Composite	Algebraic data type generalized Array Associative array Class Dependent Equality Inductive Intersection List Object metaobject Option type Product Record or Struct Refinement Set Union tagged
Other	Boolean Bottom type Collection Enumerated type Exception Function type Opaque data type Recursive data type Semaphore Stream Top type Type class Unit type Void
Related topics	Abstract data type Boxing Data structure Generic Kind metaclass Parametric polymorphism Primitive data type Interface Subtyping Type constructor Type conversion Type system Type theory Variable

Anonymous

Search

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

Namespaces

More

Page actions

Latest revision as of 13:54, 30 June 2023

Contents

इतिहास

सीमाएं

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

संशोधन

यह भी देखें

संदर्भ

Navigation

Navigation

Wiki tools

Wiki tools

Anonymous

Search

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

Latest revision as of 13:54, 30 June 2023

इतिहास

सीमाएं

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

संशोधन

यह भी देखें

संदर्भ

Navigation

Wiki tools

Page tools

Other projects

Categories