Runtime: सिस्टम का परिचय। रूण

क्या आप उम्मीद करते हैं कि इन-मेमोरी प्रतिनिधित्व 32-बिट ऑब्जेक्ट्स के तार हों, या फ्लाई पर अनुवादित हों? स्मृति दोहरीकरण के बारे में क्या पूर्व अगर? यदि बाद वाला है तो प्रदर्शन पर क्या प्रभाव पड़ता है?

क्या एक यूनिकोड-संबंधित तकनीक का नामकरण किसी विशेष यूनिकोड-समर्थित स्क्रिप्ट (और बीएमपी स्क्रिप्ट के बाद सूक्ष्म विमान समर्थन में सुधार करने के लिए एक तकनीक) के बाद करना एक अच्छा विचार है?

मुझे लगता है कि प्रस्ताव (और शायद इसे और अधिक स्पष्ट करने की आवश्यकता है) यह है कि स्ट्रिंग्स का इन-मेमोरी प्रतिनिधित्व बिल्कुल नहीं बदलता है। Rune प्रकार केवल एक विशिष्ट व्यक्तिगत 21-बिट कोड बिंदु (32-बिट int के रूप में संग्रहीत) का प्रतिनिधित्व करता है। कोड बिंदुओं को संदर्भित करने वाले तरीके संभावित रूप से इसके बजाय Rune लौटा सकते हैं। संभावित रूप से string में कुछ कार्यक्षमता है जो आपको Rune की गणना करने देगी।

मुझे लगता है कि कुछ स्पष्ट बिंदु हैं जिनके बारे में हमें कुछ इस तरह की सहमति प्राप्त करने की आवश्यकता है:

1. क्या मौजूदा तरीकों की तरह Int32 का उपयोग करने के बजाय Rune प्रकार बनाने में महत्वपूर्ण मूल्य है?
2. क्या "रूण" शब्द वास्तव में एक अच्छा विकल्प है?

उत्तर देने के लिए (1), मुझे लगता है कि हमें Rune कैसे उजागर किया जाएगा, कौन से तरीके प्राप्त होंगे और इसे वापस कर देंगे, आदि के पूर्ण विवरण की आवश्यकता है। और यह निर्धारित करने के लिए कि यह Int32 के साथ सौदा करने से बेहतर है या नहीं। इसके बजाय

जहाँ तक (2) की बात है, मैं स्वयं थोड़ा झिझक रहा हूँ। "रूण" अंग्रेजी में एक गूढ़ शब्द की तरह है, और इस संदर्भ में इसके उपयोग के लिए कुछ असामान्य अर्थ हैं। एक बात यह भी है कि अन्य लोग ला रहे हैं: यह एक अन्य यूनिकोड अवधारणा से टकराता है। जब मैं "यूनिकोड रूण" की खोज करता हूं, तो मुझे मुख्य रूप से रूनिक यूनिकोड ब्लॉक के लिए परिणाम मिलते हैं, और केवल कुछ गो भाषा दस्तावेज मिलते हैं।

char आधा शब्द और पूरा शब्द दोनों है; और आपको यह निर्धारित करने के लिए इसके परिवेश का निरीक्षण करना होगा - जैसे कि यह वर्तमान आधे अक्षर या पूर्ण अक्षर का प्रतिनिधित्व करता है।

शायद System.character जहां यह हमेशा एक पूर्ण अक्षर होता है ...: धूप का चश्मा:

char एक भयानक प्रतिनिधित्व का एक सा है और यहां तक ​​​​कि ascii/लैटिन केवल भाषाओं के लिए भी; इमोजी का उदय अभी भी व्याप्त होगा; इसका मतलब है कि char एक चेक है और शायद अगले char प्रकार की जांच करें

@NickCraver ट्विटर पर

जबकि utf8 एक परिवर्तनीय चौड़ाई एन्कोडिंग है; यह दुर्लभ है (यदि बिल्कुल भी?) कि कोई उपयोगकर्ता आधे वर्णों से निपटना चाहता है; utf8 और utf32 दोनों के लिए।

एन्यूमरेशन के लिए 32-बिट प्रकार अच्छा काम करेगा।

प्रदर्शन या स्मृति परिप्रेक्ष्य के लिए इंडेक्सऑफ, लम्बाई इत्यादि अधिक कठिन होगा।

1. एक अपारदर्शी प्रारूप के लिए बाइट सरणी सबसे अच्छा प्रतिनिधित्व है; उदाहरण के लिए प्रारूप को उसके मूल प्रारूप या अंतिम प्रारूप में रखना (फ़ाइल स्थानांतरण, तार लगाना आदि)
2. मेमोरी बैंडविड्थ और मेमोरी आकार के लिए बाइट सरणी सबसे अच्छा प्रतिनिधित्व है
3. बाइट सरणी बाइट्स के संदर्भ में स्थिति और अनुक्रमणिकाऑफ, लंबाई आदि के अनुरूप है

हालाँकि, जब आप वास्तविक पात्रों की परवाह करना शुरू करते हैं, तो अपरकेसिंग, चार्टर्स पर बंटवारा; यह समझना कि चरित्र क्या है, बाइट परिवर्तनीय चौड़ाई बन जाता है। चार इसे वास्तव में बेहतर नहीं बनाता है; यह सबसे छोटे पात्रों के आकार को दोगुना कर देता है; अधिक वर्ण शामिल हैं, लेकिन फिर भी चर चौड़ाई है।

इसके लिए उपयोगकर्ता कोड के नजरिए से 32 बिट मान बहुत उपयोगी हो सकता है। हालांकि इसमें स्थिति, लंबाई और माध्यमिक वस्तुओं (indexOf आदि) के साथ समस्याएं हैं।

मैं केवल एक एएससीआई स्ट्रिंग और एक utf8 स्ट्रिंग "कॉम्पैक्ट स्ट्रिंग कार्यान्वयन" के लिए बहुत उत्सुक हूं https://github.com/dotnet/coreclr/issues/7083; एएससीआई केवल स्ट्रिंग्स के तेजी से प्रसंस्करण के लिए

हालाँकि, हर उस चीज़ के खिलाफ जा रहा हूँ जो मैं वहाँ बहस कर रहा था ... मुझे आश्चर्य है कि utf8 का 32 बिट का प्रतिनिधित्व कैसा होगा? स्थिति को स्थिति के अनुसार मैप किया जाएगा; वर्णों की तलाश तेज होगी क्योंकि यह एएससीआई में है, आइटम मूल आकार में हैं आदि यह अपने आकार को निर्धारित करने के लिए प्रत्येक बाइट या चार को संसाधित करने के खिलाफ कैसे खड़ा होगा?

से और में रूपांतरण अधिक महंगा होगा; तो यह एक प्रसंस्करण प्रारूप का अधिक होगा; भंडारण प्रारूप की तुलना में।

@migueldeicaza जैसा कि मैंने उपक्रम किया है और आप केवल 16-बिट चार से 32-बिट तक एकल वर्ण प्रारूप का विस्तार करने का जिक्र कर रहे हैं, इसलिए सभी प्रतिनिधित्व मूल्य में निहित हैं; आधे मूल्य की संभावना के बजाय - आंतरिक प्रारूप के बजाय आवश्यक रूप से।

हालांकि विचार करने के लिए कुछ (यानी स्थिति का संबंध, और मांग की लागत, आदि)

इसके अलावा: स्विफ्ट पूरे चरित्र प्रारूपों में भी काम करती है

स्विफ्ट स्ट्रिंग्स के यूनिकोड अभ्यावेदन तक पहुँचने के लिए कई अलग-अलग तरीके प्रदान करता है। यूनिकोड विस्तारित ग्रेफेम क्लस्टर्स के रूप में इसके व्यक्तिगत कैरेक्टर मानों तक पहुंचने के लिए, आप फॉर-इन स्टेटमेंट के साथ स्ट्रिंग पर पुनरावृति कर सकते हैं। इस प्रक्रिया का वर्णन वर्णों के साथ कार्य करना में किया गया है।

वैकल्पिक रूप से, तीन अन्य यूनिकोड-संगत अभ्यावेदन में से एक में स्ट्रिंग मान तक पहुँचें:

• UTF-8 कोड इकाइयों का एक संग्रह (स्ट्रिंग की utf8 संपत्ति के साथ पहुँचा)
• UTF-16 कोड इकाइयों का एक संग्रह (स्ट्रिंग की utf16 संपत्ति के साथ पहुँचा)
• 21-बिट यूनिकोड स्केलर मानों का एक संग्रह, स्ट्रिंग के UTF-32 एन्कोडिंग फॉर्म के बराबर (स्ट्रिंग के unicodeScalars प्रॉपर्टी के साथ एक्सेस किया गया)

मैंने इसे मूल अंक में कहा था और इसे फिर से कहूंगा। एक मानक जो कहता है उसे छोड़ देना क्योंकि आपको वाक्यांश पसंद नहीं है, इससे अधिक भ्रमित हो जाएगा, और, यूनिकोड में एक रूण कोड पृष्ठ दिया गया है, जो इसे और अधिक भ्रमित करता है।

नाम गलत है।

@ मेलिनोई

रूण कई संचालन प्रदान करेगा जो आज आप चार पर उम्मीद करते हैं, जैसे ToLower[Invariant], ToUpper[Invariant], ToTitle, IsDigit, IsAlpha, IsGraphic, IsSymbol, IsControl।

इसके अतिरिक्त, यह चीजें प्रदान करेगा जैसे:

• EncodeRune (एक रन को बाइट बफर में एन्कोड करता है)
• RuneUtf8Len (UTF8 में रूण को एन्कोड करने के लिए आवश्यक बाइट्स की संख्या देता है),
• IsValid (सभी Int32 मान मान्य नहीं हैं)

और आवश्यकतानुसार स्ट्रिंग, और Utf8string में इंटरऑप करें।

मैंने गो स्ट्रिंग समर्थन को .NET में पोर्ट/समायोजित किया, और यह एक दृश्य प्रस्तुत करता है कि यह दुनिया कैसी दिखेगी (यह बिना किसी रनटाइम सहायता के है):

https://github.com/migueldeicaza/NStack/tree/master/NStack/unicode

@benaadams ने कहा:

मुझे आश्चर्य है कि utf8 का 32 बिट का प्रतिनिधित्व कैसा होगा? स्थिति को स्थिति के अनुसार मैप किया जाएगा; वर्णों की तलाश तेज होगी क्योंकि यह एएससीआई में है, आइटम मूल आकार में हैं आदि यह अपने आकार को निर्धारित करने के लिए प्रत्येक बाइट या चार को संसाधित करने के खिलाफ कैसे खड़ा होगा?

UTF8 एक इन-मेमोरी प्रतिनिधित्व है, जो अस्तित्व में रहेगा और प्रतिनिधित्व बना रहेगा (और उम्मीद है, यह .NET में भविष्य के तारों के लिए दीर्घकालिक आंतरिक एन्कोडिंग है)।

आप मौजूदा UTF16 स्ट्रिंग्स (System.String) या आगामी UTF8 स्ट्रिंग्स (Utf8String) को वर्णों में नहीं (इस कारण से कि आप और मैं दोनों सहमत हैं), लेकिन रून्स में डीकोड करेंगे।

कुछ उदाहरण, Utf8 स्ट्रिंग को रनों में बदलें:

https://github.com/migueldeicaza/NStack/blob/6a071ca5c026ca71c10ead4f7232e2fa0673baf9/NStack/strings/ustring.cs#L756

क्या utf8 स्ट्रिंग में एक रूण होता है:

https://github.com/migueldeicaza/NStack/blob/6a071ca5c026ca71c10ead4f7232e2fa0673baf9/NStack/strings/ustring.cs#L855

मैंने अभी देखा कि मैंने इंडेक्सर को लागू नहीं किया ("मुझे एन-वें रन प्राप्त करें")

एक स्ट्रिंग में Nth-rune तक पहुंच की गति भंडारण का एक कार्य है, न कि रूण का। उदाहरण के लिए, यदि आपका संग्रहण UTF32 है, तो आपके पास प्रत्येक रन तक सीधी पहुंच है। यह अकादमिक है, क्योंकि कोई भी इसका उपयोग नहीं करता है। UTF16 और UTF8 पर Nth तत्व तक पहुंच के लिए सही सीमा निर्धारित करने के लिए स्ट्रिंग (बाइट्स या 16-बिट इनट्स) बनाने वाले तत्वों की उचित स्कैनिंग की आवश्यकता होती है। String[int n] { get; } के साथ भ्रमित होने की नहीं, जो शुद्धता की परवाह किए बिना सिर्फ n-वें वर्ण लौटाता है।

@benaadams स्विफ्ट कैरेक्टर एक रन से ऊपर का स्तर है। स्विफ्ट में वर्ण "विस्तारित ग्रेफेम क्लस्टर" हैं जो एक या एक से अधिक रनों से बने होते हैं, जब वे संयुक्त होते हैं तो मानव पठनीय चरित्र उत्पन्न करते हैं।

तो स्विफ्ट चरित्र में एक निश्चित 32-बिट आकार नहीं है, यह चर लंबाई है (और हमारे पास वह निर्माण भी होना चाहिए, लेकिन यह एक अलग डेटा प्रकार में है)। यहां उस पृष्ठ का उदाहरण दिया गया है, लेकिन यह इमोजी के रंग को सेट करने के लिए भी विस्तारित है:

यहाँ एक उदाहरण है। अक्षर é को एकल यूनिकोड स्केलर é के रूप में दर्शाया जा सकता है (ACUTE के साथ लैटिन छोटा अक्षर E, या U+00E9)। हालांकि, एक ही अक्षर को स्केलर्स की एक जोड़ी के रूप में भी दर्शाया जा सकता है-एक मानक अक्षर ई (लैटिन छोटा पत्र ई, या यू+0065), उसके बाद संयोजन एक्यूट एक्सेंट स्केलर (यू+0301)। संयोजन एक्यूट एक्सेंट स्केलर को ग्राफिक रूप से उस स्केलर पर लागू किया जाता है जो इससे पहले होता है, एक ई को एक é में बदल देता है जब इसे यूनिकोड-जागरूक टेक्स्ट-रेंडरिंग सिस्टम द्वारा प्रस्तुत किया जाता है।

सिर्फ मेरे लिए grapheme शब्द अधिक आत्म-वर्णन होगा।

नाम पर मेरे दो सेंट, जोर के साथ स्ट्रिंग्स पर गो पोस्ट को फिर से उद्धृत करते हुए:

" कोड बिंदु " एक कौर है, इसलिए गो अवधारणा के लिए एक छोटा शब्द पेश करता है: रूण। यह शब्द पुस्तकालयों और स्रोत कोड में दिखाई देता है, और इसका अर्थ बिल्कुल "कोड बिंदु" जैसा ही है , जिसमें एक दिलचस्प जोड़ है।

मैं @blowdart से 100% सहमत हूं, इसे रूण कहना सिर्फ भ्रमित करने वाला और गलत है। यूनिकोड मानक उल्लेख कोड केवल परिचय अध्याय के पहले पृष्ठ में तीन बार इंगित करता है लेकिन रूण शब्द कहीं नहीं दिखाई देता है।

यदि यह एक कोड बिंदु है, तो इसे कोड बिंदु नाम दिया जाना चाहिए, यह उतना ही सरल है।

यदि रूण शब्द मानक में कभी प्रकट नहीं हुआ, तो यह ठीक हो सकता है, समस्या यह है कि यह रनों के संबंध में अध्याय 8 में कई बार प्रकट होता है। यह सिर्फ गलत नहीं है, यह सक्रिय रूप से मामले को दूसरे के साथ भ्रमित कर रहा है।

सिर्फ मेरे लिए grapheme शब्द अधिक आत्म-वर्णन होगा।

यदि यह लगभग 32-बिट कोड-पॉइंट है तो grapheme शब्द भ्रमित करने वाला होगा क्योंकि एक ग्रेफेम फिर से कुछ और है।

मैं अक्सर एक कोड-पॉइंट डेटाटाइप चाहता था (अच्छे समय में नहीं, जैसा कि मैंने जिस पर काम किया है वह बदल गया है, लेकिन कुछ साल पहले मैं इसे बहुत कुछ चाहता था और उस ज़रूरत के कुछ हिस्सों के लिए अतिव्यापी आंशिक समाधान लिखा था और एक अच्छी तरह से परीक्षित पुस्तकालय के साथ किया जा सकता था)। मुझे नहीं लगता कि इसे CodePoint जैसा कुछ क्यों नहीं कहा जाना चाहिए। अधिकांश लोग जो महसूस करते हैं कि उन्हें इस प्रकार की आवश्यकता है, वे वैसे भी कोड-पॉइंट्स के संदर्भ में सोच रहे होंगे, न कि रनों के संदर्भ में; या फिर कोड-पॉइंट्स के संदर्भ में और उनके कार्य के अलग-अलग हिस्सों के रूप में चलता है। /rúna béoþ स्टिल ब्राइसू/रून्स अभी भी उपयोग किए जाते हैं। मुझे साल में केवल एक बार रनों का उपयोग करने की ज़रूरत है, और आम तौर पर चर्मपत्र और स्याही के साथ डिजिटल कुछ भी नहीं, लेकिन निश्चित रूप से ऐसे लोग हैं जो डिजिटल रूप से भी उनसे निपटते हैं। (यहां तक ​​कि 20वीं सदी के आंकड़ों के साथ, मुझे एक ऐसे मामले के बारे में पता है जहां से वे WWII-युग के डेटा को संग्रहित करने में उपयोग में हैं)।

ग्रैफेम अभी भी पेचीदा है, क्योंकि कोई अक्सर ऑक्टेट → वर्ण (पहले से ही .NET द्वारा अच्छी तरह से संभाला जाता है) जाना चाहता है, फिर वर्ण → कोड-पॉइंट, और फिर कोड-पॉइंट्स → ग्रेफेम्स।

इसे अभी के लिए अप-फॉर-ग्रैब्स के रूप में फ़्लैग करना।

अगले चरण : हम जो खोज रहे हैं वह है: एक औपचारिक प्रस्ताव जिसमें ऊपर से फीडबैक शामिल होगा (प्रकार का वास्तविक नामकरण, और इसका उपयोग करने के फायदे केवल एक इंट 32 का उपयोग करने के विपरीत)।

मैंने प्रस्तावित एपीआई और प्रारंभिक कार्यान्वयन दोनों के साथ इस मुद्दे को अद्यतन किया है:

https://github.com/migueldeicaza/NStack/blob/master/NStack/unicode/Rune.cs

जहां तक ​​प्रकार के नामकरण का सवाल है, यह एक ऐसी जगह होने की बात है जहां आप प्रकार पर वैध संचालन की तलाश कर सकते हैं, साथ ही साथ प्रकार-विशिष्ट क्षमताएं (कुछ उदाहरणों के लिए कार्यान्वयन देखें)।

@migueldeicaza इसे समीक्षा के लिए तैयार के रूप में फ़्लैग करने से पहले, इस प्रकार के वास्तविक नामकरण पर चिंताओं के बारे में आपके क्या विचार हैं, क्या आपको लगता है कि शायद कोडपॉइंट यह वर्णन करने के मामले में बेहतर हो सकता है कि यह किस प्रकार का है?

मुझे लगता है कि नाम के रूप में कोडपॉइंट का उपयोग करने का तर्क कमजोर है।

इसका उपयोग करना एक भयानक विचार है, लंबी अवधि में, इसे मौजूदा कोड में "चार" के हर एक उपयोग को बदलने की जरूरत है - अगर हम उचित यूनिकोड समर्थन प्राप्त करने की उम्मीद करते हैं।

काश हम रस्ट की तरह "चार" का इस्तेमाल कर सकते थे, लेकिन दुख की बात है कि हमने इसे पहले ही ले लिया है और हमारे पास एक टूटा हुआ है।

इस नाम को अपनाना एक अच्छी मिसाल है।

मैं सहमत हूं कि code point यहां उपयोग करने के लिए सही शब्द नहीं है। कम से कम, यूनिकोड मानक के आधार पर इसमें 10FFFF (http://unicode.org/glossary/#code_point) से ऊपर के मान शामिल नहीं हैं।

मुझे rune शब्द पसंद नहीं है। मुझे लगता है कि यूनिकोड और अन्य जगहों पर इसका मौजूदा उपयोग है जो केवल समग्र रूप से भ्रम पैदा करेगा। मुझे यह भी लगता है कि मौजूदा उपयोगकर्ता प्रकारों के साथ विरोध करने का एक बहुत अच्छा मौका है (विशेष रूप से एकता जैसी चीजों के लिए, जहां 'रूण' एक विशिष्ट गेम ऑब्जेक्ट का प्रतिनिधित्व कर सकता है)।

हालांकि, मुझे एक प्रकार का विचार पसंद है जो सी ++ 11 char32_t प्रकार को कवर करता है, बस एक अलग नाम के साथ।

Char32 के लिए कुछ कहा जाना है। यह बिंदु पर है, यह अभिन्न प्रकारों के प्रकार के नामों के समान है। यह कोड-बिंदु स्तर के बजाय चरित्र वैचारिक स्तर पर बात करता है। यह किसी स्क्रिप्ट का नाम नहीं है।

चूंकि हम nint के बारे में nchar $ कैसे देख रहे हैं?

मिसाल डेटाबेस में होगी nchar और nvarchar

जहां nchar राष्ट्रीय चार/राष्ट्रीय चरित्र हैं और nvarchar राष्ट्रीय चार अलग-अलग/राष्ट्रीय चरित्र अलग-अलग हैं; वे कौन से फ़ील्ड प्रकार हैं जिनमें आप यूनिकोड को स्टोर कर सकते हैं, कुछ आईएसओ मानक भी - सुनिश्चित नहीं है कि कौन सा, शायद एसक्यूएल?

रूण का यह यूनिकोड उपयोग क्या है? मेरे लिए यही खबर है।

यू+16ए0 से यू+16एफ8

इसका उपयोग यूनिकोड मानक में एक विशिष्ट कोड पृष्ठ को संदर्भित करने के लिए किया जाता है। इसे इस सूत्र में कई बार लाया गया है: http://unicode.org/charts/PDF/U16A0.pdf

आह रूनिक, रूण नहीं।

बैकिंग नाम (System.Rune या System.Char32) उतना महत्वपूर्ण नहीं है जितना कि लेबल जिसे C# में पेश किया जाएगा।

सबसे पहले: हाँ, हाँ, और इससे अधिक कृपया। मुझे यह विचार पसंद है (ईमानदारी से, मेरे पास एक समान विचार है जो लंबे समय से चल रहा है)। असल में हम कुछ समय के लिए विजुअल स्टूडियो में बाद में हमारी गिट संगतता में एक कस्टम स्ट्रिंग क्लास और कैरेक्टर स्ट्रक्चर का उपयोग कर रहे हैं (गिट यूटीएफ -8 में बोलता है और सब कुछ ट्रांसकोडिंग बहुत धीमा है)।

स्थैतिक विधि नामों के विषय पर, क्या हम कृपया मनमाने ढंग से लघु-नामकरण से बच सकते हैं? यह देखते हुए कि Char.IsPunctuation वर्तमान विधि है, क्या हम कृपया इसे Rune.IsPunctuation या इसी तरह के साथ मिरर कर सकते हैं?

यह मानते हुए (हमेशा खतरनाक) कि यह स्वीकार हो जाता है, क्या हमारे पास एक आंतरिक rune या c32 हो सकता है, या char को पूरी तरह से System.Rune कार्यान्वयन के साथ बदल सकते हैं?

मेरा सुझाव है कि unichar या uchar हालांकि uchar यह एक अहस्ताक्षरित चार की तरह दिखेगा। हालांकि, जो भी चुना जाता है, मुझे उम्मीद है कि हमें इसके लिए एक भाषा विशिष्ट उपनाम मिलेगा। मैं व्यक्तिगत रूप से आदिम प्रकारों के लिए भाषा उपनामों का उपयोग करने का बहुत बड़ा प्रशंसक हूं।

इसके अलावा मैं @whoisj से सहमत हूं - निश्चित रूप से संक्षिप्त/संक्षिप्त रूपों पर पूर्ण विधि नाम पसंद करूंगा।

इसके अलावा मैं @whoisj से सहमत हूं - निश्चित रूप से संक्षिप्त/संक्षिप्त रूपों पर पूर्ण विधि नाम पसंद करूंगा।

आईएमओ एक भाषा (और इसके पुस्तकालयों) को या तो पूर्ण, संक्षिप्त नाम चुनने की जरूरत है, या संक्षेप में पूरे हॉग पर जाएं (जैसे सी strcmp, memcpy, आदि के साथ)

या सिर्फ char को पूरी तरह से System.Rune कार्यान्वयन से बदल दें?

यह काफी स्पष्ट कारणों से एक महत्वपूर्ण बदलाव होगा।

यह काफी स्पष्ट कारणों से एक महत्वपूर्ण बदलाव होगा।

मेरी टिप्पणियाँ ज्यादातर जुबान और गाल, और आशान्वित थीं। चरित्र के लिए 16-बिट प्रकार शुरू से ही एक गलती थी।

नामकरण पर अच्छी पकड़, ठीक हो जाएगी।

प्रदान की गई एपीआई में अन्य छोटी विसंगतियां हैं, उन्हें भी ठीक करने पर एक नज़र डालेगा।

@migueldeicaza

आह रूनिक, रूण नहीं।

रूनिक विशेषण है, रूण संज्ञा। सभी रनिक कैरेक्टर रन हैं।

_Runic_ विशेषण है, _rune_ संज्ञा। सभी रनिक कैरेक्टर रन हैं।

मेला जैसा लगता है "Cortana: _'rune'_ परिभाषित करें" के साथ आता है:

रोमन वर्णमाला से संबंधित एक प्राचीन जर्मनिक वर्णमाला का एक अक्षर।

आह हाँ, जब भी मैं "रून" शब्द देखता हूं, तो मैं तुरंत इस अस्पष्ट अध्याय के बारे में सोचता हूं जो किसी ने नहीं पढ़ा है जो "द रूनिक यूनिकोड ब्लॉक" के बारे में बात करता है।

मैं बचपन की यादों को टॉल्किन पढ़ने के बारे में सोचता हूं।

मैं

हाँ, मैं विशेष रूप से कल्पना के बारे में नहीं सोचता, लेकिन मैं उस प्रकार के पात्रों के बारे में सोचता हूं जो कल्पना को संदर्भित करता है।

आप rune कहते हैं और मैं जादू, कल्पना, गुप्त पहेली, प्राचीन भाषा आदि के बारे में सोचता हूं।

मुझे खुशी है कि आप "रन" शब्द नहीं देखते हैं और तुरंत सोचते हैं "आह यह स्पष्ट रूप से यूनिकोड 7.0 रनिक ब्लॉक को संदर्भित करता है जिसका मूल्य 16A0..16F8 की सीमा में उन अद्वितीय मानों तक सीमित होगा"।

मुझे पता है कि टान्नर यहां एक ही आवाज है, और आप में से कुछ अभी भी सोच रहे हैं "लेकिन मिगुएल, मुझे 'रूण' शब्द दिखाई देता है और मैं तुरंत एक डेटा प्रकार के बारे में सोचता हूं जो कभी भी केवल 88 संभावित मान रख सकता है"। अगर यह एक समस्या है जिससे आप जूझ रहे हैं, मेरे भाई/बहन, मेरे पास आपके लिए खबर है: आपके पास तलने के लिए बड़ी मछली है।

मैं इस धागे का अनुसरण कुछ समय से उत्साह और झिझक के मिश्रण के साथ एक महीने से अधिक समय से कर रहा हूं। मैंने पिछले महीने अंतर्राष्ट्रीयकरण और यूनिकोड सम्मेलन में भाग लिया, और किसी भी प्रस्तुतीकरण में .NET से संबंधित नहीं था। .NET Framework के साथ एक धारणा समस्या है; एक जो जरूरी नहीं कि इसके वैश्वीकरण सुविधाओं के इतिहास को देखते हुए अनर्जित हो। कहा जा रहा है, मुझे C# में प्रोग्रामिंग पसंद है और मैं पूरी तरह से नई सुविधाओं को देखना चाहता हूं जो वास्तव में वैश्विक समुदाय में .NET की जगह को मजबूत करती हैं। मुझे लगता है कि यह प्रस्ताव उन मानकों को अपनाने की दिशा में एक अच्छा कदम है जो अंतर्राष्ट्रीयकरण समुदाय सॉफ्टवेयर की अपेक्षा करता है।

मेरी झिझक ज्यादातर प्रकार के नाम के बारे में मनमुटाव पर रही है। हालांकि यह सच है कि गो के डिजाइनरों ने "रून" नाम चुना है, यह बार-बार ऊपर सूचीबद्ध कारणों के लिए समस्याग्रस्त है: ऐसे कोड बिंदु हैं जिन्हें ठीक से रन कहा जाता है। मेरे लिए एक ऐसे प्रस्ताव से सहमत होना कठिन है जो एक सम्मानित मानक के करीब आने की कोशिश करता है, और फिर उस शब्दावली को फिर से परिभाषित करता है जो विनिर्देश का हिस्सा है। इसके अलावा, यह तर्क कि अधिकांश डेवलपर्स इस शब्द से अनभिज्ञ हैं, यह देखते हुए कि डेवलपर्स इस प्रकार का सही ढंग से उपयोग करने में सबसे अधिक रुचि रखते हैं, यूनिकोड विनिर्देश को समझने की अधिक संभावना है और एक अच्छा विचार है कि वास्तव में "रन" क्या है। यदि आप शब्दावली को मिश्रित करते हैं तो उस विषमता की कल्पना करें जो मौजूद हो सकती है:

Rune.IsRune(new Rune('ᛁ')); // evaluates to true
Rune.IsRune(new Rune('I')); // evaluates to false

बेशक, मैंने कोई नया नाम दिए बिना आलोचना करते हुए यहां आसान रास्ता अपनाया है। मुझे लगता है कि CodePoint का पिछला सुझाव सबसे आत्म-वर्णनात्मक विकल्प है (और यह मूल अंक विवरण में दिखाई देता है), लेकिन char32 में मौजूदा आदिम प्रकारों के साथ अधिक समानता होगी (हालांकि मैं करूंगा यह कहने में संकोच करें कि प्रत्येक कोड बिंदु एक वर्ण नहीं है)। यदि लक्ष्य .NET में बेहतर यूनिकोड समर्थन का निर्माण कर रहा है, तो मैं उस पथ का पूरी तरह से समर्थन करता हूं, लेकिन ऐसा करने का सबसे अच्छा तरीका कल्पना का पालन करना है।

तीन सुझाव:

1. रूण वर्ग में महत्वपूर्ण "IsCombining" गुम है। इसके बिना, हम रनों की एक श्रृंखला (कोड बिंदु) से अंगूर की एक श्रृंखला में परिवर्तित नहीं हो सकते।

1. मुझे एक संबंधित ग्रैफेम क्लास भी अच्छा लगेगा। इस संदर्भ में एक ग्रैफेम वास्तव में केवल एक या अधिक रून्स (कोड पॉइंट्स) की एक सूची है, जैसे कि पहला रन संयोजन नहीं कर रहा है और शेष रन संयोजन कर रहे हैं। उपयोग का मामला तब होता है जब किसी डेवलपर को "दृश्यमान पात्रों" के हिस्सों से निपटने की आवश्यकता होती है। उदाहरण के लिए, ए + ग्रेव दो रन हैं जो एक ग्रेफेम बनाते हैं।

2. नेटवर्किंग में हमें अक्सर बाइट्स का एक हंक मिलता है जिसे हमें "स्ट्रिंग" जैसी वस्तु में बदलने की आवश्यकता होती है, जहां बाइट्स पूर्ण नहीं हो सकते हैं (उदाहरण के लिए, हमें कुछ बाइट्स के बारे में बताया जाता है, लेकिन मल्टी-बाइट अनुक्रम में अंतिम बाइट है ' टी अभी तक काफी आ गया है)। मुझे बाइट्स की एक धारा को रनों की एक धारा में परिवर्तित करने का कोई स्पष्ट तरीका नहीं दिखता है, जैसे कि मल्टी-बाइट अनुक्रम के अंतिम बाइट को गायब करना एक सामान्य स्थिति मानी जाती है जिसे तब ठीक किया जाएगा जब हम बाइट्स का अगला सेट प्राप्त करेंगे।

और अंत में, कृपया यूनिकोड नामों का उपयोग करें और इसे कोडपॉइंट कहें। हां यूनिकोड कंसोर्टियम अंतर समझाने में एक भयानक काम करता है। लेकिन समाधान स्पष्ट और प्रयोग करने योग्य दस्तावेज जोड़ना है; कुछ और स्पष्ट करने में मदद करने के बजाय इस मुद्दे को भ्रमित करता है।

मुझे नहीं पता कि संयोजन अनुरोध पर कहां से शुरू करना है, न ही गो, रस्ट या स्विफ्ट सतह ऐसे एपीआई पर रूण, कैरेक्टर या यूनिकोड स्केलर ( System.Rune के लिए उनके नाम)। कृपया एक प्रस्तावित कार्यान्वयन प्रदान करें।

ग्रेफेम क्लस्टर पर, यह एक अच्छा विचार है, इसे स्वतंत्र रूप से System.Rune से ट्रैक किया जाना चाहिए। इसके लायक क्या है, इसके लिए स्विफ्ट Character का उपयोग करती है, लेकिन स्विफ्ट भी स्ट्रिंग्स को संभालने के लिए एक महान मॉडल नहीं है।

बाइट्स की धाराओं को उचित रन में बदलना एक समस्या है जो उच्च स्तरीय एपीआई से संबंधित है। उस ने कहा, आप मेरे ustring कार्यान्वयन को देख सकते हैं जो मेरे $#$ System.Rune $#$ कार्यान्वयन के समान सब्सट्रेट का उपयोग करता है यह देखने के लिए कि इन बफ़र्स को utf8 स्ट्रिंग्स में कैसे मैप किया जाता है:

https://github.com/migueldeicaza/NStack/blob/master/NStack/strings/ustring.cs

दस्तावेज़ीकरण, जिसे मैंने अभी तक अपडेट नहीं किया है क्योंकि मैंने एपीआई में System.Rune पेश किया है, लेकिन इसे कवर करता है:

https://migueldeicaza.github.io/NStack/api/NStack/NStack.ustring.html

नामकरण के लिए, स्पष्ट रूप से रस्ट char के साथ सबसे अच्छा है, लेकिन हमने इसे गड़बड़ कर दिया। दूसरा सर्वश्रेष्ठ rune के साथ गो है। चार वर्णों से बड़ा कुछ भी लोगों के लिए सही काम करने के लिए बस एक उपद्रव होगा।

मुझे माफ कर दो; मुझे लगता है कि CodePoint एक बहुत अच्छा नाम है। यह c p के साथ स्व-व्याख्यात्मक, यादगार और स्वतः पूर्ण है।

IsCombining निश्चित रूप से आवश्यक होगा, लेकिन संयोजन वर्ग को भी जानना है और एक बार हमारे पास IsCombining काफी हद तक चीनी है क्योंकि यह सिर्फ IsCombining => CombiningClass != 0 या IsCombining => CombiningClass != CombiningClass.None है। ग्रैफेम क्लस्टर वास्तव में फिर से इसके बाहर होंगे, लेकिन शुरुआती बिंदु डिफ़ॉल्ट क्लस्टरिंग, रीऑर्डरिंग आदि के लिए संयोजन वर्ग को जानना होगा।

CodePoint कोड बिंदुओं के बारे में एक प्रकार के लिए एक अच्छा नाम है, और चार वर्ण शायद ही एक सीमा है जिसे हमें अन्य भारी उपयोग किए जाने वाले प्रकारों से निपटना पड़ता है; string 50% बड़ा है और हमें इसे नियमित रूप से उपयोग करने से नहीं रोकता है। चार बेतरतीब ढंग से चुने गए अक्षर गो की गलती को दोहराने से बेहतर नाम होंगे।

https://www.random.org/strings/?num=10&len=4&loweralpha=on&unique=on&format=html&rnd=new

चूंकि uint सीएलएस-अनुपालन नहीं है, इसलिए कोई सीएलएस-अनुपालन वाला सीटीआर नहीं है जो सूक्ष्म विमानों को कवर करता है। int भी आवश्यक होगा।

दो-तरफा निहित रूपांतरणों से ओवरलोड के साथ खराब चीजें हो सकती हैं, इसलिए एक दिशा शायद स्पष्ट होनी चाहिए। यह स्पष्ट नहीं है कि कौन सा। एक ओर uint / int कोड-बिंदुओं से अधिक व्यापक है क्योंकि 0 से नीचे या 10FFFF ₁₆ से ऊपर के मान सार्थक नहीं हैं, और उस रूपांतरण निहित होने से अधिक मौजूदा एपीआई के त्वरित उपयोग की अनुमति मिलती है संख्याएं। दूसरी तरफ मैं देख सकता हूं कि किसी संख्या से कोड-पॉइंट पर दूसरी तरफ से अधिक बार डालना चाहते हैं।

चूंकि यूंट सीएलएस-अनुपालन नहीं है, इसलिए कोई सीएलएस-अनुपालन वाला सीटीआर नहीं है जो सूक्ष्म विमानों को कवर करता है। int भी आवश्यक होगा।

यह तब तक है जब तक कि आम भाषा में एक नया आंतरिक प्रकार पेश नहीं किया गया।

जॉनहन्ना - क्या आपका मतलब है कि ये तीन रचनाकार:
सार्वजनिक स्थैतिक निहित ऑपरेटर uint (रूण रूण);
सार्वजनिक स्थैतिक निहित ऑपरेटर रूण (चार सीएच);
सार्वजनिक स्थैतिक निहित ऑपरेटर रूण (यूंट मूल्य);

"यूंट" के बजाय "इंट" होना चाहिए। AFAICT, int आसानी से सूक्ष्म (गैर-बीएमपी) विमानों के पूरे सेट को कवर करता है।

@PeterSmithRedmond मेरा मतलब है कि साथ ही साथ दो कंस्ट्रक्टर, एक char ले रहा है और एक uint ले रहा है, एक को int लेना चाहिए, लेकिन हाँ एक int भी होना चाहिए implicit और क्या explicit एक और सवाल है)। उन भाषाओं के लिए भी uint होने में कोई बुराई नहीं है जो इसका उपयोग कर सकती हैं; आखिर यह काफी स्वाभाविक मैच है।

यदि इसे System.Char को प्रतिस्थापित करना चाहिए तो उस पर "अंकगणित" करना संभव होना चाहिए (यानी ==,!=,>, <अनिश्चित +, -, *, /) और इससे भी महत्वपूर्ण बात यह है कि यह इसके अक्षर के लिए समर्थन होना चाहिए उदाहरण के लिए टाइप करें मुझे लिखने में सक्षम होना चाहिए:

rune r = '𐍈'; // Ostrogothic character chose on purpose as in UTF16 will be a "surrogate pairs"

यदि नहीं rune , तो character का केवल अन्य समानार्थी जो काम कर सकता है वह शायद letter है?

संज्ञा

1. किसी व्यक्ति या संगठन को संबोधित लिखित या मुद्रित संचार और आमतौर पर मेल द्वारा प्रेषित।
2. एक प्रतीक या चरित्र जो पारंपरिक रूप से भाषण ध्वनि का प्रतिनिधित्व करने के लिए लेखन और मुद्रण में उपयोग किया जाता है और यह एक वर्णमाला का हिस्सा है।
3. इस तरह के प्रतीक या चरित्र वाले मुद्रण प्रकार का एक टुकड़ा।

हालांकि यह अक्षर बनाम संख्या के साथ संघर्ष करेगा

रूण की तुलना में यूनिकोड (और सामान्य रूप से नेट) में पत्र का और भी अधिक सटीक अर्थ है।

मुझे लगता है, अगर हम इसे एक यूनिकोड वर्ण प्रकार बनाने जा रहे हैं तो हमें यूनिकोड के नामकरण परंपराओं का पालन करना होगा; जिसका अर्थ है _"कोड बिंदु"_।

कोड प्वाइंट । (1) यूनिकोड कोडस्पेस में कोई भी मूल्य; यानी 0 से 10FFFF16 तक के पूर्णांकों का परिसर। ( धारा 3.4, वर्ण और एन्कोडिंग में परिभाषा D10 देखें।) सभी कोड बिंदु एन्कोडेड वर्णों को असाइन नहीं किए गए हैं। कोड बिंदु प्रकार देखें। (2) किसी भी कोडित वर्ण सेट में किसी वर्ण के लिए एक मान, या स्थिति।

या हो सकता है कि हम बस छोड़ दें और एक बतख को "बतख" कहें और उन्हें यूनिकोड वर्ण (उर्फ uchar ) के रूप में देखें।

इसके बजाय System.CodePoint का उपयोग करने के लिए इसे हल क्यों न करें?
इम्हो यह यूनिकोड से शब्दावली के संदर्भ में अधिक उचित है, और जावा दुनिया के अन्य लोग इसका उपयोग कर रहे हैं। तो अपने आप में शब्द रखने के बजाय, आइए यूनिकोड की शर्तों का पालन करें। यह अधिक समझ में आता है, और .NET में सामान्य वर्णों और स्ट्रिंग कार्यान्वयन के संदर्भ में अधिक सार्वभौमिक है, इस तथ्य को भी जानते हुए कि .NET में स्ट्रिंग चार का एक संग्रह है, और चार का यह संग्रह यूनिकोड-आधारित है।

मुझे पता है, क्योंकि मैं जावा और .NET दोनों दुनियाओं में रहा हूं।
और शायद इस पर एक मसौदा कार्यान्वयन शुरू करें।

वास्तव में इसके दो घटक हैं और दोनों की आवश्यकता होगी ( https://github.com/dotnet/corefxlab/issues/1799 में @GrabYourPitchforks द्वारा CodeUnit)

C# keyword      Ugly Long form      Size
----------------------------------------
ubyte      <=>  System.CodeUnit    8 bit  - Assumed Utf8 in absence of encoding param
uchar      <=>  System.CodePoint  32 bit

CodeUnit / ubyte चर चौड़ाई एन्कोडिंग का प्रतिनिधित्व करने के लिए और Span<ubyte> में उपयोग के लिए महत्वपूर्ण हैं ताकि यह सुनिश्चित किया जा सके कि टेक्स्ट एपिस टेक्स्ट प्रकारों पर उपलब्ध हैं लेकिन कच्चे बाइट्स पर नहीं हैं।

CodePoint / uchar समझदार प्रसंस्करण के लिए महत्वपूर्ण है; उदाहरण के लिए .IndexOf(❤) के रूप में ubyte अपने आप में एक मल्टीबाइट यूनिकोड चार की खोज के लिए उपयोग नहीं किया जा सकता है; और ubyte s से अधिक की गणना करना जोखिम से भरा होगा, इसलिए गणक को uchar इकाइयों में काम करना चाहिए।

दो प्रस्तावों को मिलाकर यह कुछ इस तरह होगा

using System;
using System.Runtime.InteropServices;

// C# Keywords
using ubyte = System.CodeUnit;
using uchar = System.CodePoint;
using uspan = System.Utf8Span;
using ustring = System.Utf8String;

namespace System
{
    public ref struct Utf8Span
    {
        private readonly ReadOnlySpan<ubyte> _buffer;

        public Utf8Span(ReadOnlySpan<ubyte> span) => _buffer = span;
        public Utf8Span(uspan span) => _buffer = span._buffer;
        public Utf8Span(ustring str) => _buffer = ((uspan)str)._buffer;
        public Utf8Span(ReadOnlyMemory<ubyte> memory) => _buffer = memory.Span;

        // Returns the CodeUnit index, not CodePoint index
        public int IndexOf(char value) => IndexOf(value, 0);
        public int IndexOf(char value, int startIndex) => IndexOf(value, 0, _buffer.Length);
        public int IndexOf(char value, int startIndex, int count);
        public int IndexOf(char value, StringComparison comparisonType);

        public int IndexOf(uchar value) => IndexOf(value, 0);
        public int IndexOf(uchar value, int startIndex) => IndexOf(value, 0, _buffer.Length);
        public int IndexOf(uchar value, int startIndex, int count);
        public int IndexOf(uchar value, StringComparison comparisonType);

        public uspan Substring(int codeUnitIndex);
        public uspan Substring(int codeUnitIndex, int codePointCount);

        public bool StartsWith(uchar ch) => _buffer.Length >= 1 && _buffer[0] == ch;
        public bool StartsWith(ustring str) => StartsWith((uspan)str);
        public bool StartsWith(uspan value) => _buffer.StartsWith(value._buffer);
        public bool EndsWith(uchar ch) => _buffer.Length >= 1 && _buffer[0] == ch;
        public bool EndsWith(ustring str) => EndsWith((uspan)str);
        public bool EndsWith(uspan value) => _buffer.EndsWith(value._buffer);

        public Enumerator GetEnumerator() => new Enumerator(this);

        // Iterates in uchar steps, not ubyte steps
        public ref struct Enumerator
        {
            public Enumerator(uspan span);

            public uchar Current;
            public bool MoveNext();
            public void Dispose() { }
            public void Reset() => throw new NotSupportedException();
        }
    }

    public class Utf8String
    {
        private readonly ReadOnlyMemory<ubyte> _buffer;

        public Utf8String(ustring str) => _buffer = str._buffer;
        public Utf8String(ReadOnlyMemory<ubyte> memory) => _buffer = memory;

        public bool StartsWith(uchar ch) => ((uspan)this).StartsWith(ch);
        public bool StartsWith(ustring value) => ((uspan)this).StartsWith(value);
        public bool StartsWith(uspan value) => ((uspan)this).StartsWith(value);
        public bool EndsWith(uchar ch) => ((uspan)this).EndsWith(ch);
        public bool EndsWith(ustring value) => ((uspan)this).EndsWith(value);
        public bool EndsWith(uspan value) => ((uspan)this).EndsWith(value);

        public static implicit operator uspan(ustring value) => new uspan(value._buffer);

        // Returns the CodeUnit index, not CodePoint index
        public int IndexOf(char value) => IndexOf(value, 0);
        public int IndexOf(char value, int startIndex) => IndexOf(value, 0, _buffer.Length);
        public int IndexOf(char value, int startIndex, int count);
        public int IndexOf(char value, StringComparison comparisonType);

        public int IndexOf(uchar value) => IndexOf(value, 0);
        public int IndexOf(uchar value, int startIndex) => IndexOf(value, 0, _buffer.Length);
        public int IndexOf(uchar value, int startIndex, int count);
        public int IndexOf(uchar value, StringComparison comparisonType);

        public ustring Substring(int codeUnitIndex);
        public ustring Substring(int codeUnitIndex, int codePointCount);

        public uspan.Enumerator GetEnumerator() => ((uspan)this).GetEnumerator();
    }

    [StructLayout(LayoutKind.Auto, Size = 1)]
    public struct CodeUnit : IComparable<ubyte>, IEquatable<ubyte>
    {
        private readonly byte _value;

        public CodeUnit(ubyte other) => _value = other._value;
        public CodeUnit(byte b) => _value = b;

        public static bool operator ==(ubyte a, ubyte b) => a._value == b._value;
        public static bool operator !=(ubyte a, ubyte b) => a._value != b._value;
        public static bool operator <(ubyte a, ubyte b) => a._value < b._value;
        public static bool operator <=(ubyte a, ubyte b) => a._value <= b._value;
        public static bool operator >(ubyte a, ubyte b) => a._value > b._value;
        public static bool operator >=(ubyte a, ubyte b) => a._value >= b._value;

        public static implicit operator byte(ubyte value) => value._value;
        public static explicit operator ubyte(byte value) => new ubyte(value);

        // other implicit conversions go here
        // if intrinsic then casts can be properly checked or unchecked

        public int CompareTo(ubyte other) => _value.CompareTo(other._value);

        public override bool Equals(object other) => (other is ubyte cu) && (this == cu);

        public bool Equals(ubyte other) => (this == other);

        public override int GetHashCode() => _value;

        public override string ToString() => _value.ToString();
    }

    [StructLayout(LayoutKind.Auto, Size = 4)]
    public struct CodePoint : IComparable<uchar>, IEquatable<uchar>
    {
        private readonly uint _value;

        public CodePoint(uint CodePoint);
        public CodePoint(char ch);

        public static ValueTuple<uchar, int> DecodeLastCodePoint(ubyte[] buffer, int end);
        public static ValueTuple<uchar, int> DecodeLastCodePoint(ustring str, int end);
        public static ValueTuple<uchar, int> DecodeCodePoint(ubyte[] buffer, int start, int n);
        public static ValueTuple<uchar, int> DecodeCodePoint(ustring str, int start, int n);
        public static int EncodeCodePoint(uchar CodePoint, ubyte[] dest, int offset);
        public static bool FullCodePoint(ubyte[] p);
        public static bool FullCodePoint(ustring str);
        public static int InvalidIndex(ubyte[] buffer);
        public static int InvalidIndex(ustring str);
        public static bool IsControl(uchar CodePoint);
        public static bool IsDigit(uchar CodePoint);
        public static bool IsGraphic(uchar CodePoint);
        public static bool IsLetter(uchar CodePoint);
        public static bool IsLower(uchar CodePoint);
        public static bool IsMark(uchar CodePoint);
        public static bool IsNumber(uchar CodePoint);
        public static bool IsPrint(uchar CodePoint);
        public static bool IsPunctuation(uchar CodePoint);
        public static bool IsSpace(uchar CodePoint);
        public static bool IsSymbol(uchar CodePoint);
        public static bool IsTitle(uchar CodePoint);
        public static bool IsUpper(uchar CodePoint);
        public static int CodePointCount(ubyte[] buffer, int offset, int count);
        public static int CodePointCount(ustring str);
        public static int CodePointLen(uchar CodePoint);
        public static uchar SimpleFold(uchar CodePoint);
        public static uchar To(Case toCase, uchar CodePoint);
        public static uchar ToLower(uchar CodePoint);
        public static uchar ToTitle(uchar CodePoint);
        public static uchar ToUpper(uchar CodePoint);
        public static bool Valid(ubyte[] buffer);
        public static bool Valid(ustring str);
        public static bool ValidCodePoint(uchar CodePoint);

        public static bool operator ==(uchar a, uchar b) => a._value == b._value;
        public static bool operator !=(uchar a, uchar b) => a._value != b._value;
        public static bool operator <(uchar a, uchar b) => a._value < b._value;
        public static bool operator <=(uchar a, uchar b) => a._value <= b._value;
        public static bool operator >(uchar a, uchar b) => a._value > b._value;
        public static bool operator >=(uchar a, uchar b) => a._value >= b._value;

        // etc
    }
}

मैं अपने प्रोटोटाइप कार्यान्वयन में UnicodeScalar का उपयोग यूनिकोड स्केलर मान (U+0000..U+10FFFF श्रेणी में मान, समावेशी; सरोगेट कोड बिंदुओं को छोड़कर) और Utf8Char को संदर्भित करने के लिए कर रहा हूं। UTF-8 कोड इकाई को संदर्भित करने के लिए। ऐसा लगता है कि बहुत से लोग _UnicodeScalar_ के बजाय _Rune_ पसंद करते हैं क्योंकि यह एक कौर से कम है। मुझे बहुत ज्यादा परवाह नहीं है, लेकिन मैं यह बताऊंगा कि "यूनिकोड स्केलर वैल्यू" शब्द यूनिकोड विनिर्देशन द्वारा उपयोग किया जाने वाला एक ही शब्द है। ;)

.NET फ्रेमवर्क में एक "टेक्स्ट एलिमेंट" की अवधारणा भी है, जो एक या अधिक स्केलर है जो संयुक्त होने पर एक अविभाज्य ग्रेफेम बनाते हैं। एमएसडीएन पर इस पर अधिक जानकारी। विशेष रूप से, जब आप एक स्ट्रिंग की गणना करते हैं, तो आप कोड इकाई ( Utf8Char या Char ), स्केलर मान ( UnicodeScalar ), या टेक्स्ट तत्व द्वारा गणना करना चाहते हैं, जो आपके आधार पर विशेष परिदृश्य। आदर्श रूप से हम स्ट्रिंग और Utf8String दोनों में तीनों प्रकारों का समर्थन करेंगे।

हमारे प्रोटोटाइप के लिए एपीआई सतह समाप्त नहीं हुई है और तेजी से परिवर्तन के अधीन है, लेकिन आप https://github.com/dotnet/corefxlab/tree/utf8string/src/System.Text.Utf8/System पर कुछ वर्तमान सोच देख सकते हैं। https://github.com/dotnet/corefxlab/blob/master/src/System.Text.Primitives/System/Text/Encoders/Utf8Utility.cs।

थोड़ा हटकर विषय:
क्या "टेक्स्ट एलिमेंट" UAX dotnet/corefx#29 में "ग्रैफेम क्लस्टर बाउंड्रीज़" द्वारा परिभाषित सेगमेंटेशन होना चाहिए?

using System;
using System.Globalization;

class Program
{
    static void Main()
    {
        var e = StringInfo.GetTextElementEnumerator("👩🏻‍👦🏼👨🏽‍👦🏾‍👦🏿👩🏼‍👨🏽‍👦🏼‍👧🏽👩🏻‍👩🏿‍👧🏼‍👧🏾");
        while (e.MoveNext())
        {
            Console.WriteLine(e.GetTextElement());
        }
    }
}

अपेक्षित परिणाम:
‍
‍‍
‍‍‍‍
‍‍‍‍

वास्तविक परिणाम:
मैं
मैं
‍
मैं
मैं
मैं
मैं
‍
मैं
मैं
‍
मैं
मैं
मैं
मैं
‍
मैं
मैं
‍
मैं
मैं
‍
मैं
मैं
मैं
मैं
‍
मैं
मैं
‍
मैं
मैं
‍
मैं
मैं

UnicodeScalar टाइप करना अभी भी बहुत आसान है। यू एस सी स्पेस (स्वतः पूर्ण) चूंकि यह सही, सबसे स्व-वर्णनात्मक शब्द है, मुझे वास्तव में उम्मीद है कि हमें वह मिल जाएगा।

@ufcpp यह एक अच्छी बात है। उसके लिए एक नया मुद्दा खोलने के लिए स्वतंत्र महसूस करें। यदि हम अनुकूल कारणों से व्यवहार नहीं बदल सकते हैं तो मेरा सुझाव है कि हम उस प्रकार को हटा दें और एक विशिष्ट-अनुरूप ग्रेफेम एन्यूमरेटर बनाएं।

ubyte / uchar भ्रमित कर रहे हैं। वे unsigned char / unsigned byte के साथ स्थापित दिए गए सम्मेलन की तरह पढ़ते हैं $ ushort / uint / ulong । शायद char8 / u8char और char32 / u32char स्पष्ट हैं?

किसी भी स्थिति में, मुझे लगता है कि UTF-8 कोड इकाइयाँ और कोड बिंदु हैं या नहीं, इस पर हम गलत हैं:

1. .NET में निम्न-स्तरीय आदिम डेटा प्रकार - जैसे byte , int
2. मौजूदा आदिम से/में बदलने के लिए एक डेटा प्रारूप - जैसे DateTime , Guid

और फिर, हम उस निर्णय को देखते हुए कोडपॉइंट से संबंधित एपीआई को कैसे उजागर करते हैं?

विकल्प 1 का अर्थ है C++17 जैसे char8, char16, और char32 प्राइमेटिव्स (और साथ में u8string, u16string, और u32string) के माध्यम से टेक्स्ट को हैंडल करना। फिर char32 rune के रूप में एक बुरा नाम है, यह देखते हुए कि हमारे पास पहले से ही char16 char है और char8 के लिए भी तीसरे नाम की आवश्यकता है।

विकल्प 2 का अर्थ है बाइट और इंट/यूइंट यूटीएफ कोड इकाइयों और कोड बिंदुओं को संग्रहीत करने के लिए 'काफी अच्छे' हैं। इसका मतलब है कि सभी तार UTF-16 बने रहेंगे। CodePoint / rune बाइनरी प्रतिनिधित्व के बजाय Code Point शब्दार्थ की समस्याओं को हल करता है - और IO के लिए अभिप्रेत नहीं है ।

आईएमओ यूटीएफ -8/यूटीएफ -32 केवल डेटा प्रारूप हैं (विकल्प 2)। उन्हें डेटा (बाइट/इंट) के रूप में मानें। CodePoint int तुलना में DateTime या Guid (एक अन्य पहचानकर्ता*) की तरह अधिक है - निम्न-स्तरीय आदिम प्रकार नहीं, सीधे IO में समर्थित नहीं है (यानी बाइनरीवाइटर), इंट्रिनिक्स की कोई ज़रूरत नहीं है।

@miyu हम corefxlab में जो प्रोटोटाइप ला रहे हैं वह विकल्प 1 के करीब है। कोड इकाइयों का प्रतिनिधित्व करने के लिए विशिष्ट डेटा प्रकार हैं, और ये डेटा प्रकार टेक्स्ट डेटा के आंतरिक प्रतिनिधित्व के लिए हैं और पूरे तार में टेक्स्ट डेटा संचारित करने के लिए उपयोग नहीं किया जा सकता है। (जैसा कि आप इंगित करते हैं, .NET आज पहले से ही इस तरह काम करता है: System.Char UTF-16 स्ट्रिंग की कोड इकाई है, लेकिन System.Char पूरे तार में नहीं भेजा जा सकता है।)

इसके अतिरिक्त, byte[] / Span<byte> / आदि के बीच कनवर्ट करने के लिए एपीआई हैं (यह सभी डेटा का बाइनरी प्रतिनिधित्व है और I/O के लिए उपयुक्त है) और आदिम प्रकार जैसे Utf8String / String / Guid / आदि। इनमें से कुछ दूसरों की तुलना में अधिक सीधे हैं। उदाहरण के लिए, हम एक सुविधा Utf8String.Bytes संपत्ति का खुलासा कर सकते हैं जो i/o में उपयोग के लिए ReadOnlySpan<byte> लौटाती है, और इस संपत्ति गेटर में ओ (1) जटिलता हो सकती है। हम String प्रकार पर ऐसी संपत्ति का परिचय नहीं देंगे, हालांकि आप String.ToUtf8Bytes() सुविधा पद्धति होने की कल्पना कर सकते हैं। और भले ही एक Utf8String.Bytes संपत्ति मौजूद हो, Utf8String उदाहरण पर सीधे गणना करने का मौलिक प्रकार byte नहीं होगा। यह Utf8CodeUnit (नाम टीबीडी) या UnicodeScalar होगा, जो भी हमें लगता है कि डेवलपर्स के निर्माण के प्रकार के लिए अधिक समझ में आता है।

दीवार के विचार से मूर्खतापूर्ण - wchar (_wide char_) के बारे में क्या? आज, अधिकांश सी और सी ++ कंपाइलर वातावरण (विंडोज के बाहर) पहले से ही 32-बिट कोड इकाई के कार्यात्मक समकक्ष का प्रतिनिधित्व करने के लिए wchar_t का उपयोग करते हैं। विंडोज़ एक उल्लेखनीय अपवाद है, जहां wchar_t को 16-बिट प्रकार के रूप में परिभाषित किया गया है, लेकिन डेवलपर्स जो आज विंडोज़ पर पी/आह्वान करते हैं, उन्हें पहले से ही .NET char के बीच बिट चौड़ाई के अंतर से अवगत होना चाहिए। char ।

प्रकार / कीवर्ड wchar हमारे नामकरण परंपराओं का उल्लंघन करेगा, लेकिन इसे केवल विचार के लिए बाहर फेंक देगा।

दीवार के विचार से मूर्खतापूर्ण - wchar (चौड़े चार) के बारे में क्या?

मेरे लिये कार्य करता है

प्रकार / कीवर्ड wchar हमारे नामकरण परंपराओं का उल्लंघन करेगा, ...

ऐसा नहीं लगता कि हमें एक छोटा C# भाषा का कीवर्ड मिलने वाला है

https://github.com/dotnet/apireviews/pull/64#discussion_r196962756 ऐसा लगता है कि हम इन प्रकारों के लिए भाषा कीवर्ड पेश करेंगे क्योंकि इन्हें प्रासंगिक होना होगा (यानी इस पर निर्भर करता है कि वे एक प्रकार के साथ हल कर सकते हैं या नहीं कीवर्ड का नाम उन्हें अभी भी उस प्रकार से जुड़ना होगा, बजाय कीवर्ड द्वारा दर्शाए गए प्रकार के)।

तो अगर हम कुछ अच्छा चाहते हैं... यानी NotLotsOfCapitalFullWords ...

जबकि मैं आम तौर पर .NET के नामकरण सम्मेलनों को पसंद करता हूं, एक लंबा नाम अनिवार्य रूप से int के लिए थोड़ा आक्रामक है जिसका उपयोग जेनरिक और लूप चर के रूप में भी किया जाएगा।

जैसे कोई नहीं करता

foreach (Int32 i in list)
{
    // ...
}

क्या वे? (निश्चित रूप से...)

foreach (UnicodeScalar us in str)
{
    // ...
}

कहीं ज्यादा खराब है

foreach (wchar c in str)
{
    // ...
}

ठीक लगता है...

rune , wchar , और uchar (अन्य धागे पर सुझाए गए) सभी मुझे अच्छे लगते हैं। string के किसी सहकर्मी के लिए कोई सुझाव? wstring , ustring , या अन्य?

... और सी # भाषा कीवर्ड क्यों नहीं मिलता? निश्चित रूप से, पहली रिलीज के लिए एक नहीं होना समझ में आता है, लेकिन अगर यह भविष्य में स्ट्रिंग हैंडलिंग के लिए जा रहा है तो कोई कीवर्ड न केवल कपटपूर्ण है, बल्कि इसे अपनाने के प्रति अत्यधिक शत्रुतापूर्ण है।

/सीसी @MadsTorgersen @jaredpar

सी # भाषा कीवर्ड क्यों नहीं मिलता?

नए कीवर्ड 100% बार परिवर्तन तोड़ रहे हैं। कोई फर्क नहीं पड़ता कि आप कौन सा शब्द चुनते हैं, वहाँ एक कंपनी है जिसका एक प्रकार का नाम है जो उनके प्रोजेक्ट में हर जगह उपयोग किया जाता है। हमारे पास एकमात्र विकल्प प्रासंगिक कीवर्ड हैं: उदाहरण के लिए var ।

इसके लिए एक प्रासंगिक कीवर्ड का उपयोग करने के बारे में मेरी मिश्रित भावनाएं हैं। मौजूदा प्रकार के कीवर्ड ( int , string , आदि ...) का वास्तविक प्रकार के नाम ( Int32 , String ) पर एक ठोस लाभ है:

• string : यह असेंबली में प्रकार System.String को संदर्भित करता है जिसे कंपाइलर कोरलिब के रूप में पहचानता है। इस नाम के साथ शून्य अस्पष्टता जुड़ी हुई है।
• String : संकलक को इस प्रकार की शून्य समझ है। यह किसी भी अन्य प्रकार की तरह ही एक प्रकार है और आपके द्वारा परिभाषित प्रकारों के समान लुकअप नियमों के माध्यम से जाता है। यह string के बराबर हो सकता है या नहीं भी हो सकता है।

एक बार जब हम यहां प्रासंगिक कीवर्ड पेश करते हैं तो rune या तो हो सकता है:

• कोरलिब असेंबली के अंदर System.Rune टाइप करें
• प्रकार rune जिसे आपने दो साल पहले परिभाषित किया था जब आपने Go के बारे में पढ़ा था।

rune String ही अस्पष्ट है, इसलिए मुझे इसे एक प्रासंगिक कीवर्ड के रूप में रखने का कोई ठोस लाभ नहीं दिखता है।

BTW: यही कारण है कि आपको string का उपयोग करना चाहिए न कि String

बीटीडब्लू: यही कारण है कि आपको string का उपयोग करना चाहिए, न कि String

कौन सा 99% कारण मुझे लगता है कि लोग भाषा कीवर्ड चाहते हैं। अन्य 1% यह सिर्फ "बेहतर दिखता है"

"रून" कीवर्ड के लिए मजबूत नापसंदगी के लिए अंगूठे नीचे।

एक बेहतर शब्द ग्लिफ़ है, क्योंकि यह पहले से ही टाइपोग्राफी में एक मौलिक प्रतीक की सामान्य अवधारणा का प्रतिनिधित्व करता है।

रूण एक विशिष्ट प्रकार का ग्लिफ़ है जिसे विडंबना से यूनिकोड द्वारा परिभाषित किया गया है। गो को पूर्व कला के रूप में संदर्भित करना कुछ हद तक हास्यास्पद है। रनों के लिए पूर्व कला वह है जो 150 ईस्वी में और वास्तविक भौतिक रूण पत्थरों में लिखी गई थी। रेडमंड में कोई ऐसा नहीं सोचता जो रूण है। इस तरह की मौजूदा अवधारणाओं को फिर से परिभाषित करने का प्रयास असामान्य है क्योंकि .NET में आमतौर पर एक अच्छी तरह से डिज़ाइन की गई एपीआई सतह होती है। यह बहुत खराब एपीआई नामकरण का एक दुर्लभ अपवाद है और मैं अपने असंतोष को आवाज देना चाहता हूं।

एक बेहतर शब्द ग्लिफ़ है, क्योंकि यह पहले से ही टाइपोग्राफी में एक मौलिक प्रतीक की सामान्य अवधारणा का प्रतिनिधित्व करता है।

समस्या यह है कि "ग्लिफ़" एक प्रयोग किया जाने वाला शब्द है जब यूनिकोड को दृश्यमान पाठ में प्रस्तुत किया जाता है (से: utf8everywhere.org )

ग्लिफ़

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

गो को पूर्व कला के रूप में संदर्भित करना कुछ हद तक हास्यास्पद है।

Utf-8 https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt बनाते समय इस्तेमाल किए गए रॉब पाइक और केन थॉम्पसन शब्द का उपयोग करना

रॉब पाइक अब गो पर काम करता है, यही वजह है कि यह मूल शब्द का उपयोग करता है।

रूण एक विशिष्ट प्रकार का ग्लिफ़ है जिसे विडंबना से यूनिकोड द्वारा परिभाषित किया गया है।

रूनिक यूनिकोड द्वारा परिभाषित किया गया है, रूण नहीं है

रूनिक यूनिकोड द्वारा परिभाषित किया गया है, रूण नहीं है

मुझे नहीं लगता कि यह एक सटीक कथन है, नवीनतम यूनिकोड युक्ति (http://www.unicode.org/versions/Unicode11.0.0/UnicodeStandard-11.0.pdf) में "रून" के लिए 37 हिट हैं (केवल 36 मान्य हैं) , अंतिम एक बड़े शब्द का हिस्सा है) और इसका उपयोग हमेशा रूनिक वर्णमाला के अलग-अलग अक्षरों को संदर्भित करने के लिए किया जाता है।

मुझे नहीं लगता कि यह एक सटीक बयान है, नवीनतम यूनिकोड स्पेक में "रन" के लिए 37 हिट हैं

प्रेरणाओं का वर्णन करने वाले बॉडी टेक्स्ट में; किसी भी वर्ण नाम या टेक्स्ट ब्लॉक नाम में नहीं (जहां इसका रूनिक और रूनिक वर्ण)

प्रेरणाओं का वर्णन करने वाले बॉडी टेक्स्ट में; किसी भी वर्ण नाम या टेक्स्ट ब्लॉक नाम में नहीं (जहां इसका रूनिक और रूनिक वर्ण)

ठीक है, निष्पक्ष। लेकिन फिर हम इस मुद्दे पर वापस आ गए हैं कि वर्तमान यूनिकोड स्पेक "रून" शब्द को परिभाषित नहीं करता है और जब इसका उपयोग किया जाता है, तो यह "रूनिक वर्णों" का वर्णन करने वाले सूचनात्मक पाठ के लिए होता है।

चीजों का वर्णन करने के लिए औपचारिक रूप से परिभाषित और उपयोग क्या है "कोड प्वाइंट" और "कोड यूनिट" है।

• भले ही, ऐतिहासिक रूप से, मूल निर्माता ने "रून" शब्द का इस्तेमाल किया हो, आधिकारिक कल्पना नहीं है (और मुझे लगता है कि उनके पास इसका उपयोग न करने के अच्छे कारण थे)।

संक्षिप्त होने की आवश्यकता है या इसका उपयोग बदसूरत हो जाता है

int CountCommas(string str)
{
    int i = 0;
    foreach(UnicodeCodePoint c in str.AsUnicodeCodePoints())
    {
        if (c == ',') i++;
    }
}

string Trim(string str)
{
    int end = str.Length - 1;
    int start = 0;

    for (start = 0; start < Length; start++)
    {
        if (!UnicodeCodePoint.IsWhiteSpace(str.GetUnicodeCodePointAt(start)))
        {
            break;
        }
    }

    for (end = Length - 1; end >= start; end--)
    {
        if (!UnicodeCodePoint.IsWhiteSpace(str.GetUnicodeCodePointAt(start)))
        {
            break;
        }
    }

    return str.SubString(start, end);
}

बनाम

int CountCommas(string str)
{
    int i = 0;
    foreach(Rune c in str.AsRunes())
    {
        if (c == ',') i++;
    }
}

string Trim(string str)
{
    int end = str.Length - 1;
    int start = 0;

    for (start = 0; start < Length; start++)
    {
        if (!Rune.IsWhiteSpace(str.GetRuneAt(start)))
        {
            break;
        }
    }

    for (end = Length - 1; end >= start; end--)
    {
        if (!Rune.IsWhiteSpace(str.GetRuneAt(start)))
        {
            break;
        }
    }

    return str.SubString(start, end);
}

लंबाई के लिए, मैं पूरी तरह से CodePoint.IsWhiteSpace और str.GetCodePointAt के लिए जाऊंगा, लेकिन Rune भी मजेदार है और मुझे इससे कोई फर्क नहीं पड़ता।

@ jnm2 जब स्ट्रिंग्स की बात आती है तो हम GetCodePointAt का उपयोग नहीं करेंगे। यह बहुत अस्पष्ट है: हम नहीं जानते कि क्या आप char चाहते थे जो उस सूचकांक में हुआ हो (क्योंकि सभी char s - यहां तक ​​कि अयुग्मित सरोगेट - भी मान्य कोड बिंदु हैं) या अदिश / रूण जो उस सूचकांक में हुआ था।

@GrabYourPitchforks GetRuneAt एक ही समस्या से बच सकते हैं, या आप कह रहे हैं कि न तो कोई मतलब होगा?

@ jnm2 मैं बस इतना कह रहा था कि CodePoint विशेष रूप से इस परिदृश्य में बहुत अस्पष्ट है। अन्यथा विधि का नाम GetXyzAt प्रकार के नाम Xyz से मेल खाना चाहिए जो अंततः अंदर जाता है।

FYI करें मुख्य कार्यान्वयन अब चेक इन किया गया है (देखें https://github.com/dotnet/coreclr/pull/20935)। इसे corefx में प्रचारित करने के लिए कुछ समय दें, फिर ref API https://github.com/dotnet/corefx/pull/33395 के माध्यम से आ जाएगा। बेझिझक इस मुद्दे को खुला छोड़ दें या जैसा आप उचित समझें इसका समाधान करें।

मैं किसी को प्रभावित करने या कुछ भी बदलने में सक्षम होने की उम्मीद नहीं करता लेकिन सिर्फ रिकॉर्ड के लिए:

एक बेहतर शब्द ग्लिफ़ है, क्योंकि यह पहले से ही टाइपोग्राफी में एक मौलिक प्रतीक की सामान्य अवधारणा का प्रतिनिधित्व करता है।

समस्या यह है कि "ग्लिफ़" एक प्रयोग किया जाने वाला शब्द है जब यूनिकोड को दृश्यमान पाठ में प्रस्तुत किया जाता है (से: utf8everywhere.org )

तर्क की वह पंक्ति या तो रूण का समर्थन नहीं करती है, क्योंकि यूनिकोड या ट्रांजिस्टर या माइक्रोसॉफ्ट या ओपन सोर्स के अस्तित्व में आने से पहले, "रून" पूरे इतिहास में एक हजार साल से अधिक समय से इस्तेमाल किया जाने वाला शब्द रहा है। कम से कम यह इंगित करता है कि कुछ मनमाने ढंग से अलग-अलग प्रस्तावों पर अलग-अलग मानकों को लागू करते हैं जो स्पष्ट रूप से सुसंगत नहीं हैं, इसलिए शायद यह सबसे सुसंगत तर्क के बजाय सबसे पहले कौन था या सबसे जोर से है, मुझे क्या पता है। मैं प्रक्रिया को समझने की कोशिश में देर से आने वाला हूं लेकिन इसका कोई मतलब नहीं है।

गो को पूर्व कला के रूप में संदर्भित करना कुछ हद तक हास्यास्पद है।

Utf-8 https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt बनाते समय इस्तेमाल किए गए रॉब पाइक और केन थॉम्पसन शब्द का उपयोग करना

रॉब पाइक अब गो पर काम करता है, यही वजह है कि यह मूल शब्द का उपयोग करता है।

गो और रॉब पाइक इस विषय पर अपेक्षाकृत नवागंतुक हैं। वास्तव में उनकी राय ऐतिहासिक रूप से और लोकप्रिय साहित्य और समाज में परिभाषित करने के संदर्भ में कुछ हद तक अप्रासंगिक है। रॉब ने खुद किसी भी रन स्टोन को हाथ से नहीं मारा था, इसलिए उसके पास यह परिभाषित करने के लिए कुछ योग्यताएं हैं कि एक रन क्या है। मुझे यकीन है कि वह खुद रूण स्क्रिप्ट लिख या पढ़ भी नहीं सकता है, लेकिन यह मेरा अनुमान है। सबसे अच्छा वह उस अवधारणा को एन्कोडिंग के माध्यम से पकड़ सकता है, लेकिन वह अंदर नहीं आ सकता है और कह सकता है कि एक चीनी चरित्र, अरबी लेखन या हंगुल या स्माइली चेहरा एक रूण है या जो कुछ भी "कोड प्वाइंट" है वह अब एक रूण है, या कुछ इस तरह का। यह लगभग अपमानजनक रूप से इस शब्द को रौंदता हुआ प्रतीत होता है, देखो, अब सब कुछ एक रूण हो सकता है, जिसका अर्थ है, रन एन्कोडिंग टेक्स्ट के क्षेत्र में कुछ गूढ़ को संदर्भित करने के लिए चार अक्षर वाले वाइल्डकार्ड शब्द के अलावा और कुछ नहीं हैं।

रूण एक विशिष्ट प्रकार का ग्लिफ़ है जिसे विडंबना से यूनिकोड द्वारा परिभाषित किया गया है।

रूनिक यूनिकोड द्वारा परिभाषित किया गया है, रूण नहीं है

यूनिकोड को फिर से परिभाषित नहीं करना चाहिए कि एक रूण या रूनिक क्या है। यदि वे ऐसा करते हैं, तो वे अपने जनादेश से आगे बढ़ रहे हैं। उनके पास जनता को यह बताने का कोई काम नहीं है कि रूण क्या है। वास्तव में उनके पास किसी भी नई भाषा या चरित्र प्रणाली को परिभाषित करने वाला कोई व्यवसाय नहीं है। वे केवल एक ऐसे शब्द को उपयुक्त नहीं बना सकते जो पहले से ही एक हजार वर्षों से स्पष्ट रूप से अतिभारित शब्द है और फिर जयकारे लगाते हुए ऐसे दौड़ते हैं जैसे उन्होंने एक नई अवधारणा का आविष्कार किया हो। रूनिक लेखन में केवल रन होते हैं, और रन पहले से ही एक स्थापित अवधारणा है। यदि आप सड़क पर किसी बेतरतीब व्यक्ति से पूछते हैं कि रन क्या है तो वे यूनिकोड के बारे में नहीं सोचेंगे।

उपरोक्त सभी समस्याओं के अलावा, रूण एक खराब रूपक है जो सबसे खराब हिस्सा है। यह कुछ भी स्पष्ट नहीं करता है। यह सिर्फ भ्रम का एक और स्तर जोड़ता है। विषय के किसी भी नवागंतुक को अब स्पष्ट व्याख्या और पढ़ने के दौर से गुजरने की जरूरत है क्योंकि हर कोई इस संदर्भ में आता है कि रूण एक ऐतिहासिक लेखन प्रणाली है जिसका उपयोग कुछ संस्कृतियों में किया जाता है। स्पष्टीकरण कुछ इस तरह जाना होगा: "एक रूण एक यूनिकोड कोड बिंदु है"। "लेकिन इसे कोड पॉइंट क्यों नहीं कहते?" "ठीक है, क्योंकि यह बहुत लंबा है।", या "किसी ने फैसला किया कि उन्हें दौड़ना पसंद है"। तो मूल रूप से, क्योंकि कोई सोचता है कि 9 अक्षर 4 की तुलना में बहुत अधिक हैं (भले ही उनके पास Intellisense के साथ स्वत: पूर्ण है और जावा किंगडम ऑफ नोन्स की तुलना में कुछ भी नहीं है), अब हमें इस भ्रम से निपटना होगा और इसे हजारों को समझाना होगा उन डेवलपर्स की संख्या जिन्हें यूनिकोड में डब करने की आवश्यकता हो सकती है। यदि आप इसे कोड में बहुत अधिक उपयोग करते हैं तो शब्द को छोटा करने के लिए बस एक प्रयोग कथन का उपयोग करें।

यह यूनिकोडकोडपॉइंट होना जरूरी नहीं है, यह केवल कोडपॉइंट हो सकता है। यह पहले से ही अद्वितीय है। ऐसे कई एपीआई शब्द हैं जो "कोडपॉइंट" से अधिक लंबे हैं, इसलिए यह पर्याप्त होना चाहिए। यदि अभी भी बहुत लंबा है, तो बस कुछ संक्षेप के साथ एक प्रयोग कथन का उपयोग करें।

मुझे लगता है कि यह उन गोचा साक्षात्कार प्रश्नों में से एक बन गया है जो वास्तव में बहुत अधिक मूल्य नहीं जोड़ते हैं या उपयोगी किसी भी चीज़ में तार्किक आधार नहीं रखते हैं। कम से कम रूपक "मील का पत्थर" के लिए, जबकि हम पत्थर और चट्टान से प्राप्त अवधारणाओं के आधार पर सॉफ्टवेयर विकास में उपयोग किए जाने वाले प्रतीकात्मक शब्दों के विषय पर हैं, एक मील का पत्थर का वास्तविक वर्णनात्मक अर्थ होता है। यह तुरंत एक अवधारणा का संचार करता है जिससे हर कोई परिचित है। अहा, एक मील का पत्थर, जैसे जब आप एक लंबी यात्रा पर हों और आप पगडंडी पर से गुजरते हों। यह एक अच्छा वास्तविक विश्व रूपक है जो वास्तव में कुछ कल्पना करने में मदद करता है और तुरंत प्रबंधकीय भाषा बन सकता है। मैं कल्पना नहीं कर सकता कि लोग इस तरह से रनों के बारे में बात कर रहे हैं जब तक कि वे इस विषय से अच्छी तरह परिचित न हों, जिस बिंदु पर उन्हें पहले से ही पता चल जाएगा कि यह कोड बिंदु के लिए सिर्फ एक नौटंकी शब्द है।

एक बेहतर शब्द ग्लिफ़ है, क्योंकि यह पहले से ही टाइपोग्राफी में एक मौलिक प्रतीक की सामान्य अवधारणा का प्रतिनिधित्व करता है।

समस्या यह है कि "ग्लिफ़" एक प्रयुक्त शब्द है जब यूनिकोड को दृश्यमान पाठ में प्रस्तुत किया जाता है (से: utf8everywhere.org)

तर्क की वह पंक्ति या तो रूण का समर्थन नहीं करती है, क्योंकि यूनिकोड या ट्रांजिस्टर या माइक्रोसॉफ्ट या ओपन सोर्स के अस्तित्व में आने से पहले, "रून" पूरे इतिहास में एक हजार साल से अधिक समय से इस्तेमाल किया जाने वाला शब्द रहा है।

मेरा कहना था कि शब्द "ग्लिफ़" समस्याग्रस्त है क्योंकि यह पहले से ही पाठ को प्रस्तुत करने में अवधारणाओं में से एक के रूप में उपयोग किया जाता है; यह एक विशेष फ़ॉन्ट में उस चरित्र का चित्रमय प्रतिनिधित्व है। तो एक चरित्र को कई अलग-अलग ग्लिफ़ द्वारा दर्शाया जा सकता है।

... फिर से @benadams के साथ चीजों के 10,000 मीटर दृश्य और सही उत्तर 😁

ईमानदारी से, हमें पुरानी कहावत के साथ रहना होगा: "आप कुछ लोगों को हर समय खुश कर सकते हैं, और सभी लोगों को कुछ समय के लिए खुश कर सकते हैं, लेकिन आप सभी लोगों को खुश नहीं कर सकते हैं। समय।" यह बहुत पहले की स्थिति है।

सिगिल?

Exit, pursued by a bear.

किसी ऐसे व्यक्ति के रूप में जो इस एपीआई का व्यापक रूप से उपयोग करेगा, मैं कोड बिंदु के लिए एक मजबूत वोट डाल रहा हूं। यूनिकोड शब्दावली पहले से ही काफी भ्रमित कर रही है, और विसंगतियां पहले से ही लाजिमी हैं। अगर मैं हर जगह सिर्फ "कोड पॉइंट" कहूं तो आप मेरे जीवन को बहुत आसान बना देंगे।

मैं अभी बिस्तर पर लेटा हूँ। अगर मैं बग़ल में मुड़ता हूँ, तो मुझे मेरी दीवार के सामने एक व्हाइटबोर्ड का सामना करना पड़ता है। महीनों के लिए, वह व्हाइटबोर्ड विभिन्न स्क्रिबल्स और चार्ट्स का घर रहा है, जबकि मैं यह पता लगाने की कोशिश करता हूं कि सी # में कुशलतापूर्वक आईडीएन से कैसे निपटें। मैं इसे एक अवशेष की तरह मानता हूं जिसे मैंने नरक की गहराई से बुलाया है। अगर मैं इसके द्वारा वर्णित तर्क को समझाने की कोशिश करता, तो मैं नहीं कर पाता।

कृपया, मेरे जीवन को कठिन मत बनाओ। एक कोड बिंदु एक कोड बिंदु है। यह एक रूण, ग्लिफ़, चरित्र, अंगूर, या प्रतीक भी नहीं है। इसे मानव के लिए सार्थक किसी भी चीज़ का प्रतिनिधित्व करने की आवश्यकता नहीं है - यह एक नियंत्रण कोड हो सकता है। यह एक दृश्य प्रतीक का प्रतिनिधित्व नहीं कर सकता है, जैसा कि "रन" नाम का अर्थ है। यह सिर्फ एक कोड बिंदु है।

एक अधिक ठोस तर्क यह है कि "रन" का अर्थ एक एकल अंगूर का प्रतिनिधित्व है, जो अक्सर ऐसा नहीं होता है। अगर मैं कोड बिंदुओं की संख्या और अंगूर की संख्या की गणना करता हूं, तो मुझे दो बहुत अलग संख्याएं मिल सकती हैं। ग्रैफेम के समान अनुक्रम को कोड बिंदुओं की दो अलग-अलग श्रृंखलाओं द्वारा दर्शाया जा सकता है।

एक बेहतर शब्द ग्लिफ़ है, क्योंकि यह पहले से ही टाइपोग्राफी में एक मौलिक प्रतीक की सामान्य अवधारणा का प्रतिनिधित्व करता है।

यह तो और भी बुरा है। एक एकल कोड बिंदु को कई ग्लिफ़ द्वारा दर्शाया जा सकता है, और एक एकल ग्लिफ़ कई कोड बिंदुओं का प्रतिनिधित्व कर सकता है। सटीक मैपिंग सिस्टम, प्रोग्राम, टाइपफेस द्वारा भिन्न हो सकती है ...

इन सभी शब्दों के बहुत विशिष्ट तकनीकी अर्थ हैं। हालांकि इस प्रस्ताव के संदर्भ में मतभेद महत्वहीन लग सकते हैं, उनके वास्तविक परिणाम कहीं और हैं, खासकर अंग्रेजी के अलावा अन्य भाषाओं में।

जर्मन जैसी सामान्य भाषा में भी, पाठ से निपटना कितना मुश्किल हो सकता है, इसका एक उदाहरण के रूप में:

1. ß को अपरकेस में बदलें और आपको SS मिलेगा।
2. इसे वापस लोअरकेस में बदलें और आपको ss मिलेगा।

समस्या:

• char.ToUpper('ß') क्या लौटाना चाहिए? (इसे एक सिंगल चार वापस करना होगा।)
• का एक बड़ा संस्करण जिसे मेरा फ़ोन इस टेक्स्ट बॉक्स में दर्ज नहीं कर सकता है, को यूनिकोड 5.1 में जोड़ा गया था। अगर मैं इसे पेस्ट करने की कोशिश करता हूं, तो मुझे एसएस मिलता है। अब ऊपरी/निचले रूपांतरण और भी अस्पष्ट हैं।
• एक स्ट्रिंग के आवरण को बदलने से इसकी लंबाई बदल जाती है।
• केस परिवर्तन निष्क्रिय या प्रतिवर्ती नहीं हैं।
• आप केवल प्रत्येक स्ट्रिंग को कम करके केस-असंवेदनशील तुलना नहीं कर सकते।

भले ही यह उस स्थिति का प्रत्यक्ष उदाहरण नहीं है जिसमें शब्दावली समस्याएं पैदा करती है, यह दर्शाता है कि किस तरह के किनारे के मामले हैं जिनके बारे में हम आम तौर पर नहीं सोचते हैं। प्रत्येक शब्द को एक विशिष्ट, सुसंगत अर्थ देने से प्रोग्रामर्स को इन मुद्दों को संप्रेषित करने में मदद मिलती है। अगर मैं एक टीम के साथी को अंगूरों की गिनती के लिए एक समारोह लिखने के लिए कहता हूं, तो वे जानते हैं कि वे वास्तव में क्या गिनने जा रहे हैं और इसे कैसे करना है। अगर मैं उन्हें फिर से कोड अंक गिनने के लिए कहता हूं, तो वे जानते हैं कि वास्तव में क्या करना है। ये परिभाषाएँ उन भाषाओं और तकनीकों से स्वतंत्र हैं जिनका हम उपयोग कर रहे हैं।

अगर मैं किसी JavaScript डेवलपर से रनों की गिनती करने के लिए कहता हूं, तो वे मुझे ऐसे देखेंगे जैसे मेरे तीन सिर हैं।

विकिपीडिया कहता है

यूनिकोड 0hex से 10FFFFhex . की सीमा में 1,114,112 कोड बिंदुओं के कोडस्पेस को परिभाषित करता है

कोड बिंदु आधिकारिक नाम प्रतीत होता है। मैंने यह धागा पढ़ा है और कोड बिंदु गलत क्यों होगा, इसके लिए कोई जबरदस्त तर्क नहीं मिला है।

मैं सहमत हूं कि कोड बिंदु यहां उपयोग करने के लिए सही शब्द नहीं है। कम से कम, यूनिकोड मानक के आधार पर इसमें 10FFFF (http://unicode.org/glossary/#code_point) से ऊपर के मान शामिल नहीं हैं।

शायद वह वाक्य गलत है? यह कहता है "कोड स्थान में कोई भी मूल्य"। तो यह स्पष्ट रूप से सब कुछ है जबकि एक ही समय में पूर्णांक गलत हो रहा है।

इसके अलावा, "रन" का वास्तविक दुनिया अर्थ है जिसका यूनिकोड से कोई लेना-देना नहीं है। जर्मनी में, "रूण" शब्द का नाजी अर्थ है क्योंकि रनों का "जर्मनिक" इतिहास है जिसे नाजियों ने संदर्भित करना पसंद किया था।

मुझे "रन" एक भ्रमित करने वाला नाम लगता है। क्या यहां किसी को वास्तव में "रन" पसंद है या इसके लिए तर्क शुद्धता पर आधारित हैं। सहज रूप से, यह वास्तव में एक बुरा नाम है।

शायद वह वाक्य गलत है? यह कहता है "कोड स्थान में कोई भी मूल्य"। तो यह स्पष्ट रूप से सब कुछ है जबकि एक ही समय में पूर्णांक गलत हो रहा है।

वह वाक्य सही है। कोड स्थान U+0000 से U+10FFFF तक है। यूनिकोड को सैद्धांतिक रूप से किसी दिन आगे बढ़ाया जा सकता है, लेकिन यह यूटीएफ -8 और यूटीएफ -16 को तोड़ देगा। हमें नए एन्कोडिंग की आवश्यकता होगी।

संपादित करें: असल में, मुझे यूटीएफ -16 टूटने पर उद्धरण न दें, लेकिन मुझे पूरा यकीन है कि यह यूटीएफ -8 तोड़ देगा। UTF-8 निश्चित रूप से 0xFFFFFF (2^24 -1) का प्रतिनिधित्व नहीं कर सकता।

2 संपादित करें: स्पष्ट करने के लिए, यूनिकोड कहता है कि कोड बिंदु कभी भी U+10FFFF से अधिक नहीं हो सकते। इसका मतलब यह नहीं है कि वर्तमान में 0x110000 कोड बिंदु हैं - उनमें से अधिकतर कोड बिंदु असाइन नहीं किए गए हैं।

@ज़ेनेक्सर @ जीएसपीपी

इस प्रकार के रूप में वर्तमान में मास्टर ( System.Text.Rune ) में चेक इन किया गया है, विशेष रूप से "यूनिकोड स्केलर वैल्यू" ( शब्दावली देखें ) के लिए मैप करता है। यदि आप इसे -1 , 0xD800 , या 0x110000 मानों से बनाने का प्रयास करते हैं, तो प्रकार के ctors अपवाद फेंक देंगे, क्योंकि ये यूनिकोड विनिर्देश के अनुसार स्केलर मान नहीं हैं। यदि आप अपनी विधि में इनपुट के रूप में Rune पैरामीटर लेते हैं, तो आपको उस पर कोई सत्यापन जांच करने की आवश्यकता नहीं है। टाइप सिस्टम ने पहले ही सुनिश्चित कर लिया है कि इसका निर्माण एक वैध स्केलर मान से किया गया था।

पुन:: केस रूपांतरण, .NET फ्रेमवर्क में सभी केस रूपांतरण एपीआई _जब तक अन्यथा नोट नहीं किया गया_ साधारण केस फोल्डिंग नामक तकनीक का उपयोग करें। साधारण केस फोल्डिंग के नियमों के तहत, किसी भी इनपुट स्केलर वैल्यू के लिए, आउटपुट लोअरकेस, अपरकेस और टाइटलकेस फॉर्म भी प्रत्येक एक स्केलर वैल्यू होने की गारंटी देते हैं। (कुछ इनपुट, जैसे अंक 0-9 या विराम चिह्न, में केस रूपांतरण मानचित्र में प्रविष्टियां नहीं होती हैं। इन मामलों में _ToUpper_ जैसे संचालन केवल इनपुट स्केलर मान लौटाते हैं।) इसके अतिरिक्त, साधारण केस फोल्डिंग नियमों के तहत यदि इनपुट है बेसिक बहुभाषी विमान (बीएमपी) में, तो आउटपुट भी बीएमपी में होना चाहिए; और यदि इनपुट एक पूरक विमान में है, तो आउटपुट भी एक पूरक विमान में होना चाहिए।

इसके कुछ परिणाम होते हैं। सबसे पहले, Rune.ToUpper और दोस्त हमेशा एक _Rune_ (स्केलर) मान लौटाएंगे। दूसरा, String.ToUpper और दोस्त हमेशा एक स्ट्रिंग को उसके इनपुट के समान लंबाई के साथ लौटाएंगे। इसका मतलब यह है कि एक केस रूपांतरण ऑपरेशन के बाद 'ß' (मिनीस्क्यूल एस्ज़ेट) युक्त एक स्ट्रिंग, इस्तेमाल की जा रही संस्कृति के आधार पर 'ß' (कोई परिवर्तन नहीं) या 'ẞ' (majuscule eszett) युक्त हो सकती है। लेकिन इसमें "एसएस" नहीं होगा, क्योंकि इससे स्ट्रिंग की लंबाई बदल जाएगी, और लगभग सभी सार्वजनिक रूप से उजागर .NET केस रूपांतरण एपीआई सरल केस फोल्डिंग नियमों का उपयोग करते हैं। तीसरा, Utf8String.ToUpper और दोस्तों (अभी तक चेक इन नहीं किया गया) को _not_ एक मान वापस करने की गारंटी है जिसकी _Length_ संपत्ति इनपुट मान की _Length_ संपत्ति से मेल खाती है। (एक स्ट्रिंग में UTF-16 कोड इकाइयों की संख्या साधारण केस फोल्डिंग के बाद नहीं बदल सकती है, लेकिन एक स्ट्रिंग में UTF-8 कोड इकाइयों की संख्या बदल सकती है। इसका कारण यह है कि UTF-16 और UTF द्वारा BMP मान कैसे एन्कोड किए जाते हैं- 8.)

कुछ .NET API हैं जो साधारण केस फोल्डिंग नियमों के बजाय आंतरिक रूप से जटिल केस फोल्डिंग नियमों का उपयोग करते हैं। String.Equals , String.IndexOf , String.Contains , और इसी तरह के संचालन संस्कृति के आधार पर कवर के तहत जटिल केस फोल्डिंग नियमों का उपयोग करते हैं। इसलिए यदि आपकी संस्कृति _de-DE_ पर सेट है, तो यदि आप _CurrentCultureIgnoreCase_ पास करते हैं, तो एक-वर्ण वाली स्ट्रिंग "ß" और दो-वर्ण वाली स्ट्रिंग "SS" की तुलना बराबर होगी।

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

वह वाक्य सही है। कोड स्थान U+0000 से U+10FFFF तक है। यूनिकोड को सैद्धांतिक रूप से किसी दिन आगे बढ़ाया जा सकता है, लेकिन यह यूटीएफ -8 और यूटीएफ -16 को तोड़ देगा। हमें नए एन्कोडिंग की आवश्यकता होगी।

बस नाइटपिकिंग होने के लिए (या, यदि लोग रुचि रखते हैं): सिद्धांत रूप में, यूटीएफ -8 एल्गोरिदम 42 बिट्स (उपसर्ग बाइट 0xFF और 6 बिट्स पेलोड के 7 बाइट्स) के लिए काम करता है, और मूल रूप से, पहले विनिर्देशों ने पूर्ण 31 को कवर किया यूनिवर्सल कैरेक्टर सेट (यूसीएस 4) के उन पुराने संस्करणों की

UTF-16 के लिए, स्थिति अधिक कठिन है। लेकिन वे ऊपरी विमान में कोड बिंदुओं को 32 बिट या उससे अधिक के लिए "एस्केप" के रूप में आरक्षित कर सकते थे। चूंकि विमान 3 से 13 वर्तमान में अपरिभाषित हैं, वे उनमें से दो को "लो सरोगेट प्लेन" और "हाई सरोगेट प्लेन" के रूप में आरक्षित कर सकते हैं। फिर एक 32 बिट कोडपॉइंट को दो 16 बिट मानों (प्रत्येक विमान में एक) में विभाजित किया जाएगा, और फिर प्रत्येक मान को दो "क्लासिक" सरोगेट्स का उपयोग करके एन्कोड किया जाएगा, 32 बिट कोडपॉइंट को एन्कोड करने के लिए प्रत्येक 16 बिट की 4 कोड इकाइयों का प्रभावी ढंग से उपयोग किया जाएगा।

बीटीडब्ल्यू, एएफएआईसीएस, यूनिकोड कंसोर्टियम ने सार्वजनिक रूप से कहा है कि वे कभी भी यू+10एफएफएफएफ से ऊपर कोडपॉइंट आवंटित नहीं करेंगे, इसलिए व्यवहार में, मुझे आशा है कि वास्तव में ऐसा होने से पहले मैं लंबे समय से सेवानिवृत्त हो जाऊंगा। :आँख मारना:

इस प्रकार के रूप में वर्तमान में मास्टर ( System.Text.Rune ) में चेक इन किया गया है, विशेष रूप से "यूनिकोड स्केलर वैल्यू" के लिए मैप करता है

@GrabYourPitchforks उस स्पष्टीकरण के लिए धन्यवाद। इसका मतलब है कि संरचना एक कोड बिंदु का प्रतिनिधित्व नहीं करती है। तो वह नाम वास्तव में गलत होगा।

मुझे लगता है कि UnicodeScalar एक नाम के रूप में बहुत रहस्यमय है ...

@GrabYourPitchforks , इस मुद्दे के लिए क्या करना बाकी है?

@stephentoub 3.0 के लिए इन-बॉक्स Rune प्रकार के लिए कोई अतिरिक्त कार्यक्षमता की योजना नहीं है, लेकिन @migueldeicaza के पास ग्रैफेम क्लस्टर जैसी चीज़ों सहित, प्रकार की पहुंच बढ़ाने के लिए विचार थे। (हमारे पास इन-बॉक्स सबसे नज़दीकी चीज़ है TextElementEnumerator , जो कि एक बहुत पुराना प्रकार है।) उनमें से कुछ विचारों को इस सूत्र में बांधा गया था लेकिन अभी तक कुछ भी ठोस नहीं है।

हम इस मुद्दे को खुला छोड़ सकते हैं यदि समुदाय परिदृश्यों पर आगे चर्चा करना चाहता है, या हम लोगों को नए मुद्दों को खोलने के लिए निर्देशित कर सकते हैं यदि वे विशिष्ट सुझाव देना चाहते हैं। टीबीएच मैं एक मजबूत वरीयता नहीं है।

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

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

मुझे पता है कि इसे इस बिंदु से एकीकृत किया गया है, लेकिन मैं सिर्फ Rune भाग और नाम के बारे में कुछ लोगों की असहमति पर झंकार करना चाहता हूं।

मुझे पहली बार योजना 9 में Rune का सामना करना पड़ा, और जैसे अन्य लोगों ने इसे गो और अन्य में देखा है। जब msdocs ने Rune को सूचीबद्ध करना शुरू किया तो मुझे पता था कि पढ़ने से पहले यह वास्तव में क्या था।

कम से कम दो उदाहरणों में, प्लान 9 और गो, आपके पास Rune नाम का उपयोग करके UTF-8 के लिए जिम्मेदार व्यक्ति हैं। मुझे लगता है कि यह कहना सुरक्षित है कि उन्होंने इन चिंताओं के बारे में पहले से ही सोचा था और अभी भी सोचा था कि Rune उचित था। कुछ परंपरावादियों के अलावा, रूनिक वास्तव में अब इस्तेमाल की जाने वाली लेखन प्रणाली नहीं है। और Rune का मतलब उस प्रणाली में ग्रैफेम है, ठीक वैसे ही जैसे इसका अनिवार्य रूप से यहां ग्रैफेम है (नियंत्रण वर्णों जैसे मामलों को छोड़कर।

मैं वास्तव में नामकरण में थोड़ा गलत देखता हूं। रूनिक इतनी पुरानी लेखन प्रणाली है, मुझे अत्यधिक संदेह है कि आपका औसत प्रोग्रामर इसे भ्रमित करने वाला है, और उचित यूनिकोड "वर्ण" के लिए Rune का कई दशक पुराना वास्तविक मानक पहले से ही है।

@ एंटोमी

ठीक वैसे ही जैसे इसका अनिवार्य रूप से अर्थ यहाँ ग्रैफेम है (नियंत्रण वर्णों जैसे मामलों को छोड़कर।

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

इसके विपरीत, यहां तक ​​कि जब एक एकल कोड बिंदु एक ग्रेफेम का प्रतिनिधित्व करता है, तो उनके लिए एक _grapheme क्लस्टर_ में संयोजित होना बहुत आम है, जो कि अधिकांश भारतीय भाषाओं में पाठ के उचित संचालन के लिए आवश्यक है। इसलिए, तीर कुंजियों के साथ चलते समय उपयोगकर्ता द्वारा माना जाने वाला एक एकल वर्ण अक्सर अनुक्रम में कई कोड बिंदुओं से मेल खाता है। इसलिए, कोड बिंदुओं और ग्रेफेम या ग्रेफेम समूहों के बीच कोई आसान पत्राचार नहीं किया जा सकता है। यहां तक ​​​​कि "चरित्र" शायद एक बेहतर नाम होगा, यह देखते हुए कि प्रोग्रामर इस बिंदु पर अजीब और निराला पात्रों पर विचार करने के लिए उपयोग किए जाते हैं, जबकि "रन" यह धारणा देता है कि उपयोगकर्ता-कथित चरित्र सीमाओं का पता लगाने का मुद्दा प्रोग्रामर के लिए हल हो गया है। पहले से ही जब यह वास्तव में नहीं था।

जब msdocs ने रूण को सूचीबद्ध करना शुरू किया तो मुझे पता था कि पढ़ने से पहले यह वास्तव में क्या था।

तथ्य यह है कि आपने सोचा था कि नाम रूण ने ग्रैफेम्स का अच्छी तरह से वर्णन किया है, इस मुद्दे का बहुत अच्छा सबूत है जो मेरे पास यहां है: नाम "रून" प्रोग्रामर को सुरक्षा की झूठी भावना देता है जिससे यह मानना ​​​​आसान हो जाता है कि ऐसा पत्राचार है।

कम से कम दो उदाहरणों में, प्लान 9 और गो, आपके पास Rune नाम का उपयोग करके UTF-8 के लिए जिम्मेदार व्यक्ति हैं।

केन थॉम्पसन और रॉब पाइक के लिए मेरे मन में जितना सम्मान है, यहां उनका काम अनिवार्य रूप से चर-लंबाई पूर्णांकों की एक श्रृंखला को एन्कोड करने के लिए एक बहुत ही चतुर योजना तैयार कर रहा था। वे समग्र रूप से यूनिकोड के विशेषज्ञ नहीं हैं, और मैं इस मुद्दे पर उनसे काफी असहमत हूं। मैं मानता हूं कि मैं यूनिकोड का विशेषज्ञ भी नहीं हूं, लेकिन मुझे नहीं लगता कि यहां प्राधिकरण की अपील उतनी मजबूत है जितनी यह लग सकती है।

और उचित यूनिकोड "वर्ण" के लिए रूण के कई दशक पुराने वास्तविक मानक पहले से ही मौजूद हैं।

"मानक" आप कहते हैं? यह ज्यादातर सिर्फ इन दोनों ने नाम को आगे बढ़ाया है, और कुछ छोटी प्रोग्रामिंग भाषाएं जैसे कि निम ने इसे गो से अपनाया है। और निश्चित रूप से मुझे फिर से दोहराना होगा कि एक कोड बिंदु एक "उचित यूनिकोड वर्ण" का प्रतिनिधित्व नहीं करता है, चाहे वह चयन, तीर कुंजी आंदोलन, ग्रैफेम या ग्रेफेम क्लस्टर के अर्थ में हो।

...अनिवार्य रूप से यहाँ ग्रैफेम का अर्थ है ...

हां, जैसा कि बिल्कुल नहीं, लेकिन मोटे तौर पर काफी करीब है। ग्रैफेम्स, कम से कम भाषाविज्ञान में परिभाषित होने के कारण, वे ऑर्थोग्राफ़िक घटक हैं जो एक लेखन प्रणाली बनाते हैं और स्वरों को व्यक्त करने के लिए उपयोग किए जाते हैं। ये 1:1 की बात नहीं हैं। सिलेबरी और लोगोसिलेबरी में एक एकल ग्रेफेम कई स्वरों का प्रतिनिधित्व कर सकता है, आमतौर पर एक व्यंजन-स्वर जोड़ी। इसके विपरीत वर्णानुक्रमिक भाषाओं में अक्सर एक ही स्वर का प्रतिनिधित्व करने वाले कई ग्रैफेम के मामले होते हैं, जैसे कि अंग्रेजी में "वें" विशिष्ट शब्द के आधार पर पुरातन नैतिकता और कांटे के लिए जिम्मेदार है। तब आप सभी भाषाओं में सहमति भी नहीं पा सकते हैं कि क्या 'á' जैसा अक्षर स्वयं का अनूठा अक्षर है, या 'a' एक उच्चारण के साथ है। हम हजारों साल पुरानी भाषाओं में एकरूपता भी स्थापित नहीं कर सकते। हम उसके ऊपर पूरी तरह से सुसंगत जोड़ नहीं रखने जा रहे हैं, वह है इनकी एन्कोडिंग।

चूँकि आप अत्यंत सख्त शब्दार्थ के लिए बहस कर रहे हैं, जिसे UNICODE "ग्राफेम क्लस्टर" कहता है, वह अक्सर भाषाविज्ञान में केवल एक ही ग्रैफेम होता है। क्या यह अमान्य यूनिकोड है? नहीं। क्या इसका मतलब यह है कि यूनिकोड को इसका नाम बदलने की जरूरत है? क्यों नहीं? क्योंकि प्रसंग। फ़ील्ड्स का अपना लिंगो होता है, और जब तक किसी एक फ़ील्ड में कॉन्फ़ेक्शन नहीं होता है, तब तक यह कोई समस्या नहीं है।

मैं नाम को बहुत बड़ी डील के रूप में नहीं देखता। सारांश में Rune क्या है, इसके बारे में Msdocs स्पष्ट है। अगर लोग दस्तावेज़ नहीं पढ़ते हैं तो यह उनकी अपनी समस्या है। लोग 'स्ट्रीम' पर जोरदार प्रतिक्रिया नहीं दे रहे हैं और बकवास कह रहे हैं जैसे "ओह लेकिन क्या होगा अगर लोग सोचते हैं कि यह एक छोटी नदी है, क्योंकि इसका पहले से ही एक ही नाम है!" नहीं।

@Serentty @Entomy आप दोनों को StringInfo वर्ग में भी रुचि हो सकती है, जो वास्तविक यूनिकोड अवधारणा "विस्तारित ग्रेफेम क्लस्टर" को उजागर करता है। StringInfo प्रकार काफी प्राचीन है और परिणामस्वरूप यूनिकोड मानक का एक बहुत पुराना संस्करण लागू करता है, लेकिन UAX #29, Sec के अनुरूप होने के लिए इसे अद्यतन करने के लिए सक्रिय कार्य है।

हां, जैसा कि बिल्कुल नहीं, लेकिन मोटे तौर पर काफी करीब है।

मुझे लगता है कि रचित बनाम विघटित अभ्यावेदन का मुद्दा इसे असत्य बनाता है। यदि हम किसी भी प्रकार की कंप्यूटिंग-संबंधित परिभाषा के विपरीत यहां एक ग्रैफेम की भाषाई परिभाषा से जा रहे हैं, तो और ग्रैफेम के सटीक समान अनुक्रम हैं (तीन हंगुल जामो शब्दांश _han_ को खंड HAN के रूप में दर्शाते हैं), और फिर भी पहला केवल एक कोड बिंदु है जबकि दूसरा तीन का अनुक्रम है।

फ़ील्ड्स का अपना लिंगो होता है, और जब तक किसी एक फ़ील्ड में कॉन्फ़ेक्शन नहीं होता है, तब तक यह कोई समस्या नहीं है।

ठीक यही मेरी भी बात है। यूनिकोड अपनी शब्दावली के साथ वास्तव में एक जटिल प्रणाली है, तो जब यह सटीक रूप से पंक्तिबद्ध नहीं होता है तो उस पर किसी प्रकार का आधा बेक्ड "सहज ज्ञान युक्त" शब्द लागू करने का प्रयास क्यों करें? कोड बिंदु कोड बिंदु हैं। उनके पास कोई भाषाई समानांतर नहीं है, और सहज होने की कोशिश कर रहा है, जबकि केवल 75% सटीक उसी तरह की आपदा के लिए एक नुस्खा है जिसे सी # अभी भी ठीक करने की कोशिश कर रहा है।

चूँकि आप अत्यंत सख्त शब्दार्थ के लिए बहस कर रहे हैं, जिसे UNICODE "ग्राफेम क्लस्टर" कहता है, वह अक्सर भाषाविज्ञान में केवल एक ही ग्रैफेम होता है।

मानक में, एक क्लस्टर को केवल एक ग्रेफेम शामिल करने की अनुमति है। यहां इसमें कुछ भी गलत नहीं है। A _cluster_ पाठ चयन और कर्सर गति की एक इकाई है।

मैं नाम को बहुत बड़ी डील के रूप में नहीं देखता। सारांश में रूण क्या है, इसके बारे में Msdocs स्पष्ट है। अगर लोग दस्तावेज़ नहीं पढ़ते हैं तो यह उनकी अपनी समस्या है।

यह "प्रोग्रामर को होशियार होने की आवश्यकता है" तर्क है जो खराब डिजाइन निर्णयों के बचाव में बार-बार सामने आता है। यदि प्रोग्रामर को दस्तावेज़ीकरण पढ़ने और सीखने की ज़रूरत है कि एक रन यूनिकोड कोड बिंदु है, तो इसे पहले स्थान पर अधिक "सहज" नाम कहने का क्या मतलब है? यहां तर्क यह प्रतीत होता है कि "कोड बिंदु" भ्रमित करने वाला है, इसलिए अधिक सहज नाम चुनना समझ में आता है, लेकिन फिर जब नाम के भ्रामक होने के मुद्दे का सामना करना पड़ता है, तो बचाव यह है कि प्रोग्रामर को पता होना चाहिए कि कोड बिंदु क्या है वैसे भी दस्तावेज़ीकरण पढ़ने से। अगर ऐसा है, तो क्यों न केवल CodePoint टाइप करें और प्रोग्रामर के लिए इसे देखना और सीखना आसान बनाएं? यह सब इस मुद्दे को एक तरफ रख रहा है कि पहली जगह में यूनिकोड के संबंध में .NET दस्तावेज बहुत भयानक है, सरोगेट जोड़े को "16-बिट यूनिकोड वर्णों" की दुनिया में बाद में माना जाता है।

यह "प्रोग्रामर को होशियार होने की आवश्यकता है" तर्क है जो खराब डिजाइन निर्णयों के बचाव में बार-बार सामने आता है।

मैंने यह कभी नहीं कहा।

यहाँ तर्क यह प्रतीत होता है कि "कोड बिंदु" भ्रमित करने वाला है

यह भी मैंने कभी नहीं कहा।

लोग 'स्ट्रीम' पर जोरदार प्रतिक्रिया नहीं दे रहे हैं और बकवास कह रहे हैं जैसे "ओह लेकिन क्या होगा अगर लोग सोचते हैं कि यह एक छोटी नदी है, क्योंकि इसका पहले से ही एक ही नाम है!" नहीं।

मैं कह रहा हूं कि प्रोग्रामर इतने स्मार्ट हैं कि यह नहीं सोचते कि Rune विशेष रूप से एक रूनिक रन है, ठीक उसी तरह जैसे वे जानते हैं कि Stream एक छोटी नदी नहीं है।

मुझे इसे दोहराने दो

मैं कह रहा हूं कि प्रोग्रामर इसे समझने के लिए काफी स्मार्ट हैं। तुम मेरे मुंह में शब्द डाल रहे हो।

मैं नाम को बहुत बड़ी डील के रूप में नहीं देखता। सारांश में रूण क्या है, इसके बारे में Msdocs स्पष्ट है। अगर लोग दस्तावेज़ नहीं पढ़ते हैं तो यह उनकी अपनी समस्या है।

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

मैं कह रहा हूं कि प्रोग्रामर इतने स्मार्ट हैं कि यह नहीं सोचते कि Rune विशेष रूप से एक रूनिक रन है, ठीक उसी तरह जैसे वे जानते हैं कि Stream एक छोटी नदी नहीं है।

यहां मेरा तर्क यह नहीं है कि लोग इसे रूनिक रनों से भ्रमित करेंगे। मेरा तर्क यह है कि लोग इसे ग्लिफ़, ग्रैफेम और ग्रैफेम क्लस्टर के साथ भ्रमित कर देंगे, जो आपके आग्रह के बावजूद कोड बिंदुओं के साथ बहुत बुरी तरह से संबंधित हैं।

मैं कह रहा हूं कि प्रोग्रामर इसे समझने के लिए काफी स्मार्ट हैं। तुम मेरे मुंह में शब्द डाल रहे हो।

यह पता लगाने के लिए पर्याप्त स्मार्ट है कि वे वास्तविक जर्मनिक रन नहीं हैं, निश्चित रूप से। लेकिन यह पता लगाने के लिए कि वे ग्लिफ़, ग्रेफेम या ग्रेफेम क्लस्टर नहीं हैं? यूनिकोड के अधिकांश सॉफ़्टवेयर की हैंडलिंग की गुणवत्ता के साथ मेरा वास्तविक अनुभव नहीं कहता है।

अगर लोग दस्तावेज़ नहीं पढ़ते हैं तो यह उनकी अपनी समस्या है।

हां, और मैं इस पर कायम हूं। यह बुद्धि में कमी की बात नहीं है, बल्कि जल्दबाजी की धारणाओं की प्रवृत्ति के कारण है।

यदि कोई प्रोग्रामर मानता है कि String का अर्थ है एक मजबूत, पतला, रस्सी का टुकड़ा, जो धागों के घुमाव से बना है, क्योंकि, हाँ इसका मतलब यह है कि, इसे String नाम की समस्या नहीं माना जाता है .

यदि कोई प्रोग्रामर मानता है कि Char का अर्थ है चारकोल, या एक विशेष प्रकार की ट्राउट जैसी जली हुई सामग्री, जिसे Char नाम की समस्या नहीं माना जाता है।

यदि कोई प्रोग्रामर मानता है कि character का अर्थ कहानी कहने में प्रयुक्त मानसिक और नैतिक लक्षणों के एक सेट का चित्रण है, जिसे character नाम के साथ कोई समस्या नहीं माना जाता है।

ध्यान दें कि ये सभी टेक्स्ट/भाषाई मामले हैं। उन सभी के अन्य अर्थ हैं। और फिर भी प्रोग्रामर ने ठीक-ठाक अभ्यस्त किया है। क्षेत्र में एक स्थापित सम्मेलन के कारण वे शब्द वास्तविक मानक बन गए हैं: हमारा लिंगो। एक स्थापित मिसाल है कि प्रोग्रामर _are_ इसके साथ चलने के लिए पर्याप्त स्मार्ट हैं।

आप स्वयं यह तर्क दे रहे थे कि दोनों इतनी निकटता से पंक्तिबद्ध थे कि यह कोई मुद्दा नहीं था।

हाँ यह गिटहब है। पहले से बंद मुद्दे पर, जहां मैं सिर्फ अपने विचार जोड़ रहा था कि मुझे क्यों लगा कि Rune ठीक था क्योंकि नाम में कुछ स्थापित मिसाल थी। व्यापक परिभाषाओं और ध्यान से चुने गए शब्दों से भरा एक ग्रंथ लिखने का यह स्थान या संदर्भ नहीं है। उदाहरण के लिए, यदि मैं एक यूटीएफ -8 डिकोडर के लिए पीआर डाल रहा हूं, तो मैं स्पष्ट रूप से वर्णन नहीं कर रहा हूं कि मैंने वैकल्पिक तरीकों पर होहरमैन डीएफए को क्यों लागू किया। मैं बस यह कहने वाला हूं "यहाँ यह है, यहाँ कुछ प्रमाण है जो यह काम करता है, यहाँ कुछ बेंचमार्क हैं जो मैं इसके साथ क्यों गया"।

मेरा तर्क यह है कि लोग इसे ग्लिफ़, ग्रैफेम और ग्रेफेम क्लस्टर के साथ भ्रमित करेंगे

वे उपरोक्त में से किसी को भी भ्रमित नहीं कर रहे हैं, न ही Tree , Heap , Table , Key , Socket , Port ...

यह बेहद बेहूदा तर्क है। धागे का एक टुकड़ा और पाठ की एक स्ट्रिंग आसानी से भ्रमित नहीं होती है। एक लंबा पौधा और एक पेड़ डेटा संरचना आसानी से भ्रमित नहीं होती है। दूसरी ओर एक कोड बिंदु अधिकांश प्रोग्रामर द्वारा बहुत कम समझी जाने वाली अवधारणा है, और लगातार उन सभी अन्य अवधारणाओं के साथ भ्रमित है जिनकी हमने चर्चा की है। इसका समाधान है, जैसा कि आप कहते हैं, दस्तावेज़ीकरण पढ़ना। हालाँकि, कोड बिंदुओं के लिए अपने स्वयं के "चतुर" नाम का उपयोग करने वाली भाषा _वास्तविक यूनिकोड दस्तावेज़ीकरण_ से उस भाषा में ज्ञान को लागू करना और भी कठिन बना देती है। और यह मुझे इस पर लाता है:

क्षेत्र में एक स्थापित सम्मेलन के कारण वे शब्द वास्तविक मानक बन गए हैं: हमारा लिंगो।

और यही सबका मूल है। आप दावा कर रहे हैं कि या तो "रन" एक कोड बिंदु के लिए एक अच्छी तरह से स्थापित शब्द है जिसे प्रोग्रामिंग में व्यापक रूप से समझा जाता है, या यह होना चाहिए। यदि यह पूर्व है, तो मैं आपको गो के अलावा किसी अन्य प्रमुख प्रोग्रामिंग भाषा में अनुभवी औसत प्रोग्रामर से पूछने के लिए आमंत्रित करता हूं यदि उन्होंने इसे कभी सुना है। यदि यह बाद की बात है, तो मैं आपसे पहले से ही भ्रमित और खराब समझी जाने वाली स्थिति में आधिकारिक यूनिकोड शब्दावली के साथ प्रतिस्पर्धा करने की बात पूछूंगा, जिसे अक्सर अत्यधिक अनुभवी डेवलपर्स द्वारा भी गलत समझा जाता है।

@Entomy बाहरी इनपुट: आपका पूरा तर्क, जहाँ तक मैं बता सकता हूँ, 'यह भ्रमित करने वाला और बुरा है, हाँ, लेकिन यह उतना भ्रमित और बुरा नहीं है '।
इसलिए? इसके बजाय यह वास्तव में अच्छा क्यों नहीं हो सकता? इसे यूनिकोड नाम देने में क्या समस्या है?
इसके अलावा, कंप्यूटिंग के सामान्य क्षेत्र में रनों कोड बिंदु, या यहां तक ​​​​कि ग्रैफेम या क्लस्टर नहीं हैं। यदि आप Google में 'यूनिकोड रन' खोजते हैं, तो कोड बिंदुओं से संबंधित कुछ भी पृष्ठ 2 तक दिखाई नहीं देता है, और फिर भी यह सिर्फ गोडोक/निम लिंक है। DuckDuckGo पर भी, जो प्रोग्रामर के साथ अधिक सहज हो सकते हैं, यह अभी भी एक पेज 2 परिणाम है। तो मैंने जो नाम देखा है उसके लिए एकमात्र तर्क यह है कि यह सहज ज्ञान युक्त है कि यह एक कोड बिंदु का प्रतिनिधित्व करता है, लेकिन यह नहीं है । यह सहज है कि यह एक ग्रेफेम क्लस्टर, या शायद सिर्फ एक ग्रेफेम का प्रतिनिधित्व करता है।
स्रोत: मैंने गो का उपयोग किया है और मुझे लगा कि यह चार साल बाद तक एक ग्रैफेम था जब मैंने इस मुद्दे को अभी पढ़ा।

(और कह रहा है कि यह ठीक है कि यह एक ग्रैफेम का सुझाव देता है क्योंकि यह 'काफी करीब' है मुझे 16-बिट चार के काफी करीब होने की याद दिलाता है।)
हां, यदि प्रोग्रामर होशियार होते और अधिक दस्तावेज पढ़ते हैं तो हमें इसके लिए एक सार्थक नाम या यहां तक ​​कि एक प्रकार की भी आवश्यकता नहीं होगी। लोग सिर्फ चार के बजाय एक इंट में कोड पॉइंट पास करना जानते होंगे। लेकिन वे नहीं हैं। वे उतने ही स्मार्ट हैं जितने वे अभी हैं, और यह सिर्फ इसलिए बदलने वाला नहीं है क्योंकि अभी तक एक और एपीआई जोड़ा गया था। लक्ष्य सॉफ्टवेयर की मात्रा में वृद्धि करना है जो अंग्रेजी के अलावा अन्य भाषाओं को सही ढंग से संभालता है, न कि केवल एक ही काम करने के लिए नए तरीके पेश करता है और पहले की तरह ही प्रवेश के लिए समान बाधाओं को रखता है।

सिर्फ तर्क के लिए, और वैज्ञानिक उद्देश्यों के लिए, मैं यहां सभी को एक प्रोग्रामिंग भाषा पर इंगित करना चाहता हूं जो यूनिकोड टेक्स्ट को सबसे अच्छी तरह से संभालती है, जहां »सर्वश्रेष्ठ« को यूनिकोड मानक के अनुसार »निकटतम द्वारा परिभाषित किया गया है«, नहीं नकली सादगी से: स्विफ्ट

• String मनमाने ढंग से यूनिकोड टेक्स्ट का बफर है।
• Character , जिसे आप पुनरावृति करते हैं और क्या नहीं , एक यूनिकोड स्केलर मान नहीं है, बल्कि एक विस्तारित ग्रैफेम क्लस्टर है। ग्रेफेम क्लस्टर के लिए यह उदाहरण देखें 한 : let decomposed: Character = "\u{1112}\u{1161}\u{11AB}" // ᄒ, ᅡ, ᆫ
• यदि आपको यूनिकोड स्केलर मानों की आवश्यकता है, तो आप उन पर भी पुनरावृति कर सकते हैं। उनके प्रकार को UnicodeScalar कहा जाता है।
• और यदि आपको वास्तव में इसकी आवश्यकता महसूस होती है, तो आप UTF-8 और UTF-16 कोड इकाइयों पर पुनरावृति भी कर सकते हैं, जो UInt 8 s और UInt 16 s का उत्पादन करते हैं।

अब, मैं यहाँ C# को पूर्ण स्विफ्ट शैली में जाने का सुझाव नहीं दे रहा हूँ। हालांकि यह आश्चर्यजनक होगा, यह भी बहुत सारे बदलाव और काम की जरूरत है। मैं यहाँ स्विफ्ट-शैली के नामकरण को चुनने का सुझाव देने के लिए हूँ, हालाँकि, सभी कारणों से @Serentty ने बताया, और टेक्स्ट स्ट्रिंग्स को अंततः स्विफ्ट शैली को चालू करने के लिए विकल्प को खुला छोड़ने के लिए।

Rune से कुछ संभावित बेहतर नाम: CodeUnit32 , UnicodeScalar , CodeUnit , UniScalar , UnicodeValue , UniValue , UnicodeScalarValue । मुझे लगता है कि पहले दो सी # के नामकरण सम्मेलनों में अच्छी तरह फिट हो सकते हैं। ध्यान दें कि UnicodeScalar वस्तुनिष्ठ रूप से बेहतर नाम है, क्योंकि कोड इकाइयाँ यूनिकोड लिंगो में यूनिकोड स्केलर मान को एन्कोड करने के केवल तरीके हैं। तो CodeUnit32 का तात्पर्य UTF-32-एन्कोडेड टेक्स्ट स्ट्रिंग की कोड इकाइयों पर पुनरावृत्ति है, जबकि UnicodeScalar एन्कोडिंग-अज्ञेयवादी है।

संपादित करें: हाँ, System.Rune नाम पहले से ही उपलब्ध है। यह सब सिर्फ एक »अगर हम इसे आधा दशक पुराना होने से पहले इसे बेहतर बनाना चाहते हैं«.

@ पाई-स्वाद

आपका पूरा तर्क, जहाँ तक मैं बता सकता हूँ, 'यह भ्रमित करने वाला और बुरा है, हाँ, लेकिन यह इतना भ्रमित और बुरा नहीं है'।

नहीं, यह मेरा तर्क बिल्कुल नहीं है। मैं अपनी विकलांगता के साथ सर्वश्रेष्ठ कर रहा हूं, लेकिन यह मेरा इच्छित संचार नहीं है।

यदि आप Google में 'यूनिकोड रन' खोजते हैं, तो कोड बिंदुओं से संबंधित कुछ भी पृष्ठ 2 तक दिखाई नहीं देता है, और फिर भी यह सिर्फ गोडोक/निम लिंक है।

यदि आप Google में 'यूनिकोड स्ट्रिंग' खोजते हैं तो आपको विशेष रूप से यह नहीं मिलेगा कि .NET स्ट्रिंग्स कैसे काम करती हैं। यह आसन्न वस्तु की खोज का विषय है। एक बहुत सख्त सादृश्य के रूप में, मैं .NET और Ada दोनों में प्रोग्राम करता हूं; string उनके बीच समान नहीं है, और प्रत्येक के लिए कुछ मामूली पढ़ना एक अच्छा विचार है।

भाषा में अतिभारित परिभाषाएं असामान्य नहीं हैं, और फिर भी हम ठीक प्रबंधन करते हैं। यह आपको आश्चर्यचकित कर सकता है, लेकिन "रन" में कम से कम 179 औपचारिक परिभाषाएं हैं, "टेक" में कम से कम 127, "ब्रेक" में कम से कम "123" है, और इसी तरह। [ स्रोत ] लोग आश्चर्यजनक रूप से सक्षम हैं और जो यहां समस्याग्रस्त समझा जाता है उससे कहीं अधिक जटिलता को सफलतापूर्वक नेविगेट कर सकते हैं। कम से कम 2 औपचारिक परिभाषाओं वाले "रून" की चिंता, मेरी राय में, जब लोगों को 50x से अधिक ओवरलोड से निपटने के लिए दिखाया जा सकता है, तब वारंट नहीं किया जाता है।

इसके अलावा, यह खोज इंजन व्यवहार का घोर शोषण कर रहा है। अधिकांश खोज इंजनों के साथ, आपको इस आधार पर परिणाम मिलते हैं कि कितने पृष्ठ किसी चीज़ से लिंक होते हैं। अन्य कारक भी हैं, प्रत्येक दृष्टिकोण के साथ चीजों को अलग तरह से भारित किया जाता है। चूंकि .NET Rune तुलना के हिसाब से काफी हालिया अवधारणा है, इसके बारे में बात करने वाली सामग्री बहुत कम होगी, और इसे प्राप्त करने के लिए और अधिक पृष्ठ लगेंगे। लेकिन यह गलत सर्च टूल का भी इस्तेमाल कर रहा है। अगर मैं स्ट्रिंग-खोज एल्गोरिदम पर शोध खोजना चाहता हूं, यह देखने के लिए कि पिछले कुछ सालों में कुछ नया आया है या नहीं, तो मैं Google या डीडीजी नहीं खोजता। सिमेंटिक स्कॉलर, गूगल स्कॉलर और अन्य बेहतर शुरुआती बिंदु हैं। इसी तरह, यदि आप .NET API के बारे में चीजों को समझना चाहते हैं, तो आप पहले MSDocs खोजते हैं। अगर मैं शिकायत करता हूं कि "जड़ता का क्षण", एक भौतिकी/इंजीनियरिंग शब्द, इसके नाम पर अस्पष्ट या भ्रामक है, और इसका नाम बदल दिया जाना चाहिए क्योंकि मुझे सबसे कम संख्या से शुरू होने वाली पहली कुछ किताबों में इसके बारे में कोई जानकारी नहीं मिल रही है डेवी दशमलव वर्गीकरण का उपयोग करने वाले पुस्तकालय में, यह "जड़ता के क्षण" के नामकरण में कोई समस्या नहीं है; मैं स्पष्ट रूप से गलत जगह देख रहा हूँ।

स्रोत: मैंने गो का उपयोग किया है और मुझे लगा कि यह चार साल बाद तक एक ग्रैफेम था जब मैंने इस मुद्दे को अभी पढ़ा।

मैंने गो डॉक्स को देखा और नोट्स जारी किए, कम से कम वे जो मुझे मिले, और मुझे आपसे सहमत होना होगा। वे इस बारे में बहुत अस्पष्ट हैं कि rune क्या है, और दुर्भाग्य से यह भी अस्पष्ट है कि rune कितना बड़ा है। मुझे संदेह है कि यह अस्पष्टता बाद में समस्याओं का कारण बनेगी, जैसा कि मैंने देखा है कि एडा डेटा प्रकार की बाधाओं के बारे में समान रूप से अस्पष्ट है और बाद में गधे में खुद को काटता है।

हालाँकि मुझे कहना होगा कि msdocs बहुत विस्तृत और संक्षिप्त विवरण के साथ बहुत बेहतर काम करता है।

एक यूनिकोड स्केलर मान का प्रतिनिधित्व करता है ([यू+0000..यू+डी7एफएफ], समावेशी; या [यू+ई000..यू+10एफएफएफएफ], समावेशी)।

यह कहा जा रहा है, टिप्पणियों में कुछ कमी है और कुछ विस्तार क्यों Rune मौजूद है और जब आप इसका उपयोग करना चाहते हैं तो यह फायदेमंद होगा (और मेरे सरलीकृत उपरोक्त की तुलना में अधिक विस्तृत स्पष्टीकरण के लिए उपयुक्त स्थान भी) . मैं वहां कुछ सुधार आगे रखूंगा।

@Evrey

सिर्फ तर्क के लिए, और वैज्ञानिक उद्देश्यों के लिए, मैं यहां सभी को एक प्रोग्रामिंग भाषा पर इंगित करना चाहता हूं जो यूनिकोड टेक्स्ट को सबसे अच्छी तरह से संभालती है

यह एक राय है। एक मैं बिल्कुल सहमत हूँ; स्विफ्ट निश्चित रूप से आधुनिक यूनिकोड को बेहतर तरीके से संभालती है। लेकिन इन परिणामों की पुष्टि करने वाले सहकर्मी-समीक्षित प्रतिलिपि प्रस्तुत करने योग्य शोध के उद्धरण के बिना, यह एक वैज्ञानिक दावा नहीं है।

अब, मैं यहाँ C# को पूर्ण स्विफ्ट शैली में जाने का सुझाव नहीं दे रहा हूँ। हालांकि यह आश्चर्यजनक होगा, यह भी बहुत सारे बदलाव और काम की जरूरत है।

और मौजूदा सॉफ्टवेयर को तोड़ देगा।

टेक्स्ट स्ट्रिंग्स को अंततः स्विफ्ट शैली को चालू करने के लिए विकल्प को खुला छोड़ दें।

और मौजूदा सॉफ्टवेयर को तोड़ देगा।

हाँ, नाम System.Rune पहले से ही उपलब्ध है। यह सब सिर्फ एक »अगर हम इसे आधा दशक पुराना होने से पहले इसे बेहतर बनाना चाहते हैं«.

और मौजूदा सॉफ्टवेयर को तोड़ देगा।

एक काल्पनिक के रूप में यदि मौजूदा नाम में परिवर्तन किए जाने थे, तो आप मौजूदा सॉफ़्टवेयर लक्ष्यीकरण का प्रस्ताव कैसे करते हैं .NET Core 3.0/3.1, जहां Rune पहले से ही उपयोग में है, फिर भी संगत होना चाहिए, जबकि यह भी मौजूद है बाद के लक्ष्य रनटाइम में एक अलग नाम?

और मौजूदा सॉफ्टवेयर को तोड़ देगा।

जैसा कि उल्लेख किया गया है, मैं सिर्फ सिद्धांत और आदर्शवाद के दृष्टिकोण से बहस कर रहा हूं। चीजों की वास्तविकता का भरपूर उल्लेख किया गया है। हालांकि इन सब में कुछ बारीकियां हैं:

• स्ट्रिंग्स के साथ स्विफ्ट-स्टाइल जाने से जरूरी नहीं कि सॉफ्टवेयर टूट जाए। यह पहले से मौजूद String इंटरफ़ेस के शीर्ष पर अधिक गणना विधियों और प्रकारों को जोड़ने की बात है। मेरा मतलब कट्टरपंथी चीजों से नहीं है जैसे System.Char को ग्रैफेम क्लस्टर प्रकार में बदलना या उसके द्वारा कुछ ऐसी चीज।
• यदि मौजूदा प्रकार के नाम जैसे System.Char को एक अलग प्रकार के लिए फिर से तैयार किया जाएगा, तो हाँ, यह एक बहुत बड़ा ब्रेकिंग बदलाव होगा। और उस पर एक गैर जिम्मेदाराना बदलाव। मैं वहाँ तुम्हारे साथ हूँ।
• एक काल्पनिक .NET Core 4.0, SemVer में बोलते हुए, कुछ भी कर सकता है जो वह चाहता है। इसके अलावा, एक काल्पनिक 4.0 तक के परिवर्तन इतने डरावने नहीं हैं: System.Rune को System.UnicodeScalar या जो भी नाम होगा, के लिए एक पदावनत प्रकार के उपनाम में बदल दें। Rune का उपयोग करने वाले सॉफ़्टवेयर में एक मूल्यह्रास नोट के अलावा कोई अंतर नहीं दिखाई देगा, और नया सॉफ़्टवेयर बेहतर-नाम वाले वास्तविक प्रकार का उपयोग कर सकता है। और एक काल्पनिक 4.0 तो बस Rune गिर जाता है।
• इसी तरह, System.Char को System.CodeUnit16 या कुछ और के लिए उपनाम में बदला जा सकता है।
• इसे स्विफ्ट-स्टाइल करने से प्रभावी रूप से मिश्रण में System.GraphemeCluster जोड़ने का मतलब है।
• इन सभी प्रकारों के लिए अधिक, नए कीवर्ड उपनामों का परिचय समस्याग्रस्त हो सकता है।

यहाँ सिर्फ विचार के लिए खाना छोड़ रहे हैं। मुझे लगता है कि System.Rune , जबकि इसके उद्देश्य के लिए एक खराब प्रकार का नाम, वास्तव में पिछली नामकरण स्थिति को और भी खराब नहीं बनाता है। मुझे लगता है कि यह बहुत अच्छा है कि आखिरकार सभी यूनिकोड स्केलर को एन्कोड करने में सक्षम एक उचित प्रकार है। हालाँकि, मुझे अधिक सटीक यूनिकोड हैंडलिंग और नामकरण की प्रवृत्ति को फैलाने का एक अच्छा अवसर दिखाई देता है। एक अवसर यहां हर कोई अलग रखने के लिए स्वतंत्र है।

हाय सब - नाम System.Text.Rune वह है जिसे शिप किया गया है और हम आगे क्या उपयोग कर रहे हैं। Rune के बजाय UnicodeScalar नाम का उपयोग करने की महत्वपूर्ण (और गर्म!) पहले चर्चा हुई Rune , लेकिन अंत में Rune जीत गई। टीम इस समय इसके लिए कोई दूसरा नाम चुनने पर विचार नहीं कर रही है। और जब मैं जानता हूं कि लोग इसके बारे में भावुक हैं और हम यहां बातचीत की निगरानी करना जारी रखेंगे, अंततः इस बात से अवगत रहें कि नामकरण के मुद्दे पर मुकदमेबाजी जारी रखने में खर्च की गई कोई भी ऊर्जा लाभांश नहीं देगी।

स्पष्टीकरण के लिए, और डॉक्स के अनुसार: .NET में System.Text.Rune प्रकार बिल्कुल यूनिकोड स्केलर मान के बराबर है। यह निर्माण द्वारा लागू किया जाता है। यह स्विफ्ट के UnicodeScalar प्रकार की तुलना में इसे गो के rune प्रकार के अधिक अनुरूप बनाता है।

Rune डॉक्स में एक अनुभाग जोड़ने का प्रयास किया जा रहा है जिसमें इसके उपयोग के मामलों का विवरण दिया गया है और यह .NET में अन्य टेक्स्ट प्रोसेसिंग एपीआई और यूनिकोड में अवधारणाओं से कैसे संबंधित है। ट्रैकिंग समस्या https://github.com/dotnet/docs/issues/15845 पर है। उस ट्रैकिंग समस्या से अवधारणा दस्तावेज़ों के वर्तमान मसौदे का एक लिंक भी है।

मेरे लिए UnicodeScalar के साथ मुख्य दोष प्रकार के नाम की लंबाई और प्रकार के डेटासाइज के बीच बड़ी असमानता है। अनिवार्य रूप से यह एक int है जिसके डोमेन में कुछ अंतराल हैं।

हालाँकि, उपयोग में वाचालता चरम पर होगी:

foreach (UnicodeScalar unicodeScalar in name.EnumerateUnicodeScalars())
{
     // ... unicodeScalar contains 1 int
}

बनाम बराबर char एक string से अधिक (और आदर्श रूप से लोग char से अधिक नए प्रकार का उपयोग करेंगे क्योंकि वे विभाजित मान रखने के बजाय संपूर्ण मान हैं)

foreach (char c in name)
{
     // ... c contains 1 ushort
}

रूण प्रकार नाम क्रिया में एक समझौता है:

foreach (Rune rune in name.EnumerateRunes())
{
     // ... rune contains 1 int
}

@GrabYourPitchforks

नमस्कार! सच कहूं तो, मैं इस तर्क में फंस गया क्योंकि मैं .NET लोगों को यह समझाने की कोशिश कर रहा हूं कि नाम बदलने की जरूरत है, क्योंकि ऐसा लगता है कि वह जहाज चला गया है, लेकिन सिर्फ इसलिए कि मैं अपनी राय व्यक्त करना चाहता था इस सूत्र में अन्य जो इससे असहमत थे। मुझे लगता है कि यह आश्चर्यजनक है कि सी # में अंततः एक _real_ चरित्र प्रकार है जो टूटे हुए चरित्र प्रकार के विपरीत है, और यह नाम पूरी तरह से माध्यमिक है। मैं समझता हूं कि संक्षिप्तता और सटीकता के बीच एक बहुत बड़ा संतुलन बनाना है, और हालांकि मैं इसे कहीं CodePoint के आसपास रख देता, मैं समझता हूं कि अन्य लोग असहमत क्यों होंगे।

लेकिन फिर से, मैं .NET के यूनिकोड समर्थन के आधुनिकीकरण में कड़ी मेहनत के लिए आपको धन्यवाद देना चाहता हूं! यह कुछ ऐसा है जो दुनिया भर में बहुत से लोगों के लिए एक बड़ा अंतर बनाता है।