اندازهی قلم متن
تخمین مدت زمان مطالعهی مطلب:
چهار دقیقه
با توجه به ماهیت چندسکویی NET 5.، در اکثر سیستمهای ویندوزی، سرویس بومی سازی، بر اساس استاندارد NLS کار میکند، اما در سیستمهای لینوکسی و مبتنی بر یونیکس، این استاندارد از نوع ICU است (و وجود و تنظیم آنها خارج از NET. و توسط سیستم عامل مدیریت میشود). جهت یکدست سازی این دو نوع سیستم بومی سازی در دات نت، از نگارش 5 آن به بعد، استاندارد ICU که به صورت گستردهتری مورد پذیرش قرار گرفتهاست، استاندارد بومی سازی پیشفرض دات نت درنظر گرفته میشود؛ مگر اینکه سیستم عاملی آنرا پشتیبانی نکند.
کدام نگارش از ویندوز، از ICU پشتیبانی میکند؟
تمام ویندوزهای پس از Windows 10 May 2019 Update، به همراه icu.dll، به عنوان جزء استاندارد سیستم عامل هستند. بنابراین دات نت 5 و نگارشهای پس از آن، در این سیستم عاملها، از سرویس بومی سازی ICU استفاده خواهند کرد؛ اما اگر از نگارشهای پیشین ویندوز استفاده میکنید، به اجبار به سیستم NLS سوئیچ خواهد شد.
تاثیر ICU بر برنامههای دات نت 5 به بعد
قطعه کد زیر را درنظر بگیرید:
در نگارشهای پیش از 5 دات نت، خروجی کدهای فوق، عدد 6 است؛ اما ... اما ... (!) از زمان دات نت 5 به بعد، خروجی آن «منهای یک» است! البته به شرطی که آخرین به روز رسانی ویندوز 10 را نصب کرده باشید؛ یعنی حداقل Windows 10 May 2019 Update را داشته باشید.
حالت «پیشفرض» جستجو و مقایسهی رشتهها در دات نت 5 به بعد، یک مقایسهی مبتنی بر «دستورات زبانی» بر اساس فرهنگ تنظیم شدهی در Thread جاری برنامهاست (یا همان System.Threading.Thread.CurrentThread.CurrentCulture).
چرا متدهای کار بر روی رشتهها در دات نت 5 به بعد، نسبت به نگارشهای قبلی متفاوت عمل میکنند؟
زمانیکه متدی مانند IndexOf فراخوانی میشود، هدف عمدهی برنامهنویسها، یک جستجوی Ordinal است (یعنی مقایسهی کاراکتر به کاراکتر؛ بدون درنظر گرفتن نکات زبانی و بومی)؛ اما فراموش میکنند که این متدها دارای پارامتر دومی هم هستند که از نوع StringComparison است و سالها است که توصیه میشود این پارامتر را هم به صورت صریحی مقدار دهی کنید تا هدف خود را از نوع جستجو دقیقا مشخص نمائید. از زمان دات نت 5 به بعد، اگر این پارامتر را مشخص نکنید، جستجوی صورت گرفته یک رفتار culture-specific را خواهد داشت و نه Ordinal. از این لحاظ مقایسهی رشتهها توسط استانداردهای ICU و NLS، بر اساس پیاده سازیهای مختلف زبانشناسی، خروجیهای یکسانی را ارائه نمیدهند و به همین جهت است که اینبار خروجی منهای یک را دریافت میکنیم.
یک نکته: خروجی قطعه کد فوق در سیستمهای لینوکسی که از .NET Core 2x - 3x. هم استفاده میکنند، دقیقا منهای یک است؛ چون پیشفرض بومی سازی آنها نیز ICU است.
چگونه میتوان به همان حالت پیشین مقایسهی رشتهها در NET. بازگشت؟
مایکروسافت بستهی نیوگت Microsoft.CodeAnalysis.FxCopAnalyzers را جهت گوشزد کردن نکتهی ذکر صریح StringComparison، به روز رسانی کردهاست. بنابراین بهتر است تا آنرا به پروژهی خود اضافه کنید. در این حالت اخطارهای مناسبی را جهت یافتن قسمتهای مشکلدار برنامهی خود دریافت میکنید. برای مثال برای اینکه در قطعه کد فوق به همان پاسخ متداول 6 برسیم، تنها کافیاست پارامتر دوم StringComparison را ذکر کنیم:
و یا حتی میتوانید فایل csproj پروژهی خود را ویرایش کرده و یک سطر زیر را به آن اضافه کنید:
در این حالت کل برنامهی شما بدون هیچ تغییری مانند قبل کار کرده و از سیستم NLS استفاده میشود.
کدام متدهای کار با رشتهها در دات نت 5، تحت تاثیر این تغییرات قرار گرفتهاند؟
اگر از متدهای زیر در برنامههای خود استفاده میکنید، نکتهی ذکر پارامتر StringComparison.Ordinal را فراموش نکنید:
سؤال: اگر متدی پارامتر دوم StringComparison را نداشت چطور؟
اگر به ماخذ «Behavior changes when comparing strings on .NET 5» مراجعه کنید، در انتهای آن جدولی را ارائه داده که دو سطر اول آن، به صورت زیر است:
در این جدول، هر متدی که رفتار پیشفرض آن از نوع CurrentCulture است، تحت تاثیر قرار گرفتهاست و متدی مانند string.Contains که رفتار پیشفرض آن Ordinal است، از این تغییرات مصون است و نیازی به تغییری ندارد.
برای مطالعهی بیشتر:
Behavior changes when comparing strings on .NET 5+
.NET globalization and ICU.
Globalization breaking changes
بحث و گفتگویی در این مورد
کدام نگارش از ویندوز، از ICU پشتیبانی میکند؟
تمام ویندوزهای پس از Windows 10 May 2019 Update، به همراه icu.dll، به عنوان جزء استاندارد سیستم عامل هستند. بنابراین دات نت 5 و نگارشهای پس از آن، در این سیستم عاملها، از سرویس بومی سازی ICU استفاده خواهند کرد؛ اما اگر از نگارشهای پیشین ویندوز استفاده میکنید، به اجبار به سیستم NLS سوئیچ خواهد شد.
تاثیر ICU بر برنامههای دات نت 5 به بعد
قطعه کد زیر را درنظر بگیرید:
string s = "Hello\r\nworld!"; int idx = s.IndexOf("\n"); Console.WriteLine(idx);
حالت «پیشفرض» جستجو و مقایسهی رشتهها در دات نت 5 به بعد، یک مقایسهی مبتنی بر «دستورات زبانی» بر اساس فرهنگ تنظیم شدهی در Thread جاری برنامهاست (یا همان System.Threading.Thread.CurrentThread.CurrentCulture).
چرا متدهای کار بر روی رشتهها در دات نت 5 به بعد، نسبت به نگارشهای قبلی متفاوت عمل میکنند؟
زمانیکه متدی مانند IndexOf فراخوانی میشود، هدف عمدهی برنامهنویسها، یک جستجوی Ordinal است (یعنی مقایسهی کاراکتر به کاراکتر؛ بدون درنظر گرفتن نکات زبانی و بومی)؛ اما فراموش میکنند که این متدها دارای پارامتر دومی هم هستند که از نوع StringComparison است و سالها است که توصیه میشود این پارامتر را هم به صورت صریحی مقدار دهی کنید تا هدف خود را از نوع جستجو دقیقا مشخص نمائید. از زمان دات نت 5 به بعد، اگر این پارامتر را مشخص نکنید، جستجوی صورت گرفته یک رفتار culture-specific را خواهد داشت و نه Ordinal. از این لحاظ مقایسهی رشتهها توسط استانداردهای ICU و NLS، بر اساس پیاده سازیهای مختلف زبانشناسی، خروجیهای یکسانی را ارائه نمیدهند و به همین جهت است که اینبار خروجی منهای یک را دریافت میکنیم.
یک نکته: خروجی قطعه کد فوق در سیستمهای لینوکسی که از .NET Core 2x - 3x. هم استفاده میکنند، دقیقا منهای یک است؛ چون پیشفرض بومی سازی آنها نیز ICU است.
چگونه میتوان به همان حالت پیشین مقایسهی رشتهها در NET. بازگشت؟
مایکروسافت بستهی نیوگت Microsoft.CodeAnalysis.FxCopAnalyzers را جهت گوشزد کردن نکتهی ذکر صریح StringComparison، به روز رسانی کردهاست. بنابراین بهتر است تا آنرا به پروژهی خود اضافه کنید. در این حالت اخطارهای مناسبی را جهت یافتن قسمتهای مشکلدار برنامهی خود دریافت میکنید. برای مثال برای اینکه در قطعه کد فوق به همان پاسخ متداول 6 برسیم، تنها کافیاست پارامتر دوم StringComparison را ذکر کنیم:
int idx = s.IndexOf("\n", StringComparison.Ordinal);
و یا حتی میتوانید فایل csproj پروژهی خود را ویرایش کرده و یک سطر زیر را به آن اضافه کنید:
<ItemGroup> <RuntimeHostConfigurationOption Include="System.Globalization.UseNls" Value="true" /> </ItemGroup>
کدام متدهای کار با رشتهها در دات نت 5، تحت تاثیر این تغییرات قرار گرفتهاند؟
اگر از متدهای زیر در برنامههای خود استفاده میکنید، نکتهی ذکر پارامتر StringComparison.Ordinal را فراموش نکنید:
System.String.Compare System.String.EndsWith System.String.IndexOf System.String.StartsWith System.String.ToLower System.String.ToLowerInvariant System.String.ToUpper System.String.ToUpperInvariant System.Globalization.TextInfo (most members) System.Globalization.CompareInfo (most members) System.Array.Sort (when sorting arrays of strings) System.Collections.Generic.List<T>.Sort() (when the list elements are strings) System.Collections.Generic.SortedDictionary<TKey,TValue> (when the keys are strings) System.Collections.Generic.SortedList<TKey,TValue> (when the keys are strings) System.Collections.Generic.SortedSet<T> (when the set contains strings)
سؤال: اگر متدی پارامتر دوم StringComparison را نداشت چطور؟
اگر به ماخذ «Behavior changes when comparing strings on .NET 5» مراجعه کنید، در انتهای آن جدولی را ارائه داده که دو سطر اول آن، به صورت زیر است:
API Default behavior Remarks string.Compare CurrentCulture
برای مطالعهی بیشتر:
Behavior changes when comparing strings on .NET 5+
.NET globalization and ICU.
Globalization breaking changes
بحث و گفتگویی در این مورد