Runtime: .NET Core 3.0 -> .NET 5.0 से string.IndexOf (string) के साथ परिवर्तन

@tarekgh

इस क्षेत्र के ग्राहकों को टैग करना: @tarekgh , @safern , @krwq
यदि आप सदस्यता प्राप्त करना चाहते हैं, तो क्षेत्र में जानकारी देखें।

यह डिजाइन के अनुसार है। .NET 5.0 में हमने NLS के बजाय ICU का उपयोग किया है। आप अधिक विवरण के लिए https://docs.microsoft.com/en-us/dotnet/standard/globalization-localization/globalization-icu पर देख सकते हैं।

आपके पास पुराने व्यवहार पर वापस जाने के लिए config स्विच System.Globalization.UseNls का उपयोग करने का विकल्प है लेकिन हम ऐसा करने की अनुशंसा नहीं करते हैं क्योंकि ICU अधिक सही है और ICU का उपयोग करके आगे बढ़ना OS के पार स्थिरता देगा।

यह कहना भूल गया, यदि आप IndexOf Contains रूप में व्यवहार करते हैं, तो आपको उस समय साधारण तुलना का उपयोग करना चाहिए।

C# actual.IndexOf(expected, StringComparison.Ordinal)

आपके पास पुराने व्यवहार पर वापस जाने के लिए config switch System.Globalization.UseNls का उपयोग करने का विकल्प है, लेकिन हम यह करने की अनुशंसा नहीं करते हैं कि ICU अधिक सही है और ICU का उपयोग करके आगे बढ़ना OS के पार स्थिरता देगा।

हाँ, यदि आप यूनिक्स में netcoreapp3.1 लक्ष्य रखते हुए इस कोड को चलाते हैं, तो आपको यही व्यवहार दिखाई देगा:

 santifdezm  DESKTOP-1J7TFMI  ~  experimental  indexof  $   /home/santifdezm/experimental/indexof/bin/Debug/netcoreapp3.1/linux-x64/publish/indexof
actual.Contains(expected): True
actual.IndexOf(expected): -1

और @tarekgh के रूप में Ordinal तुलना के साथ यह अपेक्षित परिणाम देता है।

 santifdezm  DESKTOP-1J7TFMI  ~  experimental  indexof  $  /home/santifdezm/experimental/indexof/bin/Debug/net5.0/linux-x64/publish/indexof
actual.Contains(expected): True
actual.IndexOf(expected): 1475

मुझे लगता है कि यह विफल हो रहा है क्योंकि स्रोत स्ट्रिंग में \r\n और \n है। अगर मैं \r\n सभी उदाहरणों के साथ \n काम करता हूं। अगर मैं सब कुछ \r\n बनाता हूं तो यह सच है। यह सिर्फ मिक्स है जो आईसीयू की तुलना से अलग परिणाम में होता है।

जैसा कि ट्विटर पर रिपोर्ट किया गया था कि 5.0 रनटाइम के भीतर, स्ट्रिंग को बार-बार कॉल किया गया था। और उसी इनपुट के साथ exexOf प्रत्येक कॉल के लिए अलग-अलग परिणाम दे रहा था।

https://twitter.com/jbogard/status/1319381273585061890?s=21

संपादित करें: ऊपर एक गलतफहमी थी।

@GrabYourPitchforks क्या हम समस्या शीर्षक को फिर अपडेट कर सकते हैं? जैसा कि यह तकनीकी रूप से एक परिवर्तन है, लेकिन यह विंडोज और यूनिक्स पर होता है ... सही है?

मैंने स्पष्टीकरण के लिए जिमी को ऑफलाइन पिंग किया। यह संभव है कि मैंने उनकी मूल मुद्दे की रिपोर्ट को गलत समझा। 280-char फ़ोरम बग को स्पष्ट रूप से संप्रेषित करने में हमेशा कुशल नहीं होते हैं। ;)

बस स्पष्ट करने के लिए, Contains API क्रमिक संचालन कर रहा है। IndexOf बिना किसी स्ट्रिंग तुलना झंडे के भाषाई संचालन है और न कि क्रमिक। यदि IndexOf के साथ Contains व्यवहार की तुलना करना चाहते हैं, तो IndexOf(expected, StringComparison.Ordinal) का उपयोग करने की आवश्यकता है।
यदि अंतर के बारे में अधिक जानने की आवश्यकता है, तो https://docs.microsoft.com/en-us/dotnet/csharp/how-to/compare-strings उपयोगी लिंक है।

मुझे ट्विटर पर स्पष्टीकरण मिला। एप्लिकेशन लूप में IndexOf कॉल नहीं कर रहा है। यह सिर्फ एक मानक 3.0 बनाम 5.0 व्यवहारिक अंतर रिपोर्ट है।

@GrabYourPitchforks क्या आप अपने ट्विटर उत्तरों पर https://docs.microsoft.com/en-us/dotnet/standard/globalization-localization/globalization-icu लिंक साझा कर सकते हैं और उल्लेख कर सकते हैं कि हमारे पास पुराने व्यवहार पर वापस जाने के लिए एक config स्विच है?

मुझे ट्विटर पर स्पष्टीकरण मिला। एप्लिकेशन एक लूप में IndexOf को कॉल नहीं कर रहा है। यह सिर्फ एक मानक 3.0 बनाम 5.0 व्यवहारिक अंतर रिपोर्ट है।

धन्यवाद, @GrabYourPitchforks ... इस पर आधारित, इसे डिज़ाइन के अनुसार बंद करना।

यहां अधिक जोड़ने के लिए, यदि आप एनएलएस पर वापस जाने के बिना पुराने व्यवहार को प्राप्त करना चाहते हैं, तो आप कर सकते हैं

`` `सी #
CultureInfo.CurrentCulture.CompareInfo.IndexOf (वास्तविक, अपेक्षित, तुलनाएं ।gnoreSymbols)

or 

```C#
    actual.IndexOf(expected, StringComparison.Ordinal)

के बजाय

C# actual.IndexOf(expected)

और आपको वांछित व्यवहार मिलना चाहिए।

मैं लिंक्ड ICU से संबंधित प्रलेखन (https://docs.microsoft.com/en-us/dotnet/standard/globalization-localization/) में \r\n vs \n बारे में कुछ भी नहीं देख सकता भूमंडलीकरण-आईसीयू)।

क्या यह वास्तव में एक नियोजित परिवर्तन था?

@ForNeVeR आईसीयू और एनएलएस के बीच हर एक अंतर को सूचीबद्ध करना कठिन होगा। दस्तावेज़ ICU में स्विच करने के मुख्य परिवर्तन के बारे में बात कर रहा है। जैसा कि मैंने पहले पहले इशारा किया, इसके बारे में परिणामों की तुलना करना ठीक नहीं है Contains के साथ IndexOf StringComparison पैरामीटर के बिना। यदि आप चाहें तो मैं पिछले व्यवहार को प्राप्त करने के कुछ तरीकों से ऊपर सूचीबद्ध कर सकता हूं। इस मुद्दे की रिपोर्ट से, यह मुझे लगता है कि IndexOf के उपयोग को साधारण विकल्प का उपयोग करना चाहिए और ऐसे मामले में भाषाई तुलना का उपयोग करना गलत है। ऐसे मामले में भाषाई तुलना का उपयोग करना वर्तमान संस्कृति पर निर्भर कर सकता है जो विभिन्न वातावरणों पर अलग-अलग परिणाम देना संभव है।

क्या यह वास्तव में एक नियोजित परिवर्तन था?

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

जैसा कि दस्तावेज़ ने संकेत दिया है, आपके पास अभी भी पुराने व्यवहार पर वापस जाने का विकल्प है यदि आप चाहते हैं।

आउच, संदर्भित डॉक्टर का कहना है कि विंडोज पर आईसीयू / एनएलएस व्यवहार चुपचाप वास्तविक वातावरण में icu.dll उपलब्धता के आधार पर बदल सकता है। यह प्रकाशित स्व-निहित ऐप्स के लिए एक बड़ा आश्चर्य हो सकता है। यदि स्विच पर निर्णय लिया गया था, और सभी लक्ष्य वातावरणों पर ICU उपलब्ध नहीं है, तो मैं .NET को इस समस्या के समाधान के लिए शिप करने की अपेक्षा करूँगा। यह वैकल्पिक रनटाइम निर्भरता चीजों को मजेदार भी बनाती है।

यदि स्विच पर निर्णय लिया गया था, और सभी लक्ष्य वातावरणों पर ICU उपलब्ध नहीं है, तो मैं .NET को इस समस्या के समाधान के लिए शिप करने की अपेक्षा करूँगा। यह वैकल्पिक रनटाइम निर्भरता चीजों को मजेदार भी बनाती है।

ICU को अब NuGet पैकेज के रूप में प्रकाशित किया गया है। एप्लिकेशन ऐसे पैकेज का उपयोग कर सकते हैं जिसमें आईसीयू होने के लिए आत्म निहित ऐप सुनिश्चित हो। डॉक्स में ऐप-लोकल सेक्शन को देखें । संक्षेप में, ऐप उस व्यवहार पर पूर्ण नियंत्रण रखता है जिसे प्राप्त करना चाहते हैं।

@tarekgh , मैं मानता हूं कि Contains और IndexOf बीच के विभिन्न परिणाम इस समस्या के प्रति नहीं हैं।

समस्या स्पष्ट रूप से IndexOf जो कि एक ASCII- केवल स्ट्रिंग के अंदर एक ASCII- केवल स्ट्रिंग को खोजने में असमर्थ है (मुझे यकीन नहीं है कि ASCII- केवल तार पर लगाया गया कोई भी स्थानीय-निर्भर व्यवहार था!)।

यह ऐसा कुछ नहीं है जिसकी मैं किसी भी स्थानीय / एनएलएस / आईसीयू-संबंधी परिवर्तनों से अपेक्षा करूँगा; वास्तव में, मैं किसी भी अन्य प्रोग्रामिंग भाषा / रनटाइम के बारे में ऐसा नहीं सोच सकता था।

यहाँ एक सरल परीक्षण मामला है, टूटा हुआ है (मेरा मतलब है, मुझे .NET 5 RC 2 पर पूरी तरह से अप्रत्याशित परिणाम दे रहा है):

var actual = "\n\r\nTest";
var expected = "\nTest";

Console.WriteLine($"actual.IndexOf(expected): {actual.IndexOf(expected)}"); // => -1

क्या वास्तव में ऐसा काम करना चाहिए? भी, क्यों? यह वास्तव में क्या करने की कोशिश कर रहा है?

क्या यह वास्तव में एक नियोजित परिवर्तन था?

हां ICU में स्विच करना अलग-अलग कारणों से जानबूझकर किया गया बदलाव है।

मुझे खेद है, लेकिन मुझे विश्वास नहीं है कि यह एक नियोजित परिवर्तन था, इसलिए मैं इस बात पर जोर देना चाहता हूं: मैं किसी को भी इस तरह के बदलाव की कल्पना नहीं कर सकता था। जैसे, .NET टीम के लोग एक साथ बैठे और चर्चा की:

क्या स्ट्रिंग "\ n \ r \ nTest" में ICU सक्षम के साथ "\ nTest" है? नहीं, स्पष्ट रूप से नहीं!

और किसी ने शिकायत नहीं की? कोई मौका नहीं!

यह एक नियोजित या अपेक्षित बदलाव की तरह नहीं दिखता है, और इसके बजाय बहुत गंभीर बग, एक बड़ी संगतता अवरोधक की तरह दिखता है। उसके कारण, नए और पोर्ट किए गए .NET एप्लिकेशन नए रनटाइम पर ठीक से काम नहीं करेंगे, क्योंकि वे स्ट्रिंग के अंदर सबस्ट्रिंग नहीं ढूंढ पाएंगे!

आईसीयू वैसे भी लाइन एंडिंग की परवाह क्यों करता है? क्या कुछ स्थानों की अपनी स्थानीय-विशिष्ट लाइन अंत है?

PS हाँ, आप तर्क दे सकते हैं कि किसी को हमेशा संस्कृति-स्वतंत्र IndexOf कुछ प्रकारों को कॉल करना चाहिए, जैसे कि ऑर्डिनल ध्वज। लेकिन, अगर आपने इसे .NET 5 में इसे _that_ कठिन रूप से तोड़ने का फैसला किया है,

इसके अलावा, मुझे लगता है कि हम सभी समझते हैं कि, IndexOf हमेशा एक संस्कृति-विशिष्ट तरीके से व्यवहार करने के बावजूद, वाइल्ड में कोड के _tons_ हैं जो बिना किसी झंडे के IndexOf का उपयोग करते हैं, और वह कोड _use to work_ (कुछ / अधिकांश मामलों में, कम से कम)। और यह .NET 5 अपडेट के बाद काम करना बंद कर देगा।

समस्या स्पष्ट रूप से IndexOf है जो एक ASCII- केवल स्ट्रिंग के अंदर एक ASCII- केवल स्ट्रिंग को खोजने में असमर्थ है (मुझे यकीन नहीं है कि ASCII- केवल स्ट्रिंग्स पर लगाया गया कोई भी स्थानीय-निर्भर व्यवहार था!)।

यह सही नहीं है कि ASCII स्थानीय-स्वतंत्र है। लिंक पर देखें http://userguide.icu-project.org/collation/congets एक उदाहरण के रूप में कि कैसे ASCII वर्णों का व्यवहार विभिन्न संस्कृतियों के लिए भिन्न हो सकता है।

For example, in the traditional Spanish sorting order, "ch" is considered a single letter. All words that begin with "ch" sort after all other words beginning with "c", but before words starting with "d".
Other examples of contractions are "ch" in Czech, which sorts after "h", and "lj" and "nj" in Croatian and Latin Serbian, which sort after "l" and "n" respectively.

इसके अलावा, मैं यह स्पष्ट करना चाहता हूं कि ICU अपने डेटा और व्यवहार को यूनिकोड मानक से चुनता है जो कई विशेषज्ञों द्वारा अच्छी तरह से सोचा जाता है। @GrabYourPitchforks \r\n\ मामले के बारे में अधिक विवरण पोस्ट करने जा रहा है जिसके बारे में हम यहां बात कर रहे हैं। लेकिन इस बीच, आप अपने आप को डॉक के साथ परिचित हो सकता है https://unicode.org/reports/tr29/ विशेष रूप से वर्गों निम्नलिखित उल्लेख में:

Do not break between a CR and LF. Otherwise, break before and after controls.
--
GB3 | CR | × | LF
GB4 | (Control \| CR \| LF) | ÷ |  
GB5 |   | ÷ | (Control \| CR \| LF)

आईसीयू वैसे भी लाइन एंडिंग की परवाह क्यों करता है? क्या कुछ स्थानों की अपनी स्थानीय-विशिष्ट लाइन अंत है?

इसे अंतिम पैराग्राफ में संबोधित किया गया है।

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

यह अच्छी तरह से नियोजित काम है और इसमें गहराई से सोचा गया है। आप इस मुद्दे को देख सकते हैं https://github.com/dotnet/runtime/issues/826 जिसे हमने बहुत पहले प्रकाशित किया था और सार्वजनिक रूप से साझा किया था।
मैं यह भी जोर देना चाहता हूं कि वैश्वीकरण व्यवहार कभी भी न केवल .NET के लिए, बल्कि ओएस के और अन्य प्लेटफार्मों के लिए बदल सकता है। यह इसलिए भी है कि हमने ICU ऐप-स्थानीय सुविधा का समर्थन किया, ताकि वे यह सुनिश्चित कर सकें कि वे जिस व्यवहार का उपयोग करने जा रहे हैं, वह विशिष्ट ICU संस्करण का उपयोग करने वाला नहीं है। एक और बात, विंडोज़ स्वयं ICU के उपयोग को बढ़ावा देने की प्रक्रिया में है और एक दिन ICU व्यवहार वह होगा जो अधिकांश उपयोगकर्ता उपयोग करने जा रहे हैं।

ऑर्डिनल फ्लैग के साथ की तरह। लेकिन, अगर आपने इसे .NET 5 में कठिन रूप से तोड़ने का फैसला किया है, तो क्या आप इसे अभी भी सामान्य, सामान्य डिफ़ॉल्ट का उपयोग करने के लिए नहीं बना सकते हैं? मुझे लगता है कि यह .NET 5 RC 2 में वर्तमान परिवर्तन की तुलना में कम अनुप्रयोगों को तोड़ देगा।

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

इसके अलावा, मुझे लगता है कि हम सभी समझते हैं कि, IndexOf हमेशा एक संस्कृति-विशिष्ट तरीके से व्यवहार करने के बावजूद, वहाँ जंगली में कोड के टन होते हैं जो क्रमिक झंडे के बिना IndexOf का उपयोग करते हैं, और वह कोड काम करता था (कुछ / अधिकांश मामलों में,) कम से कम)। और यह .NET 5 अपडेट के बाद काम करना बंद कर देगा।

इसीलिए अगर आप चाहें तो हम पुराने व्यवहार को बदलने के लिए एक कॉन्फ़िगर स्विच प्रदान कर रहे हैं। System.Globalization.UseNls को देखें

@tarekgh , पूरी तरह से स्पष्टीकरण के लिए धन्यवाद!

अभी के लिए, मुझे लगता है कि इस विशेष \r\n व्यवहार के विवरण की प्रतीक्षा करना मेरे लिए बेहतर है। यह मेरे लिए स्पष्ट नहीं है कि इस विशेष खोज को करते समय IndexOf का उपयोग "Grapheme क्लस्टर सीमा नियम" (और क्या यह ऐसा करना चाहिए)।

इसके अलावा, भले ही यहां यूनिकोड युक्ति प्रासंगिक हो (जो कि बहुत अच्छी तरह से हो सकता है!), Https://unicode.org/reports/tr29/ पढ़ने से, मुझे यकीन नहीं है कि यह पिछले \n से मेल खाने से मना करता है CR | × | LF कहता है, जहाँ × अर्थ है "कोई सीमा नहीं (यहाँ तोड़ने की अनुमति न दें")। इसलिए, जब एक क्रम \r\n\n तोड़ते हैं, तो यह केवल पहले और दूसरे पात्रों के बीच "ब्रेक" लगाने के लिए मना करता है, लेकिन "ब्रेक" को तीसरे एक से पहले रखने के लिए ठीक होना चाहिए, नहीं? इसलिए, मैंने \r\n\n को दो अलग-अलग "ग्रैपहेम क्लस्टर्स" के रूप में पढ़ा है, और, भले ही IndexOf को केवल पूर्ण ग्रेप समूहों से मेल खाना हो और कभी भी क्लस्टर्स के कुछ हिस्सों को स्पर्श न करना हो, फिर भी इसे \nTest देना चाहिए। \n\r\nTest ।

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

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

_ (एक आवश्यक अस्वीकरण : मैं JetBrains के लिए ReSharper सहित कई परियोजनाओं पर काम करता हूं।) _

मैं शुरू में इस बिंदु को एक विज्ञापन की तरह नहीं सुनाना चाहता था, लेकिन मुझे लगता है कि यह बहुत प्रासंगिक है, इसलिए मुझे यह करना होगा। डिफ़ॉल्ट रूप से ReSharper IndexOf कॉल करने वाले उपयोगकर्ता कोड के लिए निम्नलिखित चेतावनी दिखाएगा:

_ (कृपया ध्यान दें कि मुझे इस थ्रेड में शामिल होने से पहले इस विशेष रूप से ReSharper डायग्नोस्टिक के बारे में पता नहीं था, इसलिए मैं इस तर्क को लाने के लिए यहां भाग नहीं ले रहा हूं) _

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

@कभी नहीं

साथ ही, भले ही यूनिकोड युक्ति यहां प्रासंगिक हो (जो बहुत अच्छी तरह से हो सकता है!), Unicode.org/reports/tr29 को पढ़ने से, मुझे यकीन नहीं है कि यह अंतिम \ n से मेल खाने के लिए मना करता है। जैसा कि मैंने युक्ति पढ़ी है, यह कहता है कि CR | × | LF, जहां × का अर्थ है "कोई सीमा नहीं (यहां ब्रेक की अनुमति न दें)"। इसलिए, जब एक अनुक्रम \ r \ n \ n को तोड़ते हैं, तो यह केवल पहले और दूसरे पात्रों के बीच "ब्रेक" लगाने के लिए मना करता है, लेकिन तीसरे ब्रेक से पहले "ब्रेक" लगाने के लिए ठीक होना चाहिए, नहीं? इसलिए, मैंने दो अलग-अलग "ग्रेफ़ेम क्लस्टर" के रूप में \ r \ n \ n पढ़ा

वह सही है। \r\n\n 2 \r\n और \n रूप में 2 क्लस्टर होंगे।

और, भले ही IndexOf को केवल पूर्ण अंगूर समूहों से मेल खाना हो और कभी भी समूहों के हिस्सों को न छूएं, फिर भी इसे string \ n \ r \ nTest के अंदर substring \ nTest खोजना चाहिए।

यह गलत है। \n\r\nTest भागों में विभाजित हो जाएंगे। \n , \r\n , और Test । यह स्पष्ट है कि \nTest इस तार का हिस्सा नहीं हो सकते। क्लस्टर \r\n को कुछ प्रतीक X साथ बदलने के बारे में सोचें। अब स्रोत स्ट्रिंग \nXTest जिसमें \nTest ।

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

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

CultureInfo.CurrentCulture.CompareInfo.IndexOf(actual, expected, CompareOptions.IgnoreSymbols)

ताकत के स्तर को बदल देगा और ऑपरेशन को प्रतीकों की उपेक्षा करेगा (जो \n और \r के व्यवहार को बदल देगा क्योंकि इसे उस समय अनदेखा किया जाएगा)

इसके अलावा, मैंने शुद्ध आईसीयू देशी सी ऐप लिखा है और उसी मामले को चलाया है:

void SearchString(const char *target, int32_t targetLength, const char *source, int32_t sourceLength)
{
    static UChar usource[100];
    static UChar utarget[100];

    u_charsToUChars(source, usource, sourceLength);
    u_charsToUChars(target, utarget, targetLength);

    UErrorCode status = U_ZERO_ERROR;
    UStringSearch* pSearcher = usearch_open(utarget, targetLength, usource, sourceLength, "en_US", nullptr, &status);
    if (!U_SUCCESS(status))
    {
        printf("usearch_open failed with %d\n", status);
        return;
    }

    int32_t index = usearch_next(pSearcher, &status);
    if (!U_SUCCESS(status))
    {
        printf("usearch_next failed with %d\n", status);
        return;
    }

    printf("search result = %d\n", index);
    usearch_close(pSearcher);
}


int main()
{
    SearchString("\nT", 2, "\r\nT", 3);
    SearchString("\nT", 2, "\n\nT", 3);
}

इस एप्लिकेशन के परिणाम का उत्पादन होगा:

search result = -1
search result = 1

जो .NET के साथ आपके द्वारा देखे जा रहे व्यवहार के समान है।

अभी के लिए, मुझे लगता है कि मेरे लिए इस विशेष \ n व्यवहार पर विवरणों की प्रतीक्षा करना बेहतर है। यह मेरे लिए स्पष्ट नहीं है कि कैसे IndexOf इस विशेष खोज को करते समय "ग्रैफेम क्लस्टर बाउंडरी रूल्स" (और क्या इसे ऐसा करना चाहिए) का उपयोग करता है।

सुनिश्चित करने के लिए क्लस्टरिंग ऑपरेशन को प्रभावित कर रहा है। यदि आप http://unicode.org/reports/tr29/tr29-7.html को देखते हैं , तो यह स्पष्ट रूप से निम्नलिखित बताता है:

Grapheme clusters include, but are not limited to, combining character sequences such as (g + °), digraphs such as Slovak “ch”, and sequences with letter modifiers such as kw. Grapheme क्लस्टर सीमाएं , regular-expressions, and counting “character” positions within text. Word boundaries, line boundaries and sentence boundaries do not occur within a grapheme cluster. In this section, the Unicode Standard provides a determination of where the default grapheme boundaries fall in a string of characters. This algorithm can be tailored for specific locales or other customizations, which is what is done in providing contracting characters in collation tailoring tables. कॉलेशन के लिए महत्वपूर्ण हैं

मुझे यकीन नहीं है कि अधिक विवरण होंगे लेकिन मैं @GrabYourPitchforks को टिप्पणी

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

धन्यवाद!
यही दिशा हम भी सोच रहे हैं।

अपने स्वयं के लिए, मैंने संस्करणों के बीच विभिन्न अधिभार की तुलना की:

| विधि | netcoreapp3.1 | net5.0 |
| ------------------------------------------------- --------------- | ----------------- | ---------- |
| actual.Contains(expected) | सच | सच |
| actual.IndexOf(expected) | 1475 | -1 |
| actual.Contains(expected, StringComparison.CurrentCulture) | सच | झूठा |
| actual.IndexOf(expected, StringComparison.CurrentCulture) | 1475 | -1 |
| actual.Contains(expected, StringComparison.Ordinal) | सच | सच |
| actual.IndexOf(expected, StringComparison.Ordinal) | 1475 | 1475 |
| actual.Contains(expected, StringComparison.InvariantCulture) | सच | झूठा |
| actual.IndexOf(expected, StringComparison.InvariantCulture) | 1475 | -1 |

कृपया इसके लिए एक विश्लेषक शामिल करें।

ऐसा लगता है कि उन परिवर्तनों में से एक है, जो लंबे समय में अच्छा है, जबकि .NET 5 लॉन्च होने के बाद बड़े पैमाने पर मंथन होता है। यदि इन विधियों का व्यवहार .NET 5 और .NET कोर 3.1 के बीच भिन्न होता है, तो क्या होने वाला है। .NET 5 एक मानक .NET 2.0 लाइब्रेरी के अंदर परिभाषित एक वस्तु को कॉल करता है, जो string में हेरफेर करता है। .NET कॉलाइट से? क्या पुराने व्यवहार का इस्तेमाल होता है या नए व्यवहार का?

@Aaronontheweb नया व्यवहार। मैंने इसे शुरू में NUnit3 में एक जोर से देखा, जो netstandard2.0 लक्ष्य रखता है। उन्नयन के बाद, मेरा परीक्षण विफल हो गया जब मैंने केवल लक्ष्य रूपरेखा को बदल दिया।

यह बहुत अच्छा नहीं है - अगर मैं अपग्रेड करना चाहता हूं तो मैं जो पुराने पुस्तकालय देख रहा हूं, उन्हें नियंत्रित नहीं कर सकता।

कितने ऐप यूनिट परीक्षणों में इसका पता नहीं लगा पाएंगे और उत्पादन में डाल देंगे?
क्या .NET टीम ने दर्द और समस्याओं पर विचार किया और इसकी वजह क्या हो सकती है?

यह बहुत अच्छा नहीं है - अगर मैं अपग्रेड करना चाहता हूं तो मैं जो पुराने पुस्तकालय देख रहा हूं, उन्हें नियंत्रित नहीं कर सकता।

अच्छा जाल!
अजीब कीड़े शिकार करके खुश समय बर्बाद hunting
लेकिन क्यों InvariantGlobalization इस समस्या के साथ मदद नहीं करता है?

कृपया इसके लिए एक विश्लेषक शामिल करें।

हाँ। और एफ # समर्थन मत भूलना।

कितने ऐप यूनिट टेस्ट में इसका पता नहीं लगा पाएंगे

शून्य - चूंकि यूनिट परीक्षण केवल .NET BCL की तरह बाहरी परिवादों / रूपरेखाओं का परीक्षण करने के लिए नहीं हैं।

मेरा विचार है कि एक विधानसभा स्तर की विशेषता होनी चाहिए जो इस व्यवहार परिवर्तन के तरीके को नियंत्रित कर सके। कम से कम तब, आप इसे प्रति-विधानसभा स्तर पर ऑप्ट-इन / आउट कर सकते हैं। इसका अर्थ है कि .NET मानक समस्या दूर हो गई है।

यह बहुत अच्छा नहीं है - अगर मैं अपग्रेड करना चाहता हूं तो मैं जो पुराने पुस्तकालय देख रहा हूं, उन्हें नियंत्रित नहीं कर सकता।

मैं यह नहीं देखता कि आप इसे नियंत्रित क्यों नहीं कर सकते। सभी स्ट्रिंग तुलना या तो आईसीयू या एनएलएस का उपयोग कर रहे हैं। यदि आप चाहें, तो आप हमवतन स्विच का उपयोग कर आईसीयू से बाहर निकल सकते हैं और आपकी सभी लाइब्रेरी पुराने व्यवहार पर वापस लौट आएगी।

आप समय के साथ स्थिर रहकर वैश्वीकरण के आंकड़ों पर भरोसा नहीं कर सकते। विंडोज टीम से लें कि वे उन लोगों को तोड़ने से डरते नहीं हैं जो स्थिर वैश्वीकरण डेटा पर निर्भर हैं। वैश्वीकरण कार्य एक ब्लैक बॉक्स होना चाहिए; मुझे नहीं लगता कि यह पुस्तकालयों के लिए समझ में आता है (विशेषकर जो .NET मानक को लक्षित करते हैं) यह कहने के लिए कि वे इस तरह कार्यान्वयन विवरणों पर निर्भर हैं।

मुझे यकीन है कि जैसे ही कई लोगों ने विंडोज बनाम लिनक्स पर अलग-अलग परिणाम देने वाले .NET वैश्वीकरण कार्यों के बारे में शिकायत की है (और शायद और भी लोगों ने अभी तक ऐसा नहीं किया है)। विंडोज और अन्य प्लेटफार्मों के बीच व्यवहार को एकजुट करना बेहतर है, और किसी भी सही कोड को वैश्वीकरण के आंकड़ों पर भरोसा नहीं करना चाहिए, भले ही।

क्या आप StringComparison.Ordinal की डिफ़ॉल्ट तुलना की रणनीति बनाने के लिए ब्रेकिंग परिवर्तन करने पर भी विचार करेंगे? वैश्वीकरण के रूप में देखना इतना अस्थिर है, यह समझ में आता है कि कम से कम डिफ़ॉल्ट कार्यान्वयन इसके बजाय एक स्थिर एल्गोरिथ्म का उपयोग करता है। मैं यह शर्त लगाने को तैयार हूं कि 99.9% लोग, जो string.Equals(...) या string.Contains(...) आदि का उपयोग किए बिना StringComparison कर रहे हैं, यह अजीब quirks से निपटने के स्पष्ट इरादे से नहीं कर रहे हैं स्थानों।

संपादित करें: मुझे लगता है कि मेरे सवाल का जवाब पहले ही दिया जा चुका है:

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

यदि आप चाहें, तो आप कम्‍प्‍यूटर स्विच का उपयोग कर ICU से बाहर निकल सकते हैं और आपकी सभी लाइब्रेरी पुराने व्‍यवहार पर वापस लौट आएगी।

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

हमारे द्वारा किए गए अधिकांश कार्य InvariantCulture , जो मेरी पिछली समझ के अनुसार डिजाइन द्वारा अपरिवर्तनीय माना जाता है। ऐसा लगता है कि IndexOf का व्यवहार .NET 5.0 और .NET कोर 3.1 के बीच उन परिस्थितियों में भी भिन्न है।

मौजूदा परियोजनाओं के लिए कोई भी विश्लेषक कैसे मदद कर सकता है?

@petarrepac यह भी एक C #

@ आईसाकाबरा और वीबी भी;)

मैं इसे संभालने का एक संकलन समय देना पसंद करूंगा।

@Aaronontheweb आपके पास इसे संभालने का एक कंपाइल-टाइम तरीका है (जब ऐप्स को

<ItemGroup>
  <RuntimeHostConfigurationOption Include="System.Globalization.UseNls" Value="true" />
</ItemGroup>

EDIT: यह केवल लाइब्रेरी का उपभोग करने वाले ऐप्स के लिए है, दुर्भाग्य से आप लाइब्रेरी लिखते समय इसे नियंत्रित नहीं कर सकते।

लंबे समय में विंडोज टीम ICU में जाने के लिए प्रचार कर रही है, इसलिए कुछ बिंदु पर ICU वैश्वीकरण की कहानी होगी, और हम OS पुस्तकालयों के चारों ओर एक पतली आवरण हैं।

जब .NET .NET मानक 2.0 लाइब्रेरी के अंदर परिभाषित एक वस्तु को कॉल करता है तो क्या होने वाला है? क्या पुराने व्यवहार का इस्तेमाल होता है या नए व्यवहार का?

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

@reflectronic अपने सभी बिंदुओं में सही है https://github.com/dotnet/runtime/issues/43736#issuecomment -716681586।

यहां बताए गए @jbogard परिणामों पर टिप्पणी करने के लिए https://github.com/dotnet/runtime/issues/43736#issuecomment -716527590, आप Windows और ICU के बीच भाषाई व्यवहार के बीच तुलना करके परिणामों को संक्षेप में प्रस्तुत कर सकते हैं। वैसे, ICU अब विंडोज पर कई अनुप्रयोगों द्वारा उपयोग किया जाता है और यह उपयोग बढ़ने की उम्मीद है। इसके अलावा, ये परिणाम .NET कोर 3.1 और नीचे के साथ लिनक्स को बाहर कर रहे हैं। जो लिनक्स पर .NET 5.0 और पिछले संस्करणों के बीच स्थिरता दिखाएगा।

लाइब्रेरी के बारे में जो बिंदु काम करता था, वह टूट जाएगा, यह पूरी तरह सच नहीं है क्योंकि इस तरह के पुस्तकालय लिनक्स पर पहले से ही टूटे हुए थे।

क्या आप StringComparison.Ordinal को डिफ़ॉल्ट तुलना रणनीति बनाने के लिए एक ब्रेकिंग परिवर्तन करने पर भी विचार करेंगे?

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

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

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

मौजूदा परियोजनाओं के लिए कोई भी विश्लेषक कैसे मदद कर सकता है?

एनालाइज़र कोड को स्कैन करते हैं और टकराव एपीआई की कॉल का पता लगाते हैं जो झंडे पास नहीं करते हैं, ऐसे कॉल को देखने और पता लगाने में मदद करेंगे यदि समस्या का पता चला है।

यह भी एक # सी बात है।

परिवर्तन .NET रनटाइम के अंदर है जो वैश्विक होना चाहिए और सी # तक सीमित नहीं होना चाहिए।

@tarekgh एक C # विश्लेषक खुद को VB या F # कोडबेस में कैसे प्रकट करता है?

हमारे द्वारा किए गए अधिकांश कार्य InvariantCulture , जो मेरी पिछली समझ के अनुसार डिजाइन द्वारा अपरिवर्तनीय माना जाता है।

गंभीर रूप से, इस परिवर्तन से पहले, क्रॉस-प्लेटफ़ॉर्म कोड के लिए वास्तव में इस पर निर्भर होना असंभव था; एनएलएस और आईसीयू क्या व्यवहार करते हैं, यहां तक ​​कि जब अपरिवर्तनीय संस्कृति का उपयोग करते हैं, तो हमेशा समान नहीं होते हैं (जैसा कि इस मुद्दे से स्पष्ट है)। जैसे @tarekgh ने कहा, यह कोड इस पूरे समय लिनक्स पर अलग तरह से काम कर रहा है। अब जब यह परिवर्तन किया गया है, किसी भी अप-टू-डेट विंडोज इंस्टाल के लिए, "इनवेरिएंट कल्चर" का क्या मतलब है कि _actually_ सभी प्लेटफार्मों पर संगत होना चाहिए।

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

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

संपादित करें: जैसे, मुझे पहले से ही तकनीकी योग्यता प्राप्त है - हां, धन्यवाद। कृपया इस बदलाव को लागत के विपरीत होने के गैर-स्पष्ट आर्थिक लाभों को बेचने में मदद करें। उपयोगकर्ताओं को क्यों ले जाना चाहिए। .NET 5 पर अपग्रेड करना चाहिए वैसे भी यह देखते हुए कि इस मुद्दे पर एक चूहे का घोंसला क्या है?

@tarekgh एक C # विश्लेषक खुद को VB या F # कोडबेस में कैसे प्रकट करता है?

हम एक एकल विश्लेषक के साथ C # और VB को कवर कर सकते हैं (हम जहां भी संभव हो, हमारे विश्लेषक भाषा-अज्ञेय बनाने का प्रयास करते हैं), लेकिन हम इस समय F # के लिए विश्लेषक कवरेज प्राप्त नहीं कर सकते हैं।

@Aaronontheweb किसी https://docs.microsoft.com/en-us/archive/blogs/shawnste/locale-culture-data-churn देखें जो बता रहे हैं कि एनएलएस का व्यवहार भी सुधार के लिए बदल रहा है। इसलिए, यहां मुद्दा केवल ICU में जाने से ज्यादा नहीं है, बल्कि यह एप्स / लाइब्रेरी के नजरिए से किसी भी गलत धारणा को पकड़ सकता है। 5.0 पर अपग्रेड करना अन्य पिछले संस्करणों में अपग्रेड करने के समान है। ऐप्स को बहुत सारे नए अच्छे फ़ीचर्स मिलेंगे और ऐप को टेस्ट करने की ज़रूरत है क्योंकि रिलीज़ के बीच कुछ ब्रेकिंग बदलाव हो सकते हैं। मैं वैश्वीकरण व्यवहार परिवर्तन पर विचार नहीं कर रहा हूं, वास्तव में यह टूट रहा है क्योंकि हम हमेशा बता रहे हैं कि वैश्वीकरण ओएस और ओएस संस्करणों के बीच कभी भी बदल सकता है। जैसा कि पहले संकेत दिया गया है, हमारे पास एनएलएस का उपयोग करने के साथ 5.0 में अपग्रेड करने के लिए चुनने के लिए कॉन्फ़िगर स्विच है। कि आईसीयू वास्तव में उन्नयन निर्णय में एक कारक नहीं होगा। अब ICU के साथ, ऐप्स के पास OS के पार अधिक संगति प्राप्त करने का अवसर होगा और यहां तक ​​कि ऐप-स्थानीय ICU का उपयोग करने का निर्णय लेने पर वैश्वीकरण व्यवहार पर अधिक नियंत्रण हो सकता है। हम पहले की तुलना में ऐप्स को बहुत अधिक नियंत्रण प्रदान कर रहे हैं।

संबंधित: https://github.com/dotnet/runtime/issues/43802

(यह मुद्दा IndexOf _per se_ को ट्रैक नहीं करता है। बल्कि, यह संस्कृति-जागरूक तुलना करने वाले के लिए Compare रूटीन के अनपेक्षित परिणामों पर चर्चा करता है।)

मौजूदा परियोजनाओं के लिए कोई भी विश्लेषक कैसे मदद कर सकता है?

एनालाइज़र कोड को स्कैन करते हैं और टकराव एपीआई की कॉल का पता लगाते हैं जो झंडे पास नहीं करते हैं, ऐसे कॉल को देखने और पता लगाने में मदद करेंगे यदि समस्या का पता चला है।

मुझे लगता है कि विश्लेषण करने वालों को csproj में जोड़ा जाना चाहिए।
यह अपने आप नहीं होगा। इसलिए, बहुत सारे मौजूदा प्रोजेक्ट उन एनालाइज़र के बिना .NET 5 में चले जाएंगे।
इसके अलावा, जैसा कि पहले ही उल्लेख किया गया है, यह एफ # परियोजनाओं के लिए मदद नहीं करेगा।

@ जेफहंडली धन्यवाद, जो इस बात की पुष्टि करता है कि मैं पहले से ही क्या समझ रहा हूं। इसलिए, यह स्वीकार करना महत्वपूर्ण है कि संभव "वर्कअराउंड" F # उपयोगकर्ताओं (एक छोटा बाजार लेकिन एक ऐसा व्यक्ति जो पूरी तरह से MS द्वारा .NET के प्रथम श्रेणी के नागरिक के रूप में समर्थित है) में मदद नहीं करेगा। मुझे इसका मतलब नहीं मालूम है:

परिवर्तन .NET रनटाइम के अंदर है जो वैश्विक होना चाहिए और सी # तक सीमित नहीं होना चाहिए।

मुझे इसका मतलब नहीं मालूम है:
परिवर्तन .NET रनटाइम के अंदर है जो वैश्विक होना चाहिए और सी # तक सीमित नहीं होना चाहिए।

मेरा मतलब था कि .NET रनटाइम का उपयोग करने वाली कोई भी भाषा प्रभावित होगी और न केवल C #।

मैं फिर से अपनी राय को जोरदार तरीके से कहने जा रहा हूं कि बॉक्स से बाहर नई दुनिया में इन गोचरों को उजागर करने के लिए एक विश्लेषक होना चाहिए, खासकर अगर योजना को वर्तमान व्यवहार को बदलना है।

मैं ऐसा करने की तकनीकी खूबियों को पूरी तरह से समझता हूं और यह सुझाव नहीं दे रहा हूं कि आप बदलाव न करें (ऐसा लगता है जैसे यह सही समय है)। न ही मैं यह कह रहा हूं कि यह पहले से ही सर्वोत्तम अभ्यास के रूप में प्रलेखित नहीं था। मैं यह कह रहा हूं कि हमें वास्तव में .NET के लिए उठने का प्रयास करने वाले डेवलपर्स के लिए एक बड़ी, लाल, चमकती त्रुटि होने की आवश्यकता है। बॉक्स से बाहर डेवलपर्स यह "बस काम करता है" अन्यथा मानने जा रहे हैं।

अभी आप प्रभावित हुए क्षेत्रों को खोजने के लिए @meziantou से इस रोसलिन एनालाइज़र लाइब्रेरी का उपयोग कर सकते हैं: https://github.com/meziantou/Meziantou.Analyzer/tree/master/docs।

इस विशेष मामले में यह MA0074 फेंक

यह कहा जा रहा है कि यह वास्तव में बॉक्स से बाहर होने की जरूरत है, मैंने इस रोज़लिन मुद्दे को यहाँ खोला है: https://github.com/dotnet/roslyn-analyzers/issues/4367

@tarekgh स्पष्ट करने के लिए धन्यवाद। मेरा मूल बिंदु यह था कि यदि आप सभी .NET उपयोगकर्ताओं के लिए काम करने वाले समाधान की तलाश कर रहे हैं, तो analyzers यहां जवाब नहीं हैं।

हम इंडेक्सऑफ जैसी किसी चीज़ को कॉल करते समय डेवलपर्स को जागरूक होने में मदद करने के लिए और अधिक तरीके देख रहे हैं और इरादे को व्यक्त करने के लिए जानबूझकर StringComparison झंडे प्रदान करते हैं। हम किसी भी विचार का स्वागत करते हैं जो आप के साथ भी आ सकते हैं।

पुराने तरीकों को हटाने के बारे में कैसे ( [Obsolete] विशेषता का उपयोग करके)?

.NET मानक संगतता क्या होती है जब एपीआई सतह समान होती है लेकिन व्यवहार में परिवर्तन होता है?

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

कोई ऐसा व्यक्ति जो अनौपचारिक स्ट्रिंग मंजन कर रहा हो, वर्णों की अस्पष्टताओं के प्रति उदासीन हो, ग्रेफेम क्लस्टर, या लोकेल, इसे इस रूप में लेगा कि यदि str.Contains (जो भी) सफल होता है, तो str.ndexOf (जो भी हो) से परिणाम का निरीक्षण करने की कोई आवश्यकता नहीं है। ) क्योंकि हमें बताया गया था कि यह वहां है और इसलिए इसे पाया जा सकता है। इससे कोई फर्क नहीं पड़ता कि वे किस दूसरे पैरामीटर के बारे में जानने की परवाह नहीं करते हैं, वह डिफ़ॉल्ट है क्योंकि डिफॉल्ट करना सभी तरीकों में

इस तरह की विसंगतियां एक ऐसी भाषा का उत्पादन करती हैं जो केवल विशेषज्ञों द्वारा सफलतापूर्वक उपयोग की जा सकती हैं और कोड शिविर से बाहर आने वाले लोगों को अलग कर सकती हैं। इस तरह से प्रवेश करने के लिए बार न उठाएं।

मैं @lupestro से सहमत हूं। विधि व्यवहार में विसंगति बहुत विषय से संबंधित है। यदि आप लंबे समय तक चलने वाले तरीके हैं, तो दोनों अलग तरह से काम करते हैं और असंगत रूप से बहुत दुख होगा। लोग इसमें भाग लेंगे, वे एपीआई द्वारा धोखा महसूस करेंगे और फिर उन्हें आश्चर्य होगा कि अन्य टाइमबॉम्ब विस्फोट करने के लिए क्या इंतजार कर रहे हैं। बहुत से होंगे। .NET दत्तक ग्रहण इस तरह के मुद्दे पर C # बंद करेंगे। ऐसा लगता है कि आपको या तो ओवरलोड को हटाना चाहिए, जो लोकेल को स्वीकार नहीं करते हैं, या विधियों के लिए डिफ़ॉल्ट लोकेल को सामान्य नहीं करते हैं। पहले से ही एक तुलना और तुलनात्मक है, शायद (अंतिम) इंडेक्सऑफ (कोई भी) और (अंतिम) इंडेक्सऑफ (कोई भी) साधारण की जरूरत है। मुझे वह समाधान पसंद नहीं है लेकिन कम से कम यह वर्तमान में मौजूद चीज़ों के अनुरूप होगा। शायद स्ट्रिंग में क्रमिक उपयोग के विचार को ह्रास होना चाहिए। अगर मुझे हर बार तेज या सही में चयन करना है तो मैं 'सही' चुनूंगा। असंगत, गैर-सहज व्यवहार बेहद निराशाजनक हैं।

मुझे लगता है कि यह समस्या पहले से ही बंद है, इसलिए मुझे लगता है कि यह पहले से ही तय है कि यह .NET 5.0 में आगे बढ़ेगा। मुझे पता है कि यह सामान कठिन है और संस्कृति (समय की तरह) जानकारी सभी प्रकार के गैर-तकनीकी कारणों से बदल सकती है। डेवलपर्स को इसके बारे में पता होना चाहिए, लेकिन उन्हें आत्मनिर्भर होने के लिए अपने एपीआई पर निर्भर रहने की भी आवश्यकता है। कम से कम एक चेतावनी (5.0 में) होनी चाहिए जैसा कि

TLDR: उन चीजों को बदलें, जिन्हें बदलने की जरूरत है, लेकिन ऐसा करने के लिए एपीआई के असंगत नहीं हैं। यदि आप इसे तोड़ने जा रहे हैं तो इसे कुछ बेहतर तरीके से बदल दें।

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

यह यूनिकोड ग्रैफेम क्लस्टर व्यवहार मुझ पर एक नया है, जैसा कि मैंने लाइन फीड्स और कैरिज रिटर्न के लिए सामान्य व्यवहार की अपेक्षा की होगी, भले ही मैंने आमतौर पर इन्वैरेंट ओवरलोड का इस्तेमाल किया हो। मुझे ऐसा लगता है कि व्यवहार जो दोनों अधिक काम करता है और विशेषज्ञ ज्ञान की आवश्यकता है, तकनीकी व्यवहार की परवाह किए बिना, ऑप्ट-इन व्यवहार होना चाहिए। शायद वह जहाज बहुत पहले ही चला गया था, लेकिन _हिस ब्रेकिंग चेंज_ को पारदर्शी रूप से बनाया जाना चाहिए, उदाहरण के लिए, एक अस्पष्ट ब्लॉग को पढ़ने के बिना, भाषा में परिवर्तन। मेरे सहकर्मी नए सी # 9.0 सुविधाओं से बमुश्किल वाकिफ हैं, आइए कुछ आर्कन आइयू नियम को लागू करें जो कोड को आज लिख सकते हैं जो किसी दिन प्रभावित हो सकते हैं और .NET 5 (या अधिक संभावना, .NET 6 या 7) में संकलित हो सकते हैं।

पुराने तरीकों को ध्यान में रखते हुए एक बात हम पर विचार कर रहे हैं। मैंने कल रात प्रस्ताव का एक मसौदा तैयार किया और इसे आंतरिक समीक्षा के लिए चारों ओर खरीदारी कर रहा हूं, और मैं इसे कुछ घंटों में यहां एक नए मुद्दे के रूप में पोस्ट करूंगा।

प्रारूप https://github.com/dotnet/runtime/issues/43956 पर पोस्ट किया गया है

यदि आप बग की रिपोर्ट कर रहे हैं, तो कृपया एक नया मुद्दा दर्ज करें और बग का वर्णन करने के लिए उस नए मुद्दे का उपयोग करें।

यदि आपके पास इस विशेष मुद्दे ( "\r\n" बनाम "\n" ) पर टिप्पणियां हैं, तो कृपया इस धागे में जवाब दें। धन्यवाद!

जब हम @GrabYourPitchforks के दस्तावेज़ में वर्णित दृष्टिकोण पर विचार करते हुए फिर से

हम आपको सुनते हैं - यहाँ बहुत स्पष्ट प्रतिक्रिया है - हम आगे सही रास्ता निकालने के लिए काम कर रहे हैं, और हम इस मुद्दे को अद्यतन रखेंगे।

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

कोई ऐसा व्यक्ति जो अनौपचारिक स्ट्रिंग मंजन कर रहा हो, वर्णों की अस्पष्टताओं के प्रति उदासीन हो, ग्रेफेम क्लस्टर, या लोकेल, इसे इस रूप में लेगा कि यदि str.Contains (जो भी) सफल होता है, तो str.ndexOf (जो भी हो) से परिणाम का निरीक्षण करने की कोई आवश्यकता नहीं है। ) क्योंकि हमें बताया गया था कि यह वहां है और इसलिए इसे पाया जा सकता है। इससे कोई फर्क नहीं पड़ता है कि वे किस दूसरे पैरामीटर के बारे में जानने की परवाह नहीं करते हैं, डिफ़ॉल्ट है क्योंकि डिफ़ॉल्ट तरीके से _same का व्यवहार करना निश्चित है_, उन्हें उपयोग करने के लिए सभी सूक्ष्मताओं का अध्ययन करने की आवश्यकता से मुक्त करते हुए।

इस तरह की विसंगतियां एक ऐसी भाषा का उत्पादन करती हैं जो केवल विशेषज्ञों द्वारा सफलतापूर्वक उपयोग की जा सकती हैं और कोड शिविर से बाहर आने वाले लोगों को अलग कर सकती हैं। इस तरह से प्रवेश करने के लिए बार न उठाएं।

हां, इसने मेरी चिंताओं को पूरी तरह व्यक्त किया। एक विशिष्ट चीनी डेवलपर के रूप में, हम शायद ही कभी StringComparison या CultureInfo स्पष्ट रूप से हमारे एप्लिकेशन कोड में स्ट्रिंग संबंधित तरीकों को कॉल करते समय डालते हैं, और यह सिर्फ काम करता है। हम IndexOf और Contains बीच एक अलग व्यवहार की उम्मीद नहीं करते हैं!
.net 5.0

.net कोर 3.1

।शुद्ध रूपरेखा

मैं @lupestro से सहमत हूं। विधि व्यवहार में विसंगति बहुत विषय से संबंधित है। यदि आप लंबे समय तक चलने वाले तरीके हैं, तो दोनों अलग तरह से काम करते हैं और असंगत रूप से बहुत दुख होगा।

शायद यहाँ एक महत्वपूर्ण बिंदु यह है कि दो विधियाँ हमेशा असंगत रही हैं। वे अचानक .NET 5.0 में असंगत नहीं बने। अगर मैं चीजों का सही ढंग से पालन कर रहा हूं, तो IndexOf ने हमेशा वर्तमान संस्कृति तुलना का उपयोग किया है, Contains ने हमेशा व्यवस्थित तुलना का उपयोग किया है। दी गई .NET .NET में अधिक असंगति है। लेकिन यहां गलती मूल एपीआई डिजाइन में थी जिसने इस असंगति की अनुमति दी।

अगर मैं चीजों का सही तरीके से पालन कर रहा हूं, तो IndexOf ने हमेशा क्रमिक तुलना का उपयोग किया है, Contains ने हमेशा वर्तमान संस्कृति तुलना का उपयोग किया है। दी गई .NET .NET में अधिक असंगति है। लेकिन यहां गलती मूल एपीआई डिजाइन में थी जिसने इस असंगति की अनुमति दी।

यह सही है, लेकिन यह दूसरा तरीका है, IndexOf(string) वर्तमान संस्कृति का उपयोग करता है, IndexOf(char) साधारण उपयोग करता है और Contains क्रमिक उपयोग करता है।

मैं हाल ही में IndexOf बनाम Contains मतभेदों के बारे में विस्तार से बताऊंगा, जो अन्य लोगों ने हाल ही में कहा था।

IndexOf(string) ने हमेशा _CurrentCulture_ तुलना की है, और Contains(string) ने हमेशा _Ordinal_ तुलना की है। यह विसंगति .NET फ्रेमवर्क में वापस मौजूद है। यह .NET 5. में शुरू की गई एक नई विसंगति नहीं है। उदाहरण के लिए, .NET फ्रेमवर्क (जो विंडोज की एनएलएस सुविधा का उपयोग करता है) पर, लिगचर "æ" और दो-चार स्ट्रिंग "ऐ" की तुलना एक भाषाई तुलना के तहत बराबर है। यह निम्न विसंगति का परिणाम है:

// Sample on .NET Framework, showing Contains & IndexOf returning inconsistent results
Console.WriteLine("encyclopædia".Contains("ae")); // prints 'False'
Console.WriteLine("encyclopædie".IndexOf("ae")); // prints '8' (my machine is set to en-US)

यह विसंगति एक दशक से भी अधिक समय से मौजूद है। यह प्रलेखित है और इसके संबंध https://github.com/dotnet/runtime/issues/43956 पर चर्चा कर रहे हैं।

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

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

यहां तक ​​कि अगर InvariantCulture निर्दिष्ट किया गया है, तो क्या यह सही व्यवहार है कि \n ICU संस्करण में मेल नहीं खाता है?

हो सकता है, अगर हम git और उसकी डिफ़ॉल्ट सेटिंग्स (autocrlf = true) का उपयोग करते हैं, तो निम्न कोड लिनक्स पर 5 और विंडोज पर -1 प्रदर्शित करता है?

using System;

var s = @"hello
world";
Console.WriteLine(s.IndexOf("\n", StringComparison.InvariantCulture));

@ufcpp हां, आईसीयू के अनुसार, जो अपेक्षित व्यवहार है, जैसा कि इस धागे में पहले चर्चा की गई है। जब दोनों एक दूसरे से सटे होते हैं तो <CR><LF> को भाषाई उद्देश्यों के लिए एक अटूट इकाई माना जाता है। भाषाई तुलनित्र (जैसे _InvariantCulture_) का उपयोग करके <LF> खोज करने से कोई मेल नहीं बनेगा क्योंकि यह इस अटूट इकाई को विभाजित करेगा।

मैं सभी के साथ एक अपडेट साझा करना चाहता हूं: हमने 5.0 जीए के लिए आईसीयू को डिफ़ॉल्ट के रूप में रखने का फैसला किया है। हम जब क्रमिक उद्देश्य से भाषाई तुलना का उपयोग करते हुए गलती से गड्ढे में सुधार देखेंगे, तो यह https://github.com/dotnet/runtime/issues/43956 में ट्रैक किया गया है

यह बनाने के लिए एक बहुत कठिन निर्णय था और हमें प्लेटफॉर्म पर मानकीकरण के लिए ड्राइव के खिलाफ पारिस्थितिकी तंत्र के लिए अनुकूलता प्रभाव को तौलना था।

यदि हम यह निर्धारित करते हैं कि वर्तमान मितव्ययिता अपर्याप्त हैं, तो सर्विसिंग में \r\n समस्या के संबंध में विचार करने के लिए हम इस मुद्दे को खुला छोड़ देंगे।

मैं लोगों को आईसीयू स्विच के परिणामस्वरूप सामने आने वाले मुद्दों की रिपोर्ट करना जारी रखने के लिए प्रोत्साहित करना चाहूंगा, भले ही व्यवहार एक ज्ञात कारण हो सकता है, इसका मतलब यह नहीं है कि यह "डिजाइन द्वारा" है। हम मतभेदों की जांच करना और मूल कारण को समझना जारी रखेंगे और निर्धारित करेंगे कि क्या हमें उन्हें संबोधित करने के लिए ICU या .NET में परिवर्तन करने की आवश्यकता है।

StringComparison को हमेशा निर्दिष्ट करने के लिए एक विश्लेषक नियम है।

https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca1307

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

यह बनाने के लिए एक बहुत कठिन निर्णय था और हमें प्लेटफॉर्म पर मानकीकरण के लिए ड्राइव के खिलाफ पारिस्थितिकी तंत्र के लिए अनुकूलता प्रभाव को तौलना था।

यदि हम यह निर्धारित करते हैं कि वर्तमान मितव्ययिता अपर्याप्त हैं, तो सर्विसिंग में \r\n समस्या के संबंध में विचार करने के लिए हम इस मुद्दे को खुला छोड़ देंगे।

मैं लोगों को आईसीयू स्विच के परिणामस्वरूप सामने आने वाले मुद्दों की रिपोर्ट करना जारी रखने के लिए प्रोत्साहित करना चाहूंगा, भले ही व्यवहार एक ज्ञात कारण हो सकता है, इसका मतलब यह नहीं है कि यह "डिजाइन द्वारा" है। हम मतभेदों की जांच करना और मूल कारण को समझना जारी रखेंगे और निर्धारित करेंगे कि क्या हमें उन्हें संबोधित करने के लिए ICU या .NET में परिवर्तन करने की आवश्यकता है।

मैं जानना चाहूंगा कि क्या मैं अभी भी .NET मानक निर्भरता का उपयोग कर सकता हूं जिसका मेरे पास कोई नियंत्रण नहीं है।

मुझे शक है कि मैं नहीं कर पाऊंगा। यह सुनिश्चित करने के बारे में कि लोगों को संक्रमण कैसे होता है, मुझे नहीं पता। .NET मानक 2.2? एपीआई बदलें?

ताकि मैं इस तथ्य के लिए जान सकूं कि मुझे अपेक्षित व्यवहार मिल गया है।

मुझे यकीन नहीं है कि हम मौजूदा पारिस्थितिकी तंत्र को तोड़ने से कैसे बच सकते हैं, जिसमें मुद्दों की अपनी उचित हिस्सेदारी पहले से ही है।

मुझे गलत साबित होने में खुशी होगी, कृपया पूर्वाग्रह के साथ ऐसा करें - यह मेरे मन को शांत करेगा :)

@rcollina

मैं जानना चाहूंगा कि क्या मैं अभी भी .NET मानक निर्भरता का उपयोग कर सकता हूं जिसका मेरे पास कोई नियंत्रण नहीं है।

.Net मानक पुस्तकालय आमतौर पर क्रॉस-प्लेटफ़ॉर्म माना जाता है। और अगर कुछ लाइब्रेरी आज .ix Core 3 पर Unix पर सही तरीके से काम करती है (जो ICU का उपयोग करती है), तो यह लगभग निश्चित रूप से .Net 5 पर भी काम करेगा (जो कि ICU का भी उपयोग करता है)।

.NET मानक 2.2

.Net मानक vNext प्रभावी रूप से मौजूद है, हालांकि इसे ".Net 5.0" कहा जाता है। (यानी यदि आप एक पुस्तकालय लिख रहे हैं और पुराने ढाँचों का समर्थन करने की परवाह नहीं करते हैं, तो आज आप .Net Standard 2.1 को लक्षित करेंगे। एक महीने में, आप .Net 5.0 के बजाय लक्ष्य करेंगे।)

@svick मुझे मिल गया। मेरा मानना ​​है कि मैं पहले से ही समझता हूं कि .NET मानक कैसे काम करता है। मैं समझता हूं कि .NET 5 नया .NET मानक है, जैसा कि यह था।

मैं माफी माँगता हूँ, लेकिन जब मैं .NET .NET 2.1 पुस्तकालय का संदर्भ लेता हूँ, तो मैं इसके बारे में अनिश्चित हूँ कि IndexOf और Contains के बीच पहले से मौजूद व्यवहार असंगतता पर निर्भर था।

यहां जो कुछ बदल रहा है वह कुछ आउट ऑफ बैंड, आईसीयू बनाम एनएलएस है। यह परिवर्तन उस विसंगति को चौड़ा करता है जो हमारे पास पहले से थी, और उम्मीदों को तोड़ता है।
इस जानकारी को libs में एन्कोडिंग नहीं है।

मैं सभी निहितार्थों को समझने का अनुमान नहीं लगाता, लेकिन हम उस भावना को हिला नहीं सकते हैं, जो हम तकनीकी रूप से सही हैं, नए सामान्य के लिए एक सहज ऑनबोर्डिंग पथ के बिना। जिसकी अत्यंत आवश्यकता है।

जैसा कि किसी और ने उल्लेख किया है, अधिकांश लोगों को नई भाषा सुविधाओं के बारे में भी पता नहीं है, अकेले भूकंपीय परिवर्तन होने दें, जैसे कि यह हमारे समुदाय के सदस्यों द्वारा यादृच्छिक रूप से खोजा गया है। ऐसी कौन सी संभावनाएं हैं जिनका हम सामना कर सकते हैं?

मैं जानना चाहूंगा कि क्या मैं अभी भी .NET मानक निर्भरता का उपयोग कर सकता हूं जिसका मेरे पास कोई नियंत्रण नहीं है।

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

नहीं, यह नहीं है। यहां यह पर्याप्त जोर नहीं दिया जा सकता है कि ICU में _always_ का उपयोग Unix पर किया गया है। .NET मानक पुस्तकालयों को डिज़ाइन द्वारा पोर्टेबल माना जाता है और कुछ भी जो पहले लिनक्स .NET कोर 3.x पर काम करता था। .NET 5 में काम करेगा।

हमारे द्वारा किया जाने वाला अधिकांश कार्य InvariantCulture है, जो मेरी पिछली समझ के अनुसार डिजाइन द्वारा अपरिवर्तनीय माना जाता है।

सच नहीं। InvariantCulture केवल उपयोगकर्ता की भाषा सेटिंग को अनदेखा करने वाला है। यह अभी भी यूनिकोड युक्ति या भूमंडलीकरण पुस्तकालयों, आदि के अद्यतन के साथ बदल सकता है।

क्या .NET टीम ने दर्द और समस्याओं पर विचार किया और इसकी वजह क्या हो सकती है?

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

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

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

क्या .NET टीम ने दर्द और समस्याओं पर विचार किया और इसकी वजह क्या हो सकती है?

इस तरह से टिप्पणी करने के लिए मुझे कोई अंत नहीं है।

लाखों प्रोजेक्ट .NET पर चल रहे हैं और स्ट्रिंग हेरफेर एक बहुत ही लगातार ऑपरेशन है।
.NET टीम को इसे ठीक करने / बदलने के लिए जो प्रयास होता है, वह सभी मौजूदा कोड को सत्यापित करने के लिए आवश्यक प्रयास की तुलना में घटा हुआ है। इसे .NET 5/6 पर माइग्रेट किया जाएगा।

इसलिए, इसे संबोधित करने के लिए "योजना" के बारे में पूछना काफी उचित है।
क्या कोई योजना है?
क्या इस बदलाव का असर अनुमानित था?
क्या यह सभी परियोजनाओं का 0.001% है? क्या यह 75% है?
अन्य समान परिवर्तन क्या हैं जिनके बारे में हम नहीं जानते हैं?

हो सकता है कि यह कुछ ही परियोजनाओं को प्रभावित करता हो।
लेकिन, क्या यह अनुमान था?

BTW, मैं अच्छा पर्याप्त कारण दिए गए परिवर्तनों को तोड़ने के लिए हूँ। लेकिन, हमें एक प्रवास पथ की भी आवश्यकता है जो बहुत जोखिम भरा न हो।

@petarrepac मुझे गलत मत समझो, मैं समझता हूं कि लेकिन जैसा कि इस सूत्र में कई बार बताया गया है:

1. एक योजना है, और यह एक रनटाइम कॉन्फ़िगरेशन स्विच प्रदान करना है।
2. तोड़ने का दावा किया गया व्यवहार सभी गैर-विंडोज़ प्लेटफार्मों पर .NET का मौजूदा व्यवहार है।
3. यह केवल प्रभाव कोड होना चाहिए जो संस्कृति-संवेदनशील संचालन करता है जहां अध्यादेश का उद्देश्य था।

पिछले दो बिंदुओं को देखते हुए यह मान लेना उचित है कि इससे परियोजनाओं का काफी कम प्रतिशत प्रभावित होता है।

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

हैलो सभी को। हम उन मुद्दों का एक संक्षिप्त सारांश देना चाहते थे जो हमने तब उठाए थे जब यह मुद्दा खुला था और अंत में हमने विंडोज 10 मई 2019 को डिफ़ॉल्ट रखने या बाद में .NET 5.0 के लिए ICU होने का फैसला क्यों किया।

जब मुद्दा खोला गया था, तो हमने संभावित प्रभावों और दर्द के बारे में कुछ आंतरिक चर्चा शुरू की थी जो हमारे ग्राहकों के साथ Contains(string) बीच असंगतता को देखते हुए किया गया था जो Ordinal और IndexOf(string) संस्कृति-जागरूक होने के साथ-साथ अन्य API के कल्चर से अधिक होने पर डिफ़ॉल्ट रूप से संस्कृति-जागरूक होने के नाते, लेकिन Span<char> या ReadOnlySpan<char> से अधिक होने पर Ordinal होने पर। इसलिए इस मुद्दे पर चर्चा के बाद, हमने NuGet संकुल पर विश्लेषण करना शुरू किया जो प्रभावित हो सकता है और एक स्पष्ट चित्र प्राप्त करने के लिए डेटा एकत्र कर सकता है। यह हमारे निष्कर्ष थे:

• IndexOf, LastIndexOf, EndsWith, StartsWith, तुलना, और ComparTo को दिए गए "सबसे अधिक उपयोग किए जाने वाले स्ट्रिंग शाब्दिक" पर "n" # 30 है।
• 1% कॉलिंग String.EndsWith एक खोज स्ट्रिंग के साथ होती है जो \ n से शुरू होती है। इनमें से कोई भी कॉलिट जहां परीक्षण किया जा रहा है, उसमें "विंडो-स्टाइल लाइन एंडिंग्स" को तोड़ा जाएगा।
• NuGet.org पर 2040 पैकेज आईडी होस्ट किए गए हैं, जहां एक संस्करण में एक असेंबली कॉलसाइट के साथ एक असेंबली है।
• इन कॉलसिट का अधिकांश हिस्सा एंडस्विथ और इंडेक्सऑफ के लिए है, जो इस परिकल्पना के अनुरूप है कि इस पैटर्न का उपयोग अक्सर भोली रेखा-ब्रेकिंग एल्गोरिदम के लिए किया जाता है।

इन 2040 पैकेजों में, जिसमें एक जोखिम-जोखिम वाले कॉललाइट थे, केवल 539 .NET मानक या .NET कोर के कुछ संस्करण का समर्थन करते हैं, इसका मतलब है कि NuGet.org में सूचीबद्ध केवल 0.54% पैकेजों के टूटने की संभावना है।

हमने 539 संभावित रूप से प्रभावित पैकेज आईडी की सूची में उन लोगों पर वास्तविक प्रभाव का अनुमान लगाने के लिए पैकेजों को देखा। हमने शीर्ष 70 (डाउनलोड काउंट द्वारा) को देखा, 20 ने नवीनतम संस्करण में पैटर्न को उजागर नहीं किया, उन लोगों से जो पैटर्न को उजागर करते हैं हम केवल 32 को देख सकते हैं जिनके पास एक अनुज्ञेय लाइसेंस था:

• 14 बग के अधीन नहीं थे
• 13 संभावित रूप से टूट गए थे
• 5 अनिश्चित थे (विविध लाइन ब्रेक पैटर्न या अन्य mitigations के लिए रक्षात्मक कोडिंग के कारण ब्रेक का कोई स्पष्ट संकेत नहीं था)।

तो इसका मतलब यह है कि, केवल 70% डाउनलोड करके शीर्ष 70 पैकेजों से संभावित रूप से प्रभावित हुए थे।

ये प्रतिशत स्टैक किए गए हैं और NuGet.org पर 229,536 पैकेज की कुल संख्या के विरुद्ध नहीं हैं। इसलिए अगर हमने NuGet.org में कुल पैकेज और कुल डाउनलोड की संख्या का उपयोग किया है, तो हम 229,536 में से 539 संभावित प्रभावित पैकेजों को देख रहे हैं, जो 0.24% है।

और जब यह हमारे लिए पुस्तकालयों का विश्लेषण करने के लिए बहुत अच्छा है, नगेट केवल C # कोड के एक छोटे से अंश का प्रतिनिधित्व करता है। और यहां तक ​​कि अगर कोई कोड का मालिक है, तो ए) बग को ट्रैक करना आसान नहीं हो सकता है, और बी) वे वास्तव में अब स्रोत नहीं हो सकते हैं।

हालाँकि, यह निष्कर्ष निकालने के लिए डेटा का एक अच्छा स्रोत था, जबकि यह व्यवहार में एक बहुत ही उल्लेखनीय परिवर्तन हो सकता है, यह एक विराम है जो कि इनपुट पढ़ते समय पहले से ही यूनिक्स पर हुआ है जिसमें विंडोज लाइन एंडिंग (जो कि आम नहीं हो सकता है) हो सकता है।

.NET कोर और .NET 5+ में, हम OS के पार निरंतरता की ओर प्रयास कर रहे हैं और इस परिवर्तन के प्रभाव को देखते हुए, ऐसा लगा कि सही काम करना है। हम संगतता के बारे में परवाह करते हैं और इसलिए लोगों को विरासत व्यवहार पर वापस जाने में सक्षम होने के लिए एक कॉम्पिटिशन रनटाइम स्विच प्रदान कर रहे हैं।

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

इसे जोड़ने के लिए, वैश्वीकरण किसी भी समय बदल सकता है क्योंकि हम OS में एक पतले रैपर हैं, इसलिए यह इस समय सही बात की तरह लगा कि सभी OS पर एक ही आवरण हो, जिसका हम समर्थन करते हैं।

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

• .NET वैश्वीकरण और ICU
• .NET5 + पर तार की तुलना करते समय व्यवहार में परिवर्तन होता है
• वैश्वीकरण ने परिवर्तन को तोड़ दिया

आपकी सभी मूल्यवान प्रतिक्रिया के लिए धन्यवाद, क्योंकि यह हमेशा हमें एक बेहतर स्थान पर ले जाता है और हम .NET 6 के लिए इस अनुभव को बेहतर बनाने की कोशिश करेंगे, जैसा कि चर्चा की गई है: https://github.com/dotnet/runtime/issues/43956

चूँकि हम यूनिक्स और विंडोज पर लाइन एंडिंग के बीच के अंतर के कारण होने वाले दर्द को समझते हैं, इसलिए हम इस मुद्दे को खुला रख रहे हैं और हम .NET 5.0 के लिए \r\n केस को कम करने के संभावित तरीके की जाँच करेंगे। .x जो सर्विसिंग रिलीज़ का हिस्सा होना चाहिए।

चार और स्ट्रिंग के साथ एक अंतर भी है:

Console.WriteLine("com/test/test/test/a/b/ʹ$ʹ".IndexOf("$"));
Console.WriteLine("com/test/test/test/a/b/ʹ$ʹ".IndexOf('$'));

-1
24

@ mattleibow वर्ण खोज का उपयोग करते समय, यह क्रमिक खोज करता है। Doc https://docs.microsoft.com/en-us/dotnet/api/system.string.indexof?view=net-5.0#System_String_IndexOf_System_Char_ जो This method performs an ordinal (culture-insensitive) search । यदि आप क्रमिक विकल्प के साथ स्ट्रिंग खोज करते हैं, तो आपको चरित्र के समान परिणाम मिलेगा।

C# Console.WriteLine("com/test/test/test/a/b/ʹ$ʹ".IndexOf("$", StringComparison.Ordinal));

~ ऐसा लगता है कि CA1307 केवल indexof(char) पर ट्रिगर करता है लेकिन indexof(string) । क्या string संस्करण के लिए कोई नियम है? यह अधिक महत्वपूर्ण लगता है क्योंकि डिफ़ॉल्ट रूप से char स्वचालित रूप से ऑर्डिनल का उपयोग करता है और ब्रेकिंग परिवर्तन वास्तव में इसे प्रभावित नहीं करता है, जबकि string का व्यवहार बदल गया है और आपको व्यवहार को पुनर्स्थापित करने के लिए ऑर्डिनल निर्दिष्ट करने की आवश्यकता है कुछ मामले। ~

~ आप indexof(string) कैसे पता लगाते हैं? ~

मिला, यह CA1310 का नियम है। हमारे डॉक्स https://docs.microsoft.com/en-us/dotnet/standard/globalization-localization/globalization-icu#use -nls -n-of-icu के लिए गलत हैं और इस विशिष्ट भिन्नता का उल्लेख नहीं करते हैं। मैं उन डॉक्स को अपडेट करूंगा।