اشتراکها
معروفترین کتابخانهی کار با JSON در دات نت، Json.NET است که این روزها، جزء جدایی ناپذیر حداقل، تمام برنامههای وب مبتنی بر دات نت میباشد. برای مثال ASP.NET Core 2x/1x و همچنین ASP.NET Web API پیش از NET Core.، به صورت پیشفرض از این کتابخانه برای کار با JSON استفاده میکنند. این کتابخانه 10 سال پیش ایجاد شد و در طول زمان، قابلیتهای زیادی به آن اضافه شدهاست. همین حجم بالای کار صورت گرفته سبب شدهاست که برای مثال شروع به استفادهی از <Span<T در آن برای بالابردن کارآیی، بسیار مشکل شده و نیاز به تغییرات اساسی در آن داشته باشد. به همین جهت خود تیم CoreFX دات نت Core گزینهی دیگری را برای کار با JSON در فضای نام جدید System.Text.Json ارائه دادهاست که برای کار با آن نیاز به نصب وابستگی ثالثی نیست و همچنین کارآیی آن به علت استفادهی از ویژگیهای جدید زبان، مانند ref struct و Span، به طور میانگین دو برابر کتابخانهی Json.NET است. برای مثال استفادهی از string (حالت پیشفرض کتابخانهی Json.NET) یعنی کار با رشتههایی از نوع UTF-16؛ اما کار با Span، امکان دسترسی مستقیم به رشتههایی از نوع UTF-8 را میسر میکند که نیازی به تبدیل به رشتههایی از نوع UTF-16 را ندارند.
ASP.NET Core 3x دیگر به صورت پیشفرض به همراه Json.NET ارائه نمیشود
در برنامههای ASP.NET Core 3x، وابستگی ثالث Json.NET حذف شدهاست و از این پس هر نوع خروجی JSON آن، مانند بازگشت مقادیر مختلف از اکشن متدهای کنترلرها، به صورت خودکار در پشت صحنه از امکانات ارائه شدهی در System.Text.Json استفاده میکند و دیگر Json.NET، کتابخانهی پیشفرض کار با JSON آن نیست. بنابراین برای کار با آن نیاز به تنظیم خاصی نیست. همینقدر که یک پروژهی جدید ASP.NET Core 3x را ایجاد کنید، یعنی در حال استفادهی از System.Text.Json هستید.
روش بازگشت به Json.NET در ASP.NET Core 3x
اگر به هر دلیلی هنوز نیاز به استفادهی از کتابخانهی Json.NET را دارید، آداپتور ویژهی آن نیز تدارک دیده شدهاست. برای اینکار:
الف) ابتدا باید بستهی نیوگت Microsoft.AspNetCore.Mvc.NewtonsoftJson را نصب کنید.
ب) سپس در کلاس Startup، باید این کتابخانه را به صورت یک سرویس جدید، با فراخوانی متد AddNewtonsoftJson، معرفی کرد:
یکی از دلایل بازگشت به Json.NET میتواند عدم پشتیبانی از OpenAPI / Swagger در حین کار با System.Text.Json باشد و این مورد قرار نیست در نگارش نهایی 3.0، حضور داشته باشد و انطباق با آن به نگارشهای بعدی موکول شدهاست.
روش کار مستقیم با System.Text.Json
اگر در قسمتی از برنامهی خود نیاز به کار مستقیم با اشیاء JSON را داشته باشید و یا حتی بخواهید از این قابلیت در برنامههای کنسول و یا کتابخانهها نیز استفاده کنید، روش انتقال کدهایی که از Json.NET استفاده میکنند به System.Text.Json، به صورت زیر است:
تبدیل رشتهی JSON حاوی اطلاعات شخص، به شیء متناظر با آن و یا حالت عکس آن:
در اینجا از کلاس System.Text.Json.Serialization.JsonSerializer، روش کار با دو متد Parse را برای Deserialization و ToString را برای Serialization مشاهده میکنید.
کلاس JsonSerializer دارای overloadهای زیر برای کار با متدهای Parse و ToString است:
یک نکته: کارآیی متد Parse با امضای ReadOnlySpan<byte> utf8Json، بیشتر است از نمونهای که string json را میپذیرد. از این جهت که چون با آرایهای از بایتهای رشتهای از نوع UTF-8 کار میکند، نیاز به تبدیل به UTF-16 را مانند متدی که string را میپذیرد، ندارد. برای تولید آرایهی بایتهای utf8Json از روی یک شیء، میتوانید از متد JsonSerializer.ToUtf8Bytes استفاده کنید و یا برای تولید آن از روی یک رشته، از متد Encoding.UTF8.GetBytes استفاده کنید.
سفارشی سازی JsonSerializer جدید
اگر به امضای متدهای Parse و ToString کلاس JsonSerializer دقت کنید، دارای یک پارامتر اختیاری از نوع JsonSerializerOptions نیز هستند که به صورت زیر تعریف شدهاست:
برای نمونه معادل تنظیم NullValueHandling در Json.NET:
اینبار توسط خاصیت IgnoreNullValues صورت میگیرد:
در برنامههای ASP.NET Core که این نوع متدها در پشت صحنه فراخوانی میشوند، روش تنظیم JsonSerializerOptions به صورت زیر است:
نگاشت نام ویژهی خواص در حین عملیات deserialization
در مثال فوق، فرض شدهاست که نام خاصیت BirthDay، دقیقا با اطلاعاتی که از رشتهی JSON دریافتی پردازش میشود، تطابق دارد. اگر این نام در اطلاعات دریافتی متفاوت است، میتوان از ویژگی JsonPropertyName برای تعریف این نگاشت استفاده کرد:
روش دیگر اینکار، برای نمونه تنظیم PropertyNamingPolicy به حالت CamelCase است:
و یا اگر میخواهید حساسیت به بزرگی و کوچکی حروف را ندید بگیرید (مانند حالت پیشفرض JSON.NET) از تنظیم JsonSerializerOptions.PropertyNameCaseInsensitive استفاده کنید.
در این بین اگر نمیخواهید خاصیتی در عملیات serialization و یا برعکس آن پردازش شود، میتوان از تعریف ویژگی [JsonIgnore] بر روی آن استفاده کرد.
ASP.NET Core 3x دیگر به صورت پیشفرض به همراه Json.NET ارائه نمیشود
در برنامههای ASP.NET Core 3x، وابستگی ثالث Json.NET حذف شدهاست و از این پس هر نوع خروجی JSON آن، مانند بازگشت مقادیر مختلف از اکشن متدهای کنترلرها، به صورت خودکار در پشت صحنه از امکانات ارائه شدهی در System.Text.Json استفاده میکند و دیگر Json.NET، کتابخانهی پیشفرض کار با JSON آن نیست. بنابراین برای کار با آن نیاز به تنظیم خاصی نیست. همینقدر که یک پروژهی جدید ASP.NET Core 3x را ایجاد کنید، یعنی در حال استفادهی از System.Text.Json هستید.
روش بازگشت به Json.NET در ASP.NET Core 3x
اگر به هر دلیلی هنوز نیاز به استفادهی از کتابخانهی Json.NET را دارید، آداپتور ویژهی آن نیز تدارک دیده شدهاست. برای اینکار:
الف) ابتدا باید بستهی نیوگت Microsoft.AspNetCore.Mvc.NewtonsoftJson را نصب کنید.
ب) سپس در کلاس Startup، باید این کتابخانه را به صورت یک سرویس جدید، با فراخوانی متد AddNewtonsoftJson، معرفی کرد:
public void ConfigureServices(IServiceCollection services) { services.AddControllers() .AddNewtonsoftJson() // ... }
روش کار مستقیم با System.Text.Json
اگر در قسمتی از برنامهی خود نیاز به کار مستقیم با اشیاء JSON را داشته باشید و یا حتی بخواهید از این قابلیت در برنامههای کنسول و یا کتابخانهها نیز استفاده کنید، روش انتقال کدهایی که از Json.NET استفاده میکنند به System.Text.Json، به صورت زیر است:
public class Person { public string FirstName { get; set; } public string LastName { get; set; } public DateTime? BirthDay { get; set; } }
using System; using System.Text.Json.Serialization; namespace ConsoleApp { class Program { static void Main(string[] args) { Person person = JsonSerializer.Parse<Person>(...); string json = JsonSerializer.ToString(person); } } }
کلاس JsonSerializer دارای overloadهای زیر برای کار با متدهای Parse و ToString است:
namespace System.Text.Json.Serialization { public static class JsonSerializer { public static object Parse(ReadOnlySpan<byte> utf8Json, Type returnType, JsonSerializerOptions options = null); public static object Parse(string json, Type returnType, JsonSerializerOptions options = null); public static TValue Parse<TValue>(ReadOnlySpan<byte> utf8Json, JsonSerializerOptions options = null); public static TValue Parse<TValue>(string json, JsonSerializerOptions options = null); public static string ToString(object value, Type type, JsonSerializerOptions options = null); public static string ToString<TValue>(TValue value, JsonSerializerOptions options = null); } }
سفارشی سازی JsonSerializer جدید
اگر به امضای متدهای Parse و ToString کلاس JsonSerializer دقت کنید، دارای یک پارامتر اختیاری از نوع JsonSerializerOptions نیز هستند که به صورت زیر تعریف شدهاست:
public sealed class JsonSerializerOptions { public bool AllowTrailingCommas { get; set; } public int DefaultBufferSize { get; set; } public JsonNamingPolicy DictionaryKeyPolicy { get; set; } public bool IgnoreNullValues { get; set; } public bool IgnoreReadOnlyProperties { get; set; } public int MaxDepth { get; set; } public bool PropertyNameCaseInsensitive { get; set; } public JsonNamingPolicy PropertyNamingPolicy { get; set; } public JsonCommentHandling ReadCommentHandling { get; set; } public bool WriteIndented { get; set; } }
// Json.NET: var settings = new JsonSerializerSettings { NullValueHandling = NullValueHandling.Ignore }; string json = JsonConvert.SerializeObject(person, settings);
// JsonSerializer: var options = new JsonSerializerOptions { IgnoreNullValues = true }; string json = JsonSerializer.ToString(person, options);
در برنامههای ASP.NET Core که این نوع متدها در پشت صحنه فراخوانی میشوند، روش تنظیم JsonSerializerOptions به صورت زیر است:
services.AddControllers() .AddJsonOptions(options => options.JsonSerializerOptions.WriteIndented = true);
نگاشت نام ویژهی خواص در حین عملیات deserialization
در مثال فوق، فرض شدهاست که نام خاصیت BirthDay، دقیقا با اطلاعاتی که از رشتهی JSON دریافتی پردازش میشود، تطابق دارد. اگر این نام در اطلاعات دریافتی متفاوت است، میتوان از ویژگی JsonPropertyName برای تعریف این نگاشت استفاده کرد:
[JsonPropertyName("birthdate")] public DateTime? BirthDay { get; set; }
var options = new JsonSerializerOptions { PropertyNamingPolicy = JsonNamingPolicy.CamelCase }; string json = JsonSerializer.ToString(person, options);
در این بین اگر نمیخواهید خاصیتی در عملیات serialization و یا برعکس آن پردازش شود، میتوان از تعریف ویژگی [JsonIgnore] بر روی آن استفاده کرد.
نظرات مطالب
نحوه ارتقاء برنامههای موجود MVC3 به MVC4
مشکلی مشاهده نشد. با دات نتهای 4.5 و 4.5.1 در یک برنامه MVC 5.x تست شد و کار میکند.
اگر v خالی است، ممکن است اسکریپتهای مورد استفاده مشکل دارند. آدرس نهایی تولید شده را مستقلا در مرورگر باز کرده و خروجی آنرا بررسی کنید. اگر مشکلی باشد، در ابتدای خروجی، خطاها را ذکر میکند.
اگر v خالی است، ممکن است اسکریپتهای مورد استفاده مشکل دارند. آدرس نهایی تولید شده را مستقلا در مرورگر باز کرده و خروجی آنرا بررسی کنید. اگر مشکلی باشد، در ابتدای خروجی، خطاها را ذکر میکند.
اشتراکها
شروع کار با OpenAI و ChatGPT با #C
در شروع کار با تکنولوژیهای جدید ممکنه همیشه اولش کمی پیچیده بنظر بیاد و زمان بر باشه. توی این مخزن(Repository) گیتهاب سعی کردم چند مثال از کار با OpenAI API با دات نت و به زبان سی شارپ بزارم.
از سادهترین حالت فراخوانی API تا مدلهای یکم پیچیده مثل یک ربات تلگرامی برای چت با ChatGPT و همچنین تولید عکسهای خلاقانه بر اساس promptهای ورودی کاربر با استفاده از DALL-E.
به مرور سعی میکنم مثالهای بیشتر و پیشرفتهتری رو هم اضافه کنم تا برای اونایی که در شروع این راه هستند با حداقل اصطکاک یادگیری و در کمترین زمان بتوانند ایدههای خود را بر اساس ChatGPT پیاده سازی کنند.
در تولید کدها و همچنین مستندسازی هم تا حد امکان سعی کردم از خود ChatGPT استفاده کنم!
با برنامههای دات نت هم کار میکنه. مثلا متد new WebClient().DownloadData را در برنامه دات نتی خودتون فراخوانی کنید. بعد در برنامه API Monitor تیک قسمت مربوط به شبکه و اینترنت را قرار دهید (تصویر اول مقاله فوق). تمام فراخوانیهای شبکه برنامه را مونیتور میکند.
ضمنا برنامه API Monitor قابل بسط است. یعنی اگر به پوشه API آن مراجعه کنید یک سری فایل XML در آن قرار دارد که تعاریف توابع DLLهای مختلف در آن ارائه شدهاند. اگر تعریفی یا DLL ایی در آن نیست، قابل افزودن است. یا حتی اگر خودتان نمیتوانید اینکار را انجام دهید، فایل هدر آنرا در انجمن این برنامه ارسال کنید تا به شما کمک کنند.
ضمنا برنامه API Monitor قابل بسط است. یعنی اگر به پوشه API آن مراجعه کنید یک سری فایل XML در آن قرار دارد که تعاریف توابع DLLهای مختلف در آن ارائه شدهاند. اگر تعریفی یا DLL ایی در آن نیست، قابل افزودن است. یا حتی اگر خودتان نمیتوانید اینکار را انجام دهید، فایل هدر آنرا در انجمن این برنامه ارسال کنید تا به شما کمک کنند.
یکی از اهداف مهم استفادهی از TypeScript، یافتن خطاهای متداول کدهای جاواسکریپتی، پیش از اجرای آنها در مرورگر است. برای مثال، قطعه کد زیر:
دارای سه مشکل است که سریعا توسط TypeScript شناسایی میشود:
- خاصیت lastname در شیء author وجود خارجی ندارد.
- نوع رشتهای، به همراه متد trimStart نیست.
- متد charCodeAt یک عدد را به عنوان پارامتر قبول میکند.
اما باید درنظر داشت که بسیاری از قابلیتهای بررسی کد TypeScript، به صورت پیشفرض فعال نیستند که در ادامه آنها را برای یافتن پیش از موعود بسیاری از مشکلات، فعالسازی خواهیم کرد.
نصب افزونهی TSLint در VSCode
جهت مشاهدهی بهتر خطاهای کامپایلر TypeScript، پیش از کامپایل نهایی کدها، میتوان از افزونهی TSLint استفاده کرد. برای نصب آن، ابتدا باید بستهی ذیل را نصب کرد:
سپس نیاز است افزونهی آنرا نیز نصب کنید: https://marketplace.visualstudio.com/items?itemName=eg2.tslint
کار TSLint انجام static code analysis است؛ چیزی شبیه به افزونههایی مانند ریشارپر در ویژوال استودیو که راهنماهایی را در مورد بهتر کردن کیفیت کدهای نوشته شده ارائه میدهد.
فعالسازی بررسی نال و نوعهای نال پذیر
strictNullChecks یکی از مهمترین پرچمهای تنظیمات کامپایلر تایپاسکریپت است. برای افزودن آن، به فایل tsconfig.json مراجعه کرده و پرچم آنرا به true تنظیم کنید:
به این ترتیب کامپایلر تایپاسکریپت، بین null ،undefined و سایر نوعها، تفاوت قائل خواهد شد و اگر نوعی نالپذیر است، باید آنرا به صورت صریح type | null تعریف کنید.
برای مثال، متد ذیل را در نظر بگیرید:
زمانیکه پرچم strictNullChecks فعال شود، قطعه کد فوق با خطای ذیل کامپایل نخواهد شد:
از این جهت که خروجی متد getItem به صورت string | null تعریف شدهاست؛ اما پارامتر متد JSON.parse فقط string را قبول میکند. یعنی ممکن است data دریافتی نال باشد که متد JSON.parse قادر به پردازش آن نیست.
برای رفع این مشکل تنها کافی است بررسی کنیم که آیا data نال است یا خیر؟ و اگر خیر، آنگاه آنرا به متد JSON.parse ارسال کنیم:
همانطور که ملاحظه میکنید، فعالسازی strictNullChecks میتواند از بروز بسیاری از خطاهای در زمان اجرای برنامه، جلوگیری کند.
گزارش returnهای فراموش شده
در متد ذیل، یک return فراموش شده وجود دارد و تمام شرطهای برنامه به یک خروجی مشخص، منتهی نمیشوند:
برای تشخیص زود هنگام یک چنین مشکلاتی میتوان پرچم noImplicitReturns را در فایل tsconfig.json به true تنظیم کرد:
پس از این تنظیم، کامپایلر در مورد متد noImplicitReturns، خطای ذیل را صادر میکند:
تشخیص کدهای مرده
قطعه کدی که پس از یک return قرار بگیرد، یک کد مرده نامیده میشود. با تنظیم پرچم allowUnreachableCode در فایل tsconfig.json به false، میتوان کامپایلر TypeScript را وادار کرد تا اینگونه موارد را به عنوان خطا گزارش کند:
پس از این فعالسازی، کامپایلر TypeScript دو خطای [ts] Unreachable code detected را در مورد قطعه کد ذیل صادر میکند:
مورد اول مربوط به بدنهی if ایی است که شرط آن false است و این بدنه هیچگاه فراخوانی نمیشود و مورد دوم، به سطر پس از return آخر مرتبط است که آن مورد نیز یک کد مرده محسوب میشود.
تشخیص پارامترها و متغیرهای استفاده نشده
دو متد ذیل را درنظر بگیرید:
در اولی متغیر a تعریف شدهاست، اما هیچگاه استفاده نشدهاست. در متد دوم، پارامتر n نیز هیچگاه خوانده نشدهاست و وجود آن بیمصرف است؛ حتی ممکن است نشان فراموش شدن استفادهی از آن و مقدار دهی اشتباه آن باشد.
برای فعالسازی بررسی یک چنین مواردی باید دو پرچم ذیل را در فایل tsconfig.json به true تنظیم کرد:
پس از آن، کامپایلر دو خطای ذیل را در مورد متدهای فوق، گزارش میکند:
یافتن خواصی که نباید در یک شیء وجود داشته باشند
در مثال ذیل، خاصیت baz در تعاریف اصلی نوعهای x و y وجود ندارد:
برای فعالسازی یافتن یک چنین مواردی که در بسیاری از حالات ممکن است ناشی از اشتباهات تایپی نیز باشند، میتوان پرچم suppressExcessPropertyErrors را در فایل tsconfig.json به false تنظیم کرد:
پس از آن برای نمونه در مورد انتساب اول، یک چنین پیام خطایی از طرف کامپایلر TypeScript صادر خواهد شد:
یافتن breakهای فراموش شده در عبارات switch
در مثال زیر، یک break فراموش شدهاست:
برای تشخیص آن توسط کامپایلر TypeScript باید پرچم noFallthroughCasesInSwitch را در فایل tsconfig.json به true تنظیم کرد:
پس از آن کامپایلر TypeScript خطای «[ts] Fallthrough case in switch» را در مورد متد فوق صادر میکند.
یافتن ایندکسهای تعریف نشدهی در اشیاء
در مثال زیر، شیء x دارای خاصیت b نیست؛ اما دقیقا با این ایندکس مورد استفاده قرار گرفتهاست:
برای تشخیص یک چنین خطاهایی میتوان پرچم suppressImplicitAnyIndexErrors را در فایل tsconfig.json به false تنظیم کرد:
پس از آن کامپایلر TypeScript خطای ذیل را در مورد دسترسی به ایندکسی که با امضای شیء سازگاری ندارد، صادر میکند:
اجبار به تعریف صریح نوعها در TypeScript
عمدهی قابلیت TypeScript در یافتن خطاها به تعاریف نوعها و راهنمایی کامپایلر آن در این زمینه بر میگردد. اما چون این زبان سازگاری کاملی را با JavaScript دارد، تعریف نوعها در آن اجباری نیست و در این حالت اگر نوعی تعریف نشده باشد، به any تفسیر میشود. جهت اجبار به تعریف نوعها در TypeScript میتوان پرچم noImplicitAny را در فایل tsconfig.json به true تنظیم کرد:
در این حالت دیگر قطعه کد ذیل کامپایل نخواهد شد:
برای رفع این مشکل میتوان نوع args را به صورت صریحی مشخص کرد:
یک نکتهی تکمیلی
اگر از دستور ng build --watch برای ساخت برنامههای Angular استفاده میکنید، تغییرات فوق زمانی تاثیر داده خواهند شد که یکبار این برنامه را بسته و مجددا اجرا کنید.
defaultChecks() { const author = { firstName: "Vahid", lastName: "N" }; console.log(author.lastname); author.lastName.trimStart(); author.firstName.charCodeAt("1"); }
- خاصیت lastname در شیء author وجود خارجی ندارد.
- نوع رشتهای، به همراه متد trimStart نیست.
- متد charCodeAt یک عدد را به عنوان پارامتر قبول میکند.
اما باید درنظر داشت که بسیاری از قابلیتهای بررسی کد TypeScript، به صورت پیشفرض فعال نیستند که در ادامه آنها را برای یافتن پیش از موعود بسیاری از مشکلات، فعالسازی خواهیم کرد.
نصب افزونهی TSLint در VSCode
جهت مشاهدهی بهتر خطاهای کامپایلر TypeScript، پیش از کامپایل نهایی کدها، میتوان از افزونهی TSLint استفاده کرد. برای نصب آن، ابتدا باید بستهی ذیل را نصب کرد:
> npm install -g tslint typescript
کار TSLint انجام static code analysis است؛ چیزی شبیه به افزونههایی مانند ریشارپر در ویژوال استودیو که راهنماهایی را در مورد بهتر کردن کیفیت کدهای نوشته شده ارائه میدهد.
فعالسازی بررسی نال و نوعهای نال پذیر
strictNullChecks یکی از مهمترین پرچمهای تنظیمات کامپایلر تایپاسکریپت است. برای افزودن آن، به فایل tsconfig.json مراجعه کرده و پرچم آنرا به true تنظیم کنید:
{ "compilerOptions": { "strictNullChecks": true } }
برای مثال، متد ذیل را در نظر بگیرید:
getSessionItem(key: string): any { const data = window.sessionStorage.getItem(key); return JSON.parse(data); }
[ts] Argument of type 'string | null' is not assignable to parameter of type 'string'. Type 'null' is not assignable to type 'string'. const data: string | null
برای رفع این مشکل تنها کافی است بررسی کنیم که آیا data نال است یا خیر؟ و اگر خیر، آنگاه آنرا به متد JSON.parse ارسال کنیم:
getSessionItem(key: string): any { const data = window.sessionStorage.getItem(key); if (data) { return JSON.parse(data); } else { return null; } }
گزارش returnهای فراموش شده
در متد ذیل، یک return فراموش شده وجود دارد و تمام شرطهای برنامه به یک خروجی مشخص، منتهی نمیشوند:
noImplicitReturns(a: number) { if (a > 10) { return a; } // No return in this branch }
{ "compilerOptions": { "noImplicitReturns": true } }
[ts] Not all code paths return a value.
تشخیص کدهای مرده
قطعه کدی که پس از یک return قرار بگیرد، یک کد مرده نامیده میشود. با تنظیم پرچم allowUnreachableCode در فایل tsconfig.json به false، میتوان کامپایلر TypeScript را وادار کرد تا اینگونه موارد را به عنوان خطا گزارش کند:
{ "compilerOptions": { "allowUnreachableCode": false } }
allowUnreachableCode() { if (false) { console.log("Unreachable code"); } const a = 1; if (a > 0) { return 10; // reachable code } return 0; console.log("Unreachable code"); }
تشخیص پارامترها و متغیرهای استفاده نشده
دو متد ذیل را درنظر بگیرید:
unusedLocals() { const a = "foo"; // Error: 'a' is declared but its value is never read return "bar"; } unusedParameters(n: number) { n = 0; // Never read }
برای فعالسازی بررسی یک چنین مواردی باید دو پرچم ذیل را در فایل tsconfig.json به true تنظیم کرد:
{ "compilerOptions": { "noUnusedLocals": true, "noUnusedParameters": true } }
[ts] 'a' is declared but its value is never read. [ts] 'n' is declared but its value is never read.
یافتن خواصی که نباید در یک شیء وجود داشته باشند
در مثال ذیل، خاصیت baz در تعاریف اصلی نوعهای x و y وجود ندارد:
excessPropertyForObjectLiterals() { let x: { foo: number }; x = { foo: 1, baz: 2 }; // Error, excess property 'baz' let y: { foo: number, bar?: number }; y = { foo: 1, baz: 2 }; // Error, excess property 'baz' }
{ "compilerOptions": { "suppressExcessPropertyErrors": false } }
[ts] Type '{ foo: number; baz: number; }' is not assignable to type '{ foo: number; }'. Object literal may only specify known properties, and 'baz' does not exist in type '{ foo: number; }'. (property) baz: number
یافتن breakهای فراموش شده در عبارات switch
در مثال زیر، یک break فراموش شدهاست:
fallthroughCasesInSwitchStatement(a: number) { switch (a) { case 0: break; case 1: a += 1; case 2: a += 2; break; } }
{ "compilerOptions": { "noFallthroughCasesInSwitch": true } }
یافتن ایندکسهای تعریف نشدهی در اشیاء
در مثال زیر، شیء x دارای خاصیت b نیست؛ اما دقیقا با این ایندکس مورد استفاده قرار گرفتهاست:
indexingObjectsLackingIndexSignatures() { const x = { a: 0 }; x["a"] = 1; // ok x["b"] = 1; // Error, type '{ a: number; }' has no index signature. }
{ "compilerOptions": { "suppressImplicitAnyIndexErrors": false } }
[ts] Element implicitly has an 'any' type because type '{ a: number; }' has no index signature.
اجبار به تعریف صریح نوعها در TypeScript
عمدهی قابلیت TypeScript در یافتن خطاها به تعاریف نوعها و راهنمایی کامپایلر آن در این زمینه بر میگردد. اما چون این زبان سازگاری کاملی را با JavaScript دارد، تعریف نوعها در آن اجباری نیست و در این حالت اگر نوعی تعریف نشده باشد، به any تفسیر میشود. جهت اجبار به تعریف نوعها در TypeScript میتوان پرچم noImplicitAny را در فایل tsconfig.json به true تنظیم کرد:
{ "compilerOptions": { "noImplicitAny": true } }
noImplicitAny(args) { // Error: Parameter 'args' implicitly has an 'any' type. console.log(args); }
noImplicitAnyArgs(args: string[]) { // ok with the type information console.log(args); }
یک نکتهی تکمیلی
اگر از دستور ng build --watch برای ساخت برنامههای Angular استفاده میکنید، تغییرات فوق زمانی تاثیر داده خواهند شد که یکبار این برنامه را بسته و مجددا اجرا کنید.
مطالب
Html Encoding
.
.
مقدمه
در دنیای وب دو انکدینگ معروف داریم: Url Encoding و Html Encoding. در هر کدام از این انکدینگها یک عملیات کلی صورت میگیرد: تبدیل کاراکترهای غیرمجاز به عبارات معادل مجاز.
Url Encoding همانطور که از نامش پیداست روشی برای کدکردن Url هاست. مثل عبارت کدشده زیر:
Hello%20world%20,%20hi
درواقع کاراکتر مشخصکننده رشتهای که Url Encoding احتمالا در آن اعمال شده است، همان کاراکتر % است. بحث درباره این نوع انکدینگ کمی مفصل است که خود مطلب جداگانهای میطلبد. (اطلاعات بیشتر)
Html Encoding نیز با توجه به نامش برای انکدینگ عبارات HTML استفاده میشود. مثلا عبارت زیر را درنظر بگیرید:
<html>encoding</html>
این عبارت پس از اعمال عملیات Html Encoding به صورت زیر در خواهد آمد:
<html>encoding</html>
میبینید که در اینجا کاراکترهای > و < به صورت عبارات ;lt& و ;gt& در آمدهاند. شرح کاملی درباره این عبارات معادل (که اصطلاحا به آنها character entity میگویند) در اینجا آورده شده است.
در حالت کلی Html Encoding شامل کدکردن 5 کاراکتر زیر است:
.
کاراکتر | عبارت معادل | توضیحات |
> | > | |
< | < | |
" | " | |
' | ' | یا ;apos& به غیر از IE |
& | & |
نکته: در برخی استانداردها (بیشتر برای XML) برای کاراکتر ' از عبارت ;apos& استفاده میشود. این عبارت جایگزین به غیر از IE در بقیه مرورگرها درست کار میکند.
این کاراکترها درواقع از عناصر اصلی تشکیلدهنده ساختار Html هستند، بنابراین وجود آنها درون یک متن میتواند در روند رندر صفحات html اختلال ایجاد کند. بنابراین با استفاده از Html Encoding و تبدیل این کاراکترها به معادلشان (عباراتی که مرورگرها آنها را میشناسند)، میتوان از نمایش درست این کاراکترها مطمئن شد. البته یکی دیگر از دلایل مهم اعمال این انکدینگ، افزایش امنیت و جلوگیری از حملات XSS است.
فرمت این عبارات معادل به صورت ;entity_name& است. به کل این عبارت اصطلاحا Character Entity گفته میشود. این عبارات با کاراکتر & شروع شده و به یک کاراکتر ; ختم میشوند. کلمه میان این دو کاراکتر نیز عبارت جایگزین (یا همان entity name) هر یک از این کاراکترهاست که در لینک بالا به همراه بسیاری دیگر از کاراکترها اشاره شده است (^).
روش دیگری نیز برای کدکردن کاراکترها با فرمت ;entity_number#& وجود دارد. این entity_number درواقع کد کاراکتر مربوطه در جدول کاراکترست جاری مرورگر است. معمولا این کدها منطبق بر جدول ASCII هستند. برای کاراکترهای خارج از جدول اسکی هم از سایر جداول (مثلا یونیکد) استفاده میشود. عملیات انکدینگ برای کاراکترهای با کد 160 تا 255 (براساس استاندارد ISO-8859-1) با این روش انجام میشود (^). اطلاعات بیشتر راجع به این کدها در اینجا آورده شده است.
خوشبختانه در سمت سرور، در داتنت روشهای گوناگون و قابل اطمینانی برای اعمال این انکدینگ وجود دارد. اما متاسفانه در سمت کلاینت چنین امکاناتی اصلا فراهم نیست و برنامه نویسان خود باید دست به کار شوند. ازآنجاکه امروزه قسمتهای بیشتری از اپلیکیشنهای تحت وب در سمت کلاینت پیاده میشوند و کتابخانههای سمت کلاینت روز به روز پرطرفدارتر میشوند وجود نمونههای مشابه از این متدها در سمت کلاینت میتواند بسیار مفید باشد.
بنابراین تمرکز اصلی ادامه این مطلب بیشتر بر نحوه اعمال این انکدینگ در سمت کلاینت با استفاده از زبان جاوا اسکریپت است.
.
.
Html Encoding در داتنت
در داتنت متدهای متعددی برای اعمال Html Encoding وجود دارد. برخی از آنها صرفا برای اسناد HTML طراحی شدهاند و برخی دیگر یک پیادهسازی کلی دارند و بعضی نیز برای فایلهای XML ارائه شدهاند. این متدها عبارتند از:
- متد System.Security.SecurityElement.Escape: این متد بیشتر برای اعمال این انکدینگ در XML بهکار میرود. در این متد 5 کاراکتر اشاره شده در بالا به عبارات معادل انکد میشوند. البته برای کاراکتر ' از عبارت ;apos& استفاده میشود.
- متدهای موجود در System.Net.WebUtility: متدهای HtmlEncode و HtmlDecode موجود در این کلاس عملیات انکدینگ را انجام میدهند. این کلاس از داتنت 4 اضافه شده است.
- متدهای کلاس System.Web.HttpUtility: در این کلاس از متدهای موجود در کلاس System.Web.Util.HttpEncoder استفاده میشود. در پیادهسازی پیشفرض، متدهای این کلاس از متدهای موجود در کلاس WebUtility استفاده میکنند. البته میتوان با فراهم کردن یک Encoder سفارشی و تنظیم آن در فایل کانفیگ (خاصیت encoderType در قسمت HttpRuntime) این رفتار را تغییر داد. دلیل اصلی جابجایی مکان پیادهسازی این متدها از دات نت 4 به بعد نیز به همین دلیل است. (اطلاعات بیشتر ^ و ^).
- متدهای موجود در System.Web.HttpServerUtility: متدهای HtmlEncode و HtmlDecode موجود در این کلاس مستقیما از متدهای موجود در کلاس HttpUtility استفاده میکنند. خاصیت Server موجود در HttpContext یا در کلاس Page از نوع این کلاس است.
- متدهای موجود در کلاس System.Web.Security.AntiXss.AntiXssEncoder: این کلاس از دات نت 4.5 اضافه شده است. همانطور که از نام این کلاس بر میآید، از HttpEncoder مشتق شده است که در متدهای مرتبط با html encoding تغییراتی در آن اعمال شده است. متدهای این کلاس برای امنیت بیشتر به جای استفاده از Black List از یک White List استفاده میکنند.
درحال حاضر بهترین گزینه موجود برای عملیات انکدینگ، متدهای موجود در کلاس WebUtility هستند. ازآنجاکه این کلاس در فضای System.Net و در کتابخانه System.dll قرار دارد (کتابخانهای که معمولا برای تمام برنامههای داتنتی نیاز است)، بنابراین بارگذاری آن در برنامه نیز بار اضافی بر حافظه تحمیل نمیکند.
پیادهسازی عملیات HtmlEncode کار سختی نیست. مثلا میتوان برای سادگی از متد Replace استفاده کرد. اما برای رشتههای طولانی این متد کارایی مناسبی ندارد. به همین دلیل در تمام پیادهسازیها، معمولا از یک حلقه بر روی تمام کاراکترهای رشته موردنظر برای یافتن کاراکترهای غیرمجاز استفاده میشود. در کدهای متدهای موجود، برای افزایش سرعت حتی از اشارهگر و کدهای unsafe نیز استفاده شده است.
برای افزایش کارایی در تولید رشته نهایی تبدیلشده، بهتر است از یک StringBuilder استفاده شود. در پیادهسازیهای متدهای بالا برای اینکار معمولا از یک TextWriter استفاده میشود. TextWriterهای موجود از کلاس StrigBuilder برای دستکاری رشتهها استفاده میکنند.
صرفا جهت آشنایی بیشتر، پیادهسازی خلاصهشده متد HtmlEncode در کلاس WebUtility در زیر آورده شده است:
public static unsafe void HtmlEncode(string value, TextWriter output) { int index = IndexOfHtmlEncodingChars(value, 0); if (index == -1) { output.Write(value); return; } int cch = value.Length - index; fixed (char* str = value) { char* pch = str; while (index-- > 0) { output.Write(*pch++); } while (cch-- > 0) { char ch = *pch++; if (ch <= '>') { switch (ch) { case '<': output.Write("<"); break; case '>': output.Write(">"); break; case '"': output.Write("""); break; case '\'': output.Write("'"); break; case '&': output.Write("&"); break; default: output.Write(ch); break; } } else if (ch >= 160 && ch < 256) { // The seemingly arbitrary 160 comes from RFC output.Write("&#"); output.Write(((int)ch).ToString(NumberFormatInfo.InvariantInfo)); output.Write(';'); } else { output.Write(ch); } } } } private static unsafe int IndexOfHtmlEncodingChars(string s, int startPos) { int cch = s.Length - startPos; fixed (char* str = s) { for (char* pch = &str[startPos]; cch > 0; pch++, cch--) { char ch = *pch; if (ch <= '>') { switch (ch) { case '<': case '>': case '"': case '\'': case '&': return s.Length - cch; } } else if (ch >= 160 && ch < 256) { return s.Length - cch; } } } return -1; }
در ابتدا بررسی میشود که آیا اصلا متن ورودی حاوی کاراکترهای غیرمجاز است یا خیر. درصورت عدم وجود چنین کاراکترهایی، کار متد با برگشت خود متن ورودی پایان مییابد. درغیراینصورت عملیات انکدینگ آغاز میشود.
همانطور که میبینید عملیات انکدینگ برای 5 کاراکتر اشاره شده به صورت جداگانه انجام میشود و برای کاراکترهای با کد 160 تا 255 (با توجه به توضیحات موجود در مقدمه) نیز با استاندارد ;code#& عملیات تبدیل انجام میشود.در سمت دیگر، پیادهسازی بهینه متد HtmlDecode چندان ساده نیست. چون به جای یافتن یک کاراکتر غیرمجاز باید به دنبال عبارات چند کاراکتری معادل گشت که کاری نسبتا پیچیده است.
اطلاعات و پیادهسازی نسبتا کاملی درباره Html Encoding در سمت سرور در اینجا قابل مشاهده است.
نکته: درصورت نیاز به کدکردن سایر کاراکترها (مثلا کاراکترهای یونیکد) پیادهسازیهای موجود کارا نخواهند بود. بنابراین باید encoder سفارشی خود را تهیه کنید. مثلا میتوانید شرط دوم در بررسی کد کاراکترها را بردارید (منظور قسمت ch < 256) که در اینصورت متد شما محدوده وسیعی را پوشش میدهد. اما دقت کنید که با این تغییر متدی سفارشی برای عملیات decode نیز باید تهیه کنید!
.
.
Html Encoding در جاوا اسکریپت
برای انجام عملیات Url Encoding در جاوا اسکریپت چند متد توکار وجود دارد، که فرایند کلی عملیات همه آنها تقریبا یکسان است. اما متاسفانه برای انجام عملیات Html Encoding متدی در جاوا اسکریپت وجود ندارد. بنابراین متدهای مربوطه باید توسط خود برنامهنویسان پیادهسازی شوند.
یک روش برای اینکار استفاده از لیست اشارهشده در بالا و انجام عملیات replace برای تمام این کاراکترهاست (5 کاراکتر اصلی و درصورت نیاز سایر کاراکترها). این کار میتواند کمی سخت باشد و درواقع پیادهسازی چنین متدی نسبتا مشکل نیز هست (مخصوصا عملیات decode).
اما خوشبختانه امکانی در اسناد html وجود دارد که این کار (مخصوصا Decode کردن) را آسان میکند.
این روش جالب برای انجام عملیات Html Encoding در جاوا اسکریپت، استفاده از یک قابلیت توکار در مرورگرهاست. عناصر DOM (مانند div) دو خاصیت innerText و innerHTML دارند که مرورگرها با توجه به مقادیر تنظیمشده برای هر یک، عملیات coding و decoding مربوطه را به صورت کاملا خودکار انجام داده و مقدار خاصیت دیگر را بهروزرسانی میکنند (دقت کنید که در این دو پراپرتی، کلمه HTML کاملا با حروف بزرگ است، برخلاف Text که تنها حرف اول آن بزرگ است).
برای روشنتر شدن موضوع به مثال زیر برای عملیات encode توجه کنید:
<div id="log"></div> <script type="text/javascript"> var element = document.getElementById('log'); element.innerText = '<html> encoding </html>'; console.log(element.innerHTML); </script>
<html> encoding </html>
عکس این عملیات یعنی decoding نیز با استفاده از کدی مثل زیر امکانپذیر است:
<div id="log"> </div> <script type="text/javascript"> var element = document.getElementById('log'); element.innerHTML = "<html> encoding </html>"; console.log(element.innerText); </script>
<html> encoding </html>
..
.
متد htmlEncode
برای پیادهسازی این متد برای حالت استفاده مستقیم داریم:
String.htmlEncode = function (s) { var el = document.createElement("div"); el.innerText = s || ''; return el.innerHTML; };
در اینجا با استفاده از متد createElement شی document یک المان DOM (در اینجا div) ایجاد شده و سپس با توجه به توضیحات بالا خاصیت innerText آن به مقدار ورودی تنظیم میشود. استفاده از عبارت '' || s در اینجا برای جلوگیری از برگشت عبارات ناخواسته (مثل undefined یا null) برای ورودیهای غیرمجاز است. درنهایت خاصیت innerHTML این المان به عنوان رشته انکدشده برگشت داده میشود.
console.log(String.htmlEncode("<html>")); //result: <html>
و برای حالت استفاده از خاصیت prototype داریم:
String.prototype.htmlEncode = function () { var el = document.createElement("div"); el.innerText = this.toString(); return el.innerHTML; };
console.log("<html>".htmlEncode()); //result: <html>
.
.
متد htmlDecode
با استفاده از مطالب اشارهشده در بالا، پیادهسازی این متد به صورت زیر است:
String.htmlDecode = function (s) { var el = document.createElement("div"); el.innerHTML = s || ''; return el.innerText; };
String.prototype.htmlDecode = function () { var el = document.createElement("div"); el.innerHTML = this.toString(); return el.innerText; };
نحوه استفاده از این متدها هم به صورت زیر است:
console.log(String.htmlDecode("<html>")); console.log("<html>".htmlDecode());
.
.
پیادهسازی با استفاده از jQuery
درصورت در دسترس بودن کتابخانه jQuery، کار پیادهسازی این متدها بسیار سادهتر خواهد شد. برای اینکار میتوان از متدهای زیر استفاده کرد:
.
- متد htmlEncode:
String.htmlEncode = function (s) { return $('<div/>').text(value).html(); }; String.prototype.htmlEncode = function () { return $('<div/>').text(this.toString()).html(); };
- متد htmlDecode:
String.htmlDecode = function (s) { return $('<div/>').html(s).text(); }; String.prototype.htmlDecode = function () { return $('<div/>').html(this.toString()).text(); };
.
.
نکات پایانی
1. با اینکه به نظر میرسد در متدهای ارائه شده در بالا، بین نسخههای معمولی و نسخه مخصوص jQuery تفاوتی وجود ندارد اما تست زیر نشان میدهد که نکات ریزی باعث بهوجود آمدن برخی تفاوتها میشود. رشته زیر را درنظر بگیرید:
var value = "a \n b";
با استفاده از متد htmlEncode معمولی نشان داده شده در بالا، عبارت انکدشده رشته فوق به صورت زیر خواهد بود:
"a <br> b"
میبینید که به صورت هوشمندانهای! مقدار n\ به تگ <br> انکد شده است. اما اگر با استفاده از متد نوشته شده با jQuery سعی به انکدکردن این رشته کنیم، میبینیم که مقدار n\ بدین صورت انکد نمیشود! حال کدام روش درست و استاندارد است؟
در ابتدای این مطلب هم اشاره شده بود که Html Encoding برای کدکردن یکسری کاراکتر غیرمجاز در متون موجود در صفحات HTML بکار میرود و معمولا همان 5 کاراکتر اشارهشده در بالا به عنوان کاراکترهای اصلی غیرمجاز به حساب میآیند. کاراکتر n\ از این نوع کاراکترها محسوب نمیشود. همچنین ازآنجاکه عملیات عکس این تبدیل در Decode مربوطه صورت نمیگیرد، تبدیل این کاراکتر به معادلش در html اصلا کاری منطقی نیست و باعث خراب شدن متن موردنظر میشود.
با استفاده از متدهای HtmlEncode موجود در کلاسهای دات نت (WebUtility و HtmlUtility که در بالا به آنها اشاره شده بود) عملیات انکدینگ برای این رشته تکرار شد و نتیجه حاصله نشان داد که عبارت n\ در خروجی این متدها نیز انکد نمیشود. بنابراین متد نوشته شده با استفاده از jQuery خروجیهای استانداردتری ارائه میدهد.
با کمی تحقیق و بررسی کدهای jQuery مشخص شد که دلیل این تفاوت، در استفاده از متد createTextNode از شی document در متد ()text است. بنابراین برای بهبود متد htmlEncode اولیه داریم:
String.htmlEncode = function (s) { var el = document.createElement("div"); var txt = document.createTextNode(s); el.appendChild(txt); return el.innerHTML; };
.
.
2. نکته مهم دیگری که باید بدان توجه داشت برقراری اصل مهم زیر در عملیات انکدینگ است:
String.htmlDecode(String.htmlEncode(myString)) === myString;
var myString = "<HTML>"; String.htmlDecode(String.htmlEncode(myString)) === myString; // result: true // -------------------------------------------------------------------------- myString = "<اچ تی ام ال>"; String.htmlDecode(String.htmlEncode(myString)) === myString; // result: true
myString = "a \r b"; String.htmlDecode(String.htmlEncode(myString)) === myString; // result: false
پس از کمی تحقیق و بررسی بیشتر مشخص شد که مرورگرها در تبدیل کاراکترها، کاراکتر carriage return (یا CR یا همان r\ با کد اسکی 13 یا 0D) را تبدیل به کاراکتر line feed (یا LF یا n\ با کد اسکی 10 یا 0A) میکنند. برای آزمایش این نکته میتوانید از سه خط زیر استفاده کنید:
console.log(escape(String.htmlDecode('\r'))); // result: %0A : it is url encode of character '\n' console.log(escape(String.htmlDecode('\n'))); // result: %0A console.log(escape(String.htmlDecode('\r\n'))); // result: %0A
با بررسی بیشتر مشخص شد که این تبدیل به محض مقداردهی به یکی از خاصیتهای یک عنصر DOM صورت میگیرد. برای مثال کد زیر را در مرورگرهای مختلف امتحان کنید:
var el = document.createElement('div'); el.innerText = '\r'; console.log(escape(el.innerText)); // result: %0A el.innerHTML = '\r'; console.log(escape(el.innerHTML)); // result: %0A console.log(escape('\r')); // result: %0D
با بررسی هایی که من کردم دلیل و یا راهحلی برای این مشکل پیدا نکردم!
بنابراین در استفاده از این متدها باید این نکته را مدنظر قرار داد. ازآنجاکه این مشکل حالتی به خصوص دارد نمیتوان راهحلی کلی برای آن ارائه داد. پس برای موقعیتهای گوناگون با توجه به زوایای روشنشده از این مشکل باید به دنبال راهحل مناسب بود.
البته ممکن است این اشکال درمورد کاراکترهای دیگری هم وجود داشته باشد که من به آن برخورد نکرده باشم (با درنظر گرفتن تفاوت میان مرورگرهای مختلف ممکن است پیچیدهتر هم باشد).
نکته: ازآنجاکه برای رفع این مشکل، پیادهسازی متد htmlDecode به این کاملی، با عدم استفاده از ویژگی پراپرتیهای innerHTML و innerText، کاری نسبتا سخت و پیچیده و طولانی است، بنابراین در بیشتر حالات میتوان از این مشکل صرفنظر کرد! به همین دلیل در اینجا نیز متد دیگری برای رفع این مشکل ارائه نمیشود!
.
.
3. یک مشکل دیگر که این متدها دارند این است که متاسفانه در متد htmlEncode، از 5 کاراکتر معروف بالا، کاراکترهای ' و " در این متدها اصلا تبدیل نمیشوند. همچنین سایر کاراکترهای عنواندار یا کاراکترهای خارج از جدول ASCII (مثلا کاراکترهای با کد 160 تا 255 یا کاراکترهای یونیکد) نیز که معمولا انکد میشوند در این متد تغییری نمیکنند و به همان صورت برگشت داده میشوند.
هرچند متد htmlDecode نشان داده شده در این مطلب، بهدرستی تمامی عبارات معادل (حتی عبارات معادل غیر از 5 کاراکتر نشان داده شده در بالا با هر دو استاندارد ;character-entity& و ;code#&) را تبدیل کرده و کاراکتر درست را برمیگرداند.
برای اصلاح این مشکل میتوان متد htmlEncode را کاملا به صورت دستی و مستقیم نوشت و اعمال انکدینگهای موردنیاز را با استفاده یک حلقه روی تمام کاراکترها متن موردنظر انجام داد. چیزی شبیه به کد زیر:
String.htmlEncode = function (text) { text = text || ''; var encoded = ''; for (var i = 0; i < text.length; i++) { var c = text[i]; switch (c) { case '<': encoded += '<'; break; case '>': encoded += '>'; break; case '&': encoded += '&'; break; case '"': encoded += '"'; break; case "'": encoded += '''; break; default: // the upper limit can be removed to support more chars... var code = c.charCodeAt(); if (code >= 160 & code < 256) encoded += '&#' + code + ';'; else encoded += c; } } return encoded; };
.
.
کتابخانههای موجود
هرچند توضیحات ارائه شده در این مطلب کافی هستند، اما صرفا برای آشنایی با سایر کتابخانههای موجود، روشهای استفادهشده در آنها و نقایص و مزایای آنها این قسمت اضافه شده است.
.
Prototype: این کتابخانه شامل مجموعهای از متدهای کمکی برای راحتی کار در سمت کلاینت است. برای عملیات html encoding دو متد escapeHTML و unescapeHTML دارد که به صورت زیر پیاده شدهاند:
function escapeHTML() { return this.replace(/&/g, '&').replace(/</g, '<').replace(/>/g, '>'); } function unescapeHTML() { return this.stripTags().replace(/</g, '<').replace(/>/g, '>').replace(/&/g, '&'); }
همانطور که میبینید در این متدها از replace استفاده شده است که برای متنهای طولانی کندتر از روشهای نشان دادهشده در این مطلب است. همچنین عملیات انکد و دیکد را تنها برای 3 کاراکتر < و > و & انجام میدهد که نقص بزرگی محسوب میشود.
.
jQuery.string: این پلاگین حاوی چند متد برای کار با رشتههاست که یکی از این متدها با نام htmlspecialchars مخصوص عملیات انکدینگ است. در این متد تنها همان 5 کاراکتر اصلی تبدیل میشوند. متاسفانه متدی برای decode در این پلاگین وجود ندارد. پیادهسازی خلاصهشده این کتابخانه تنها برای نمایش نحوه عملکرد متد فوق به صورت زیر است:
var andExp = /&/g, htmlExp = [/(<|>|")/g, /(<|>|')/g, /(<|>|'|")/g], htmlCharMap = { '<': '<', '>': '>', "'": ''', '"': '"' }, htmlReplace = function (all, $1) { return htmlCharMap[$1]; }; $.extend({ // convert special html characters htmlspecialchars: function (string, quot) { return string.replace(andExp, '&').replace(htmlExp[quot || 0], htmlReplace); } });
$.htmlspecialchars("<div>");
string.$: پلاگین دیگری برای jQuery که عملیات مربوط به رشتهها را دربر دارد. در این پلاگین برای عملیات انکدینگ دو متد escapeHTML و unescapeHTML به صورت زیر تعریف شدهاند:
this.escapeHTML = function (s) { this.str = this.s(s) .split('&').join('&') .split('<').join('<') .split('>').join('>'); return this; }; this.unescapeHTML = function (s) { this.str = this.stripTags(this.s(s)).str.replace(/&/g, '&').replace(/</g, '<').replace(/>/g, '>'); return this; };
همانطور که میبنید در متد encode این پلاگین از یک روش جالب اما به نسبت ناکارآمد در رشتههای طولانی، برای استخراج کاراکترهای غیرمجاز استفاده شده است. در این متدها هم تنها 3 کاراکتر & و < و > انکد و دیکد میشوند.
.
encoder.js: کتابخانه نسبتا کاملی برای عملیات انکدینگ رشتهها در سمت کلاینت. این کتابخانه علاوه بر encode و decode رشتهها متدهایی برای تبدیل html entityها به فرمت عددیشان و برعکس، حذف کاراکترهای یونیکد، بررسی اینکه رشته ورودی شامل کاراکترهای انکد شده است، جلوگیری از انکدینک مجدد یک رشته و ... نیز دارد.
. .
htmlEncode: این متد پیادهسازی کاملی برای اجرای عملیات Html Encode دارد و محدوده وسیعی از کاراکترها را نیز تبدیل میکند. مشاهده عملیات موجود در این متد برای آشنایی با مطالب ظریفتر پیشنهاد میشود.
.
.
منابع برای مطالعه بیشتر
در قسمت قبل، با نحوهی رندر سمت سرور و روش فعالسازی قابلیتهای تعاملی در این حالت، آشنا شدیم. از این نکات میتوان جهت ارتقاء ساختار پروژههای قدیمی Blazor Server به Blazor Server 8x استفاده کرد. البته همانطور که پیشتر نیز عنوان شد، در دات نت 8 دیگر خبری از قالبهای قدیمی پروژههای blazor server و blazor wasm نیست و اگر دقیقا همین موارد مدنظر هستند، آنها را میتوان با تنظیم سطح رندر و میزان تعاملی که مدنظر است، شبیه سازی کرد و یا حتی هر دو را هم با هم در یک پروژه داشت.
1) بهروز رسانی شماره نگارش داتنت
اولین قدم در جهت ارتقاء پروژههای قدیمی، تغییر شماره نگارش TargetFramework موجود در فایل csproj. به net8.0 است. پس از اینکار نیاز است تمام بستههای نیوگت موجود را نیز به نگارشهای جدیدتر آنها ارتقاء دهید.
2) فعالسازی حالت SSR تعاملی سمت سرور
پایهی تمام تغییرات انجام شدهی در Blazor 8x، قابلیت SSR است و تمام امکانات دیگر برفراز آن اجرا میشوند. به همین جهت پس از ارتقاء شماره نگارش داتنت، نیاز است SSR را فعال کنیم و برای اینکار باید به هاست ASP.NET Core بگوئیم که درخواستهای رسیده را به کامپوننتهای Razor هدایت کند. بنابراین، به فایل Program.cs مراجعه کرده و دو تغییر زیر را به آن اعمال کنید:
یک نمونهی کامل از فایل Program.cs را در قسمت قبل مشاهده کردید و یا حتی میتوانید دستور dotnet new blazor --interactivity Server را جهت ساخت یک پروژهی آزمایشی جدید بر اساس SDK دات نت 8 و ایده گیری از آن، اجرا کنید.
در اینجا ترکیب کامپوننتهای تعاملی سمت سرور (AddInteractiveServerComponents) و رندر تعاملی سمت سرور (AddInteractiveServerRenderMode)، دقیقا همان Blazor Server قدیمی است که ما با آن آشنا هستیم.
یک نکته: اگر از قالب جدید dotnet new blazor --interactivity None استفاده کنیم، یعنی حالت تعاملی بودن آنرا به None تنظیم کنیم، کلیات ساختار پروژهای را که مشاهده خواهیم کرد، با حالت تعاملی Server آن یکی است؛ فقط در تنظیمات Program.cs آن، گزینههای فوق را نداریم و به صورت زیر ساده شدهاست:
در این نوع برنامهها نمیتوان جزایر/قسمتهای تعاملی Blazor Server را در صفحات و کامپوننتهای SSR، تعریف کرد. در مورد جزایر تعاملی، در مطالب بعدی بیشتر بحث خواهیم کرد.
3) ایجاد فایل جدید App.razor
در دات نت 8، دیگر خبری از فایل آغازین Host.cshtml_ پروژههای Blazor Server قدیمی نیست و کدهای آن با تغییراتی، به فایل جدید App.razor منتقل شدهاند. در این قسمت، کار هدایت درخواستهای رسیده به کامپوننتهای برنامه رخ میدهد و از این پس، صفحهی ریشهی برنامه خواهد بود.
در این تصویر، مقایسهای را بین جریان پردازش یک درخواست رسیده در دات نت 8، با نگارش قبلی Blazor Server مشاهده میکنید. در دات نت 8، فایل Host.cshtml_ (یک Razor Page آغازین برنامه) با یک کامپوننت Razor به نام App.razor جایگزین شدهاست و فایل قدیمی App.razor این پروژهها به Routes.razor، تغییر نام یافتهاست.
نمونهای از فایل App.razor جدید را که در قسمت قبل نیز معرفی کردیم، در اینجا با جزئیات بیشتری بررسی میکنیم:
در این فایل جدید تغییرات زیر رخ دادهاند:
- تمام دایرکتیوهای تعریف شده مانند page ،@addTagHelper@ و غیره حذف شدهاند.
- base href تعریف شده اینبار فقط با یک / شروع میشود و نه با /~. این مورد خیلی مهم است! اگر به آن دقت نکنید، هیچکدام از فایلهای استاتیک برنامه مانند فایلهای css. و js.، بارگذاری نخواهند شد!
- پیشتر برای رندر HeadOutlet، از یک تگهلپر استفاده میشد. این مورد در نگارش جدید با یک کامپوننت ساده جایگزین شدهاست.
- تمام component tag helperهای پیشین حذف شدهاند و نیازی به آنها نیست.
- ارجاع پیشین فایل blazor.server.js با فایل جدید blazor.web.js جایگزین شدهاست.
یک نکته: همانطور که مشاهده میکنید، فایل App.razor یک کامپوننت است و اینبار به همراه تگ <script> نیز شدهاست. یعنی در این نگارش از Blazor میتوان اسکریپتها را در کامپوننتها نیز ذکر کرد؛ فقط با یک شرط! این کامپوننت حتما باید SSR باشد. اگر این تگ اسکریپتی را در یک کامپوننت تعاملی ذکر کنید، همانند قابل (و نگارشهای پیشین Blazor) با خطا مواجه خواهید شد.
4) ایجاد فایل جدید Routes.razor و مدیریت سراسری خطاها و صفحات یافت نشده
همانطور که عنوان شد، فایل قدیمی App.razor این پروژهها به Routes.razor تغییر نام یافتهاست که درج آنرا در قسمت body مشاهده میکنید. محتوای این فایل نیز به صورت زیر است:
این محتوای جدید، فاقد ذکر کامپوننت NotFound قبلی است؛ از این جهت که سیستم مسیریابی جدید Blazor 8x با ASP.NET Core 8x یکپارچه است و نیازی به این کامپوننت نیست. یعنی اگر قصد مدیریت آدرسهای یافت نشدهی برنامه را دارید، باید همانند ASP.NET Core به صورت زیر در فایل Program.cs عمل کرده:
و سپس کامپوننت جدید StatusCode.razor را برای مدیریت آن به نحو زیر به برنامه اضافه کنید و بر اساس responseCode دریافتی، واکنشهای متفاوتی را ارائه دهید:
یک نکته: اگر پروژهای را بر اساس قالب dotnet new blazor --interactivity Server ایجاد کنیم، در فایل Program.cs آن، چنین تنظیمی اضافه شدهاست:
که دقیقا معادل رفتاری است که در برنامههای ASP.NET Core قابل مشاهدهاست. این مسیر Error/، به کامپوننت جدید Components\Pages\Error.razor نگاشت میشود. بنابراین اگر در برنامههای جدید Blazor Server، استثنائی رخ دهد، با استفاده از میانافزار ExceptionHandler فوق، کامپوننت Error.razor نمایش داده خواهد شد. باید دقت داشت که این کامپوننت ویژه، تحت هر شرایطی در حالت یک static server component رندر میشود.
سؤال: در اینجا (برنامههای Blazor Server) چه تفاوتی بین UseExceptionHandler و UseStatusCodePagesWithRedirects وجود دارد؟
میانافزار UseExceptionHandler برای مدیریت استثناءهای آغازین برنامه، پیش از تشکیل اتصال دائم SignalR وارد عمل میشود. پس از آن و تشکیل اتصال وبسوکت مورد نیاز، فقط از میانافزار UseStatusCodePagesWithRedirects استفاده میکند.
اگر علاقمند نیستید تا تمام خطاهای رسیده را همانند مثال فوق در یک صفحه مدیریت کنید، میتوانید حداقل سه فایل زیر را به برنامه اضافه کنید تا خطاهای متداول یافت نشدن آدرسی، بروز خطایی و یا عدم دسترسی را مدیریت کنند:
5) تعاملی کردن سراسری برنامه
پس از این تغییرات اگر برنامه را اجرا کنید، بر اساس روش جدید static server-side rendering کار میکند و تعاملی نیست. یعنی تمام کامپوننتهای آن به صورت پیشفرض، یکبار بر روی سرور رندر شده و خروجی آنها به مرورگر کاربر ارسال میشوند و هیچ اتصال دائم SignalR ای برقرار نخواهد شد. برای فعالسازی سراسری قابلیتهای تعاملی برنامه و بازگشت به حالت Blazor Server قبلی، به فایل App.razor مراجعه کرده و دو تغییر زیر را اعمال کنید تا به صورت خودکار به تمام زیرکامپوننتها، یعنی کل برنامه، اعمال شود:
نکته 1: اجرای دستور زیر در داتنت 8، قالب پروژهای را ایجاد میکند که رفتار آن همانند پروژههای Blazor Server نگارشهای قبلی داتنت است (این مورد را در قسمت قبل بررسی کردیم)؛ یعنی همهجای آن به صورت پیشفرض، تعاملی است:
نکته 2: البته ... InteractiveServer، دقیقا همان حالت پیشفرض برنامههای Blazor Server قبلی نیست! این حالت رندر، به صورت پیشفرض به همراه پیشرندر (pre-rendering) هم هست. یعنی در این حالت، روال رویدادگردان OnInitializedAsync یک کامپوننت، دوبار فراخوانی میشود (که باید به آن دقت داشت و عدم توجه به آن میتواند سبب انجام دوبارهی کارهای سنگین آغازین یک کامپوننت شود)؛ یکبار برای پیشرندر صفحه به صورت یک HTML استاتیک (بدون فعال سازی هیچ قابلیت تعاملی) که برای موتورهای جستجو و بهبود SEO مفید است و بار دیگر برای فعالسازی قسمتهای تعاملی آن، درست پس از زمانیکه اتصال SignalR صفحه، برقرار شد (البته امکان فعالسازی حالت پیشرندر در Blazor Server قبلی هم وجود داشت؛ ولی مانند Blazor 8x، به صورت پیشفرض فعال نبود). در صورت نیاز، برای سفارشی سازی و لغو آن میتوان به صورت زیر عمل کرد:
در مورد پیشرندر و روش مدیریت دوبار فراخوانی شدن روال رویدادگردان OnInitializedAsync یک کامپوننت در این حالت، در قسمتهای بعدی این سری بیشتر بحث خواهد شد.
1) بهروز رسانی شماره نگارش داتنت
اولین قدم در جهت ارتقاء پروژههای قدیمی، تغییر شماره نگارش TargetFramework موجود در فایل csproj. به net8.0 است. پس از اینکار نیاز است تمام بستههای نیوگت موجود را نیز به نگارشهای جدیدتر آنها ارتقاء دهید.
2) فعالسازی حالت SSR تعاملی سمت سرور
پایهی تمام تغییرات انجام شدهی در Blazor 8x، قابلیت SSR است و تمام امکانات دیگر برفراز آن اجرا میشوند. به همین جهت پس از ارتقاء شماره نگارش داتنت، نیاز است SSR را فعال کنیم و برای اینکار باید به هاست ASP.NET Core بگوئیم که درخواستهای رسیده را به کامپوننتهای Razor هدایت کند. بنابراین، به فایل Program.cs مراجعه کرده و دو تغییر زیر را به آن اعمال کنید:
// ... builder.Services.AddRazorComponents().AddInteractiveServerComponents(); // ... app.MapRazorComponents<App>().AddInteractiveServerRenderMode();
در اینجا ترکیب کامپوننتهای تعاملی سمت سرور (AddInteractiveServerComponents) و رندر تعاملی سمت سرور (AddInteractiveServerRenderMode)، دقیقا همان Blazor Server قدیمی است که ما با آن آشنا هستیم.
یک نکته: اگر از قالب جدید dotnet new blazor --interactivity None استفاده کنیم، یعنی حالت تعاملی بودن آنرا به None تنظیم کنیم، کلیات ساختار پروژهای را که مشاهده خواهیم کرد، با حالت تعاملی Server آن یکی است؛ فقط در تنظیمات Program.cs آن، گزینههای فوق را نداریم و به صورت زیر ساده شدهاست:
// ... builder.Services.AddRazorComponents(); // ... app.MapRazorComponents<App>();
3) ایجاد فایل جدید App.razor
در دات نت 8، دیگر خبری از فایل آغازین Host.cshtml_ پروژههای Blazor Server قدیمی نیست و کدهای آن با تغییراتی، به فایل جدید App.razor منتقل شدهاند. در این قسمت، کار هدایت درخواستهای رسیده به کامپوننتهای برنامه رخ میدهد و از این پس، صفحهی ریشهی برنامه خواهد بود.
در این تصویر، مقایسهای را بین جریان پردازش یک درخواست رسیده در دات نت 8، با نگارش قبلی Blazor Server مشاهده میکنید. در دات نت 8، فایل Host.cshtml_ (یک Razor Page آغازین برنامه) با یک کامپوننت Razor به نام App.razor جایگزین شدهاست و فایل قدیمی App.razor این پروژهها به Routes.razor، تغییر نام یافتهاست.
نمونهای از فایل App.razor جدید را که در قسمت قبل نیز معرفی کردیم، در اینجا با جزئیات بیشتری بررسی میکنیم:
<!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <base href="/" /> <link rel="stylesheet" href="bootstrap/bootstrap.min.css" /> <link rel="stylesheet" href="app.css" /> <link rel="stylesheet" href="MyApp.styles.css" /> <link rel="icon" type="image/png" href="favicon.png" /> <HeadOutlet /> </head> <body> <Routes /> <script src="_framework/blazor.web.js"></script> </body> </html>
- تمام دایرکتیوهای تعریف شده مانند page ،@addTagHelper@ و غیره حذف شدهاند.
- base href تعریف شده اینبار فقط با یک / شروع میشود و نه با /~. این مورد خیلی مهم است! اگر به آن دقت نکنید، هیچکدام از فایلهای استاتیک برنامه مانند فایلهای css. و js.، بارگذاری نخواهند شد!
- پیشتر برای رندر HeadOutlet، از یک تگهلپر استفاده میشد. این مورد در نگارش جدید با یک کامپوننت ساده جایگزین شدهاست.
- تمام component tag helperهای پیشین حذف شدهاند و نیازی به آنها نیست.
- ارجاع پیشین فایل blazor.server.js با فایل جدید blazor.web.js جایگزین شدهاست.
یک نکته: همانطور که مشاهده میکنید، فایل App.razor یک کامپوننت است و اینبار به همراه تگ <script> نیز شدهاست. یعنی در این نگارش از Blazor میتوان اسکریپتها را در کامپوننتها نیز ذکر کرد؛ فقط با یک شرط! این کامپوننت حتما باید SSR باشد. اگر این تگ اسکریپتی را در یک کامپوننت تعاملی ذکر کنید، همانند قابل (و نگارشهای پیشین Blazor) با خطا مواجه خواهید شد.
4) ایجاد فایل جدید Routes.razor و مدیریت سراسری خطاها و صفحات یافت نشده
همانطور که عنوان شد، فایل قدیمی App.razor این پروژهها به Routes.razor تغییر نام یافتهاست که درج آنرا در قسمت body مشاهده میکنید. محتوای این فایل نیز به صورت زیر است:
<Router AppAssembly="@typeof(Program).Assembly"> <Found Context="routeData"> <RouteView RouteData="@routeData" DefaultLayout="@typeof(Layout.MainLayout)" /> <FocusOnNavigate RouteData="@routeData" Selector="h1" /> </Found> </Router>
app.UseStatusCodePagesWithRedirects("/StatusCode/{0}");
@page "/StatusCode/{responseCode}" <h3>StatusCode @ResponseCode</h3> @code { [Parameter] public string? ResponseCode { get; set; } }
یک نکته: اگر پروژهای را بر اساس قالب dotnet new blazor --interactivity Server ایجاد کنیم، در فایل Program.cs آن، چنین تنظیمی اضافه شدهاست:
if (!app.Environment.IsDevelopment()) { app.UseExceptionHandler("/Error", createScopeForErrors: true); }
سؤال: در اینجا (برنامههای Blazor Server) چه تفاوتی بین UseExceptionHandler و UseStatusCodePagesWithRedirects وجود دارد؟
میانافزار UseExceptionHandler برای مدیریت استثناءهای آغازین برنامه، پیش از تشکیل اتصال دائم SignalR وارد عمل میشود. پس از آن و تشکیل اتصال وبسوکت مورد نیاز، فقط از میانافزار UseStatusCodePagesWithRedirects استفاده میکند.
اگر علاقمند نیستید تا تمام خطاهای رسیده را همانند مثال فوق در یک صفحه مدیریت کنید، میتوانید حداقل سه فایل زیر را به برنامه اضافه کنید تا خطاهای متداول یافت نشدن آدرسی، بروز خطایی و یا عدم دسترسی را مدیریت کنند:
404.razor
@page "/StatusCode/404" <PageTitle>Not found</PageTitle> <h1>Not found</h1> <p role="alert">Sorry, there's nothing at this address.</p>
500.razor
@page "/StatusCode/500" <PageTitle>Unexpected error</PageTitle> <h1>Unexpected error</h1> <p role="alert">There was an unexpected error.</p>
401.razor
@page "/StatusCode/401" <PageTitle>Not Authorized</PageTitle> <h1>Not Authorized</h1> <p role="alert">Sorry, you are not authorized to access this page.</p>
5) تعاملی کردن سراسری برنامه
پس از این تغییرات اگر برنامه را اجرا کنید، بر اساس روش جدید static server-side rendering کار میکند و تعاملی نیست. یعنی تمام کامپوننتهای آن به صورت پیشفرض، یکبار بر روی سرور رندر شده و خروجی آنها به مرورگر کاربر ارسال میشوند و هیچ اتصال دائم SignalR ای برقرار نخواهد شد. برای فعالسازی سراسری قابلیتهای تعاملی برنامه و بازگشت به حالت Blazor Server قبلی، به فایل App.razor مراجعه کرده و دو تغییر زیر را اعمال کنید تا به صورت خودکار به تمام زیرکامپوننتها، یعنی کل برنامه، اعمال شود:
<HeadOutlet @rendermode="@InteractiveServer" /> ... <Routes @rendermode="@InteractiveServer" />
نکته 1: اجرای دستور زیر در داتنت 8، قالب پروژهای را ایجاد میکند که رفتار آن همانند پروژههای Blazor Server نگارشهای قبلی داتنت است (این مورد را در قسمت قبل بررسی کردیم)؛ یعنی همهجای آن به صورت پیشفرض، تعاملی است:
dotnet new blazor --interactivity Server --all-interactive
نکته 2: البته ... InteractiveServer، دقیقا همان حالت پیشفرض برنامههای Blazor Server قبلی نیست! این حالت رندر، به صورت پیشفرض به همراه پیشرندر (pre-rendering) هم هست. یعنی در این حالت، روال رویدادگردان OnInitializedAsync یک کامپوننت، دوبار فراخوانی میشود (که باید به آن دقت داشت و عدم توجه به آن میتواند سبب انجام دوبارهی کارهای سنگین آغازین یک کامپوننت شود)؛ یکبار برای پیشرندر صفحه به صورت یک HTML استاتیک (بدون فعال سازی هیچ قابلیت تعاملی) که برای موتورهای جستجو و بهبود SEO مفید است و بار دیگر برای فعالسازی قسمتهای تعاملی آن، درست پس از زمانیکه اتصال SignalR صفحه، برقرار شد (البته امکان فعالسازی حالت پیشرندر در Blazor Server قبلی هم وجود داشت؛ ولی مانند Blazor 8x، به صورت پیشفرض فعال نبود). در صورت نیاز، برای سفارشی سازی و لغو آن میتوان به صورت زیر عمل کرد:
@rendermode InteractiveServerRenderModeWithoutPrerendering @code{ static readonly IComponentRenderMode InteractiveServerRenderModeWithoutPrerendering = new InteractiveServerRenderMode(false); }
در مورد پیشرندر و روش مدیریت دوبار فراخوانی شدن روال رویدادگردان OnInitializedAsync یک کامپوننت در این حالت، در قسمتهای بعدی این سری بیشتر بحث خواهد شد.
هدف از زیر ساخت بومی سازی در ASP.NET Core، حذف عبارات و رشتههای درج شدهی در کلاسها و ویووهای مختلف برنامه و انتقال آنها به فایلهای منبع resx است و سپس استفادهی از آنها توسط تزریق وابستگیها. به این ترتیب میتوان بر اساس نوع فرهنگ درخواستی کاربر جاری، رشتههای درج شده را به صورت پویا، در زمان اجرای برنامه، بر اساس ترجمههای آنها به کاربر نمایش داد.
نحوهی تعیین فرهنگ ترد جاری در ASP.NET Core
در نگارشهای پیشین ASP.NET، برای تعیین فرهنگ ترد جاری، از یکی از دو روش ذیل استفاده میشود:
الف) افزودن مدخل بومی سازی به فایل web.config
ب) و یا تعیین فرهنگ ترد با کدنویسی مستقیم در فایل global.asax
در ASP.NET Core با حذف شدن System.Web و همچنین فایل global.asax، برای تعیین فرهنگ پیش فرض ترد جاری، به همراه فرهنگهایی که برنامه از آنها پشتیبانی میکند، به صورت ذیل عمل میشود:
در اینجا با مراجعه به کلاس آغازین برنامه و افزودن تنظیمات میان افزار RequestLocalization، میتوان فرهنگ پیش فرض درخواست جاری و یا فرهنگهای پشتیبانی شده را مشخص کرد.
- تنظیمات SupportedCultures بر روی نمایش تاریخ، ساعت و واحد پولی تاثیر دارند. همچنین میتوانند بر روی نحوهی مقایسهی حروف و مرتب سازی آنها تاثیر داشته باشند.
- تنظیمات SupportedUICultures مشخص میکنند که کدامیک از فایلهای resx برنامه که مداخل ترجمههای آنرا به زبانهای مختلف مشخص میکنند، باید بارگذاری شوند.
- تنظیم DefaultRequestCulture در صورت مشخص نشدن فرهنگ ترد جاری مورد استفاده قرار میگیرد.
یک مثال: هر ترد در دات نت دارای اشیاء CurrentCulture و CurrentUICulture است. اگر فرهنگ ترد جاری به en-US تنظیم شده باشد، متد DateTime.Now.ToLongDateString، خروجی نمونه Thursday, February 18, 2016 را نمایش میدهد.
زمانیکه میان افزار RequestLocalization فعال میشود، سه تامین کنندهی پیش فرض (مقدارهای پیش فرض خاصیت RequestCultureProviders شیء RequestLocalizationOptions فوق)، جهت مشخص ساختن فرهنگ ترد جاری بکار گرفته خواهند شد:
الف) از طریق کوئری استرینگ با فعال سازی QueryStringRequestCultureProvider
http://localhost:5000/?culture=es-MX&ui-culture=es-MX
http://localhost:5000/?culture=es-MX
برای مثال در اینجا QueryStringRequestCultureProvider به دنبال کوئری استرینگهای culture و یا ui-culture گشته و با رسیدن به es-MX، فرهنگ جاری را به اسپانیایی مکزیکی تنظیم میکند. در این حالت اگر فقط culture ذکر شود، ui-culture نیز به همان مقدار تنظیم خواهد شد.
ب) از طریق نام کوکی با فعال سازی CookieRequestCultureProvider
CookieRequestCultureProvider کوکی ویژهای را با نام پیش فرض AspNetCore.Culture. ایجاد میکند. این کوکی برای ردیابی اطلاعات بومی سازی انتخابی کاربر بکار میرود. برای مثال اگر به مقدار ذیل تنظیم شود:
c آن به معنای culture و uic آن به معنای ui-culture خواهد بود.
ج) از طریق هدر مخصوص Accept-Language با فعال سازی AcceptLanguageHeaderRequestCultureProvider که میتواند به همراه درخواست HTTP ارسال شود.
اگر تمام این حالتها تنظیم نشده بودند، آنگاه از مقدارDefaultRequestCulture استفاده میشود. برای مثال اگر مرورگر به صورت پیش فرض هدر Accept-Language را en-US ارسال میکند :
دیگر کار به پردازش مقدارDefaultRequestCulture نخواهد رسید.
اکنون اگر علاقمند بودید تا به کاربر امکان انتخاب زبانی را بدهید، یک چنین اکشن متدی را طراحی کنید:
این اکشن متد بر اساس تامین کنندهی کوکی ردیابی زبان انتخاب شدهی توسط کاربر و یا CookieRequestCultureProvider کار میکند و توسط آن، فرهنگ جاری برنامه به زبان فارسی تنظیم میشود. هرگاه که این اکشن متد فراخوانی شود، کوکی AspNetCore.Culture. به مقدار c=fa-IR|uic=fa-IR تنظیم میشود:
از اینجا به بعد است که اگر نام کنترلر شما TestLocalController باشد، فایل منبع متناظر با آن یعنی Controllers.TestLocalController.fa.resx، به صورت خودکار بارگذاری و پردازش خواهد شد. در غیر اینصورت فایل نمونهی ختم شدهی به en.resx پردازش میشود؛ چون این زبان به صورت پیش فرض در هدر Accept-Language قید شدهاست.
آماده سازی برنامه برای کار با فایلهای منبع زبانهای مختلف
ابتدا پوشهی جدیدی را به نام Resources به ریشهی پروژه اضافه کنید. سپس به کلاس آغازین برنامه مراجعه کرده و محل یافت شدن این پوشه را معرفی کنید:
در اینجا سرویس جدید Localization، به لیست سرویسهای ثبت شدهی در IoC Container اضافه میشود. همچنین توسط خاصیت ResourcesPath آن مشخص شدهاست که فایلهای resx را باید از کجا دریافت کند.
به علاوه به سرویس ASP.NET MVC، تنظیمات بومی سازی Viewها و DataAnnotations نیز اضافه شدهاند. تنظیم suffix به معنای view file suffix و یا مثلا fr در نام فایل Index.fr.cshtml است.
نحوهی تعریف و پوشه بندی فایلهای منبع زبانهای مختلف
تا اینجا پوشهی جدید Resources را به پروژه اضافه، معرفی و سرویسهای مرتبط را نیز فعال کردیم. پس از آن نوبت به افزودن فایلهای resx است. برای این منظور بر روی پوشهی منابع کلیک راست کرده و گزینهی add->new item را انتخاب کنید.
در اینجا با جستجوی resource، میتوان فایل resx جدیدی را به پروژه اضافه کرد؛ اما ... انتخاب نام آن باید بر اساس نکات ذیل باشد:
الف) برای کنترلرها یکی از دو مسیر / دار و یا نقطه دار جستجو میشوند:
Resources/Controllers.HomeController.fr.resx
Resources/Controllers/HomeController.fr.resx
در اینجا fr ذکر شده، همان LanguageViewLocationExpanderFormat.Suffix است که پیشتر بحث شد. قسمت ابتدایی Controllers همیشه ثابت است (یا به صورت نام یک پوشه و یا به عنوان قسمت اول نام فایل). سپس نام کلاس کنترلر به همراه نام فرهنگ مدنظر باید ذکر شوند. قسمت نام پوشهی Resources را نیز به services.AddLocalization معرفی کردهایم.
ب) برای Viewها نیز همان حالتهای / دار و یا نقطه دار بررسی میشوند:
Resources/Views.Home.About.fr.resx
Resources/Views/Home/About.fr.resx
برای تمام فایلها و کلاسها میتوان فایل منبع ایجاد کرد
در این نگارش از ASP.NET، در حالت کلی، نام یک فایل منبع، همان نام کامل کلاس آن است؛ منهای فضای نام آن (اگر این فایل منبع در همان اسمبلی قرار گیرد). برای مثال اگر میخواهید برای کلاس Startup برنامه، فایل منبعی را درست کنید و نام کامل آن با درنظر گرفتن فضای نام، معادل LocalizationWebsite.Web.Startup است، ابتدای فضای نام آنرا حذف کنید و سپس آنرا ختم به fa.resx کنید؛ مثلا Startup.fa.resx
اگر محل واقع شدن فایلهای resx در همان اسمبلی اصلی پروژه باشند، نیازی به ذکر فضای نام پیش فرض پروژه نیست. برای مثال اگر فضای نام پیش فرض پروژهی وب جاری MyLocalizationWebsite.Web است، بجای نام فایل MyLocalizationWebsite.Web.Controllers.HomeController.fr.resx میتوانید به صورت خلاصه بنویسید Controllers.HomeController.fr.resx. در غیراینصورت (استفاده از اسمبلیهای دیگر)، ذکر کامل فضای نام مرتبط هم الزامی است.
چند نکته:
- اگر ResourcesPath را در services.AddLocalization معرفی نکنید، مسیر پیش فرض یافتن فایلهای resx مربوط به کنترلرها، پوشهی ریشهی پروژه است و برای Viewها، همان پوشهی محل واقع شدن View متناظر خواهد بود.
- اینکه کدام فایل منبع در برنامه بارگذاری میشود، دقیقا مرتبط است با فرهنگ ترد جاری و این فرهنگ به صورت پیش فرض en-US است (چون همواره در هدر Accept-Language ارسالی توسط مرورگر وجود دارد). برای تغییر آن، از نکتهی اکشن متد public IActionResult SetFaLanguage ابتدای بحث استفاده کنید (در غیراینصورت در آزمایشات خود شاهد بارگذاری فایلهای منبع دیگری بجز en.resxها نخواهید بود).
- فایلهای منبع را به صورت کامپایل شده در پوشهی bin برنامه خواهید یافت:
خواندن اطلاعات منابع در کنترلرهای برنامه
فرض کنید کنترلری را به نام TestLocalController ایجاد کردهایم. بنابراین فایل منبع فارسی متناظر با آن Controllers.TestLocalController.fa.resx خواهد بود؛ با این محتوای نمونه:
محتوای این کنترلر نیز به صورت ذیل است:
در اینجا نحوهی دسترسی به فایلهای منبع را در کنترلرها مشاهده میکنید. سرویس IStringLocalizer برای خواندن key/valueهای معمولی طراحی شدهاست و سرویس IHtmlLocalizer برای خواندن key/valueهای تگ دار، بکار میرود. علت تنظیم شدن پارامتر جنریک آنها به نام کنترلر جاری این است که این سرویسها بدانند دقیقا چه نوعی را قرار است بارگذاری کنند و دقیقا باید به دنبال کدام فایل بگردند. این سرویسها یک کلید را میگیرند و یک خروجی و مقدار را باز میگردانند.
اگر برنامه را در حالت معمولی اجرا کنید و سپس آدرس http://localhost:7742/testlocal/gettitle را درخواست کنید، عبارت About Title را مشاهده میکنید؛ به دو علت:
الف) هنوز فرهنگ پیش فرض ترد جاری همان en-US است که توسط مرورگر ارسال شدهاست.
ب) چون فایل resx متناظر با فرهنگ پیش فرض ترد جاری یافت نشدهاست، مقدار همان کلید درخواستی بازگشت داده میشود؛ یعنی همان About Title.
برای رفع این مشکل آدرس http://localhost:7742/testlocal/SetFaLanguage را درخواست کنید. به این صورت با تنظیم کوکی ردیابی فرهنگ ترد جاری به زبان فارسی، خروجی GetTile اینبار «درباره» خواهد بود.
خواندن اطلاعات منابع در Viewهای برنامه
فرض کنید فایل Views.TestLocal.Index.fa.resx (فایل منبع کنترلر TestLocal و ویوو Index آن به زبان فارسی) دقیقا همان محتوای فایل Controllers.TestLocalController.fa.resx فوق را دارد (اگر نام پوشهی Views را تغییر دادهاید، قسمت ابتدایی نام فایل Views را هم باید تغییر دهید). برای دسترسی به اطلاعات آن در یک ویوو، میتوان از سرویس IViewLocalizer به نحو ذیل استفاده کرد:
در اینجا ViewData، از همان اطلاعات اکشن متد Index استفاده میکند.
Localizer از طریق تزریق سرویس IViewLocalizer به View برنامه تامین میشود. این سرویس در پشت صحنه از همان IHtmlLocalizer استفاده میکند و در حین استفادهی از آن، اطلاعات تگها انکد (encoded) نخواهند شد (به همین جهت برای کار با کلیدها و مقادیر تگدار توصیه میشود).
استفاده از اطلاعات منابع در DataAnnotations
قسمت اول فعال سازی بومی سازی DataAnnotations با ذکر AddDataAnnotationsLocalization در متد ConfigureServices، در ابتدای بحث انجام شد و همانطور که پیشتر نیز عنوان گردید، در این نگارش از ASP.NET، برای تمام کلاسهای برنامه میتوان فایل منبع ایجاد کرد. برای مثال اگر کلاس RegisterViewModel در فضای نام ViewModels.Account قرار گرفتهاست، نام فایل منبع آن یکی از دو حالت / دار و یا نقطه دار ذیل میتواند باشد:
Resources/ViewModels.Account.RegisterViewModel.fr.resx
Resources/ViewModels/Account/RegisterViewModel.fr.resx
محتوای این کلاس را در ذیل مشاهده میکنید:
در این حالت مقداری که برای ErrorMessage ذکر میشود، کلیدی است که باید در فایل منبع جستجو شود:
یک نکته: هیچ الزامی ندارد که کلیدها را به این شکل وارد کنید. از این جهت که اگر این کلید در فایل منبع یافت نشد و یا فرهنگ ترد جاری با فایلهای منبع مهیا تطابقی نداشت، عبارتی را که کاربر مشاهده میکند، دقیقا معادل «EmailReq» خواهد بود. بنابراین در اینجا میتوانید کلید را به صورت کامل، مثلا مساوی «The Email field is required» وارد کنید و همین عبارت را به عنوان کلید در فایل منبع ذکر کرده و مقدار آنرا مساوی ترجمهی آن قرار دهید. این نکته در تمام حالات کار با کنترلرها و ویووها نیز صادق است.
استفاده از یک منبع اشتراکی
اگر میخواهید تعدادی از منابع را در همهجا در اختیار داشته باشید، روش کار به این صورت است:
الف) یک کلاس خالی را به نام SharedResource دقیقا با فرمت ذیل در پوشهی Resources ایجاد کنید:
ب) اکنون فایلهای منبع خود را در پوشهی Resources، دقیقا با این نامهای خاص ایجاد کنید:
SharedResource.fa.resx
SharedResource.en-US.resx
و امثال آن
ج) برای استفادهی از این منبع اشتراکی در کلاسهای مختلف برنامه تنها کافی است در حین تزریق وابستگیها، نوع آرگومان جنریک IStringLocalizer را به SharedResource تنظیم کنید:
و یا حتی در ویووهای برنامه نیز میتوان از آن استفاده کرد:
نحوهی تعیین فرهنگ ترد جاری در ASP.NET Core
در نگارشهای پیشین ASP.NET، برای تعیین فرهنگ ترد جاری، از یکی از دو روش ذیل استفاده میشود:
الف) افزودن مدخل بومی سازی به فایل web.config
<system.web> <globalization uiCulture="fa-IR" culture="fa-IR" /> </system.web>
protected void Application_BeginRequest() { Thread.CurrentThread.CurrentCulture = new CultureInfo("fa-IR"); Thread.CurrentThread.CurrentUICulture = new CultureInfo("fa-IR"); }
public void Configure(IApplicationBuilder app) { app.UseRequestLocalization(new RequestLocalizationOptions { DefaultRequestCulture = new RequestCulture(new CultureInfo("fa-IR")), SupportedCultures = new[] { new CultureInfo("en-US"), new CultureInfo("fa-IR") }, SupportedUICultures = new[] { new CultureInfo("en-US"), new CultureInfo("fa-IR") } });
- تنظیمات SupportedCultures بر روی نمایش تاریخ، ساعت و واحد پولی تاثیر دارند. همچنین میتوانند بر روی نحوهی مقایسهی حروف و مرتب سازی آنها تاثیر داشته باشند.
- تنظیمات SupportedUICultures مشخص میکنند که کدامیک از فایلهای resx برنامه که مداخل ترجمههای آنرا به زبانهای مختلف مشخص میکنند، باید بارگذاری شوند.
- تنظیم DefaultRequestCulture در صورت مشخص نشدن فرهنگ ترد جاری مورد استفاده قرار میگیرد.
یک مثال: هر ترد در دات نت دارای اشیاء CurrentCulture و CurrentUICulture است. اگر فرهنگ ترد جاری به en-US تنظیم شده باشد، متد DateTime.Now.ToLongDateString، خروجی نمونه Thursday, February 18, 2016 را نمایش میدهد.
زمانیکه میان افزار RequestLocalization فعال میشود، سه تامین کنندهی پیش فرض (مقدارهای پیش فرض خاصیت RequestCultureProviders شیء RequestLocalizationOptions فوق)، جهت مشخص ساختن فرهنگ ترد جاری بکار گرفته خواهند شد:
الف) از طریق کوئری استرینگ با فعال سازی QueryStringRequestCultureProvider
http://localhost:5000/?culture=es-MX&ui-culture=es-MX
http://localhost:5000/?culture=es-MX
برای مثال در اینجا QueryStringRequestCultureProvider به دنبال کوئری استرینگهای culture و یا ui-culture گشته و با رسیدن به es-MX، فرهنگ جاری را به اسپانیایی مکزیکی تنظیم میکند. در این حالت اگر فقط culture ذکر شود، ui-culture نیز به همان مقدار تنظیم خواهد شد.
ب) از طریق نام کوکی با فعال سازی CookieRequestCultureProvider
CookieRequestCultureProvider کوکی ویژهای را با نام پیش فرض AspNetCore.Culture. ایجاد میکند. این کوکی برای ردیابی اطلاعات بومی سازی انتخابی کاربر بکار میرود. برای مثال اگر به مقدار ذیل تنظیم شود:
c='en-UK'|uic='en-US'
ج) از طریق هدر مخصوص Accept-Language با فعال سازی AcceptLanguageHeaderRequestCultureProvider که میتواند به همراه درخواست HTTP ارسال شود.
اگر تمام این حالتها تنظیم نشده بودند، آنگاه از مقدارDefaultRequestCulture استفاده میشود. برای مثال اگر مرورگر به صورت پیش فرض هدر Accept-Language را en-US ارسال میکند :
دیگر کار به پردازش مقدارDefaultRequestCulture نخواهد رسید.
اکنون اگر علاقمند بودید تا به کاربر امکان انتخاب زبانی را بدهید، یک چنین اکشن متدی را طراحی کنید:
public IActionResult SetFaLanguage() { Response.Cookies.Append( CookieRequestCultureProvider.DefaultCookieName, CookieRequestCultureProvider.MakeCookieValue(new RequestCulture(new CultureInfo("fa-IR"))), new CookieOptions { Expires = DateTimeOffset.UtcNow.AddYears(1) } ); return RedirectToAction("GetTitle"); }
از اینجا به بعد است که اگر نام کنترلر شما TestLocalController باشد، فایل منبع متناظر با آن یعنی Controllers.TestLocalController.fa.resx، به صورت خودکار بارگذاری و پردازش خواهد شد. در غیر اینصورت فایل نمونهی ختم شدهی به en.resx پردازش میشود؛ چون این زبان به صورت پیش فرض در هدر Accept-Language قید شدهاست.
آماده سازی برنامه برای کار با فایلهای منبع زبانهای مختلف
ابتدا پوشهی جدیدی را به نام Resources به ریشهی پروژه اضافه کنید. سپس به کلاس آغازین برنامه مراجعه کرده و محل یافت شدن این پوشه را معرفی کنید:
public void ConfigureServices(IServiceCollection services) { services.AddLocalization(options => options.ResourcesPath = "Resources"); services.AddMvc() .AddViewLocalization(LanguageViewLocationExpanderFormat.Suffix) .AddDataAnnotationsLocalization();
به علاوه به سرویس ASP.NET MVC، تنظیمات بومی سازی Viewها و DataAnnotations نیز اضافه شدهاند. تنظیم suffix به معنای view file suffix و یا مثلا fr در نام فایل Index.fr.cshtml است.
نحوهی تعریف و پوشه بندی فایلهای منبع زبانهای مختلف
تا اینجا پوشهی جدید Resources را به پروژه اضافه، معرفی و سرویسهای مرتبط را نیز فعال کردیم. پس از آن نوبت به افزودن فایلهای resx است. برای این منظور بر روی پوشهی منابع کلیک راست کرده و گزینهی add->new item را انتخاب کنید.
در اینجا با جستجوی resource، میتوان فایل resx جدیدی را به پروژه اضافه کرد؛ اما ... انتخاب نام آن باید بر اساس نکات ذیل باشد:
الف) برای کنترلرها یکی از دو مسیر / دار و یا نقطه دار جستجو میشوند:
Resources/Controllers.HomeController.fr.resx
Resources/Controllers/HomeController.fr.resx
در اینجا fr ذکر شده، همان LanguageViewLocationExpanderFormat.Suffix است که پیشتر بحث شد. قسمت ابتدایی Controllers همیشه ثابت است (یا به صورت نام یک پوشه و یا به عنوان قسمت اول نام فایل). سپس نام کلاس کنترلر به همراه نام فرهنگ مدنظر باید ذکر شوند. قسمت نام پوشهی Resources را نیز به services.AddLocalization معرفی کردهایم.
ب) برای Viewها نیز همان حالتهای / دار و یا نقطه دار بررسی میشوند:
Resources/Views.Home.About.fr.resx
Resources/Views/Home/About.fr.resx
برای تمام فایلها و کلاسها میتوان فایل منبع ایجاد کرد
در این نگارش از ASP.NET، در حالت کلی، نام یک فایل منبع، همان نام کامل کلاس آن است؛ منهای فضای نام آن (اگر این فایل منبع در همان اسمبلی قرار گیرد). برای مثال اگر میخواهید برای کلاس Startup برنامه، فایل منبعی را درست کنید و نام کامل آن با درنظر گرفتن فضای نام، معادل LocalizationWebsite.Web.Startup است، ابتدای فضای نام آنرا حذف کنید و سپس آنرا ختم به fa.resx کنید؛ مثلا Startup.fa.resx
اگر محل واقع شدن فایلهای resx در همان اسمبلی اصلی پروژه باشند، نیازی به ذکر فضای نام پیش فرض پروژه نیست. برای مثال اگر فضای نام پیش فرض پروژهی وب جاری MyLocalizationWebsite.Web است، بجای نام فایل MyLocalizationWebsite.Web.Controllers.HomeController.fr.resx میتوانید به صورت خلاصه بنویسید Controllers.HomeController.fr.resx. در غیراینصورت (استفاده از اسمبلیهای دیگر)، ذکر کامل فضای نام مرتبط هم الزامی است.
چند نکته:
- اگر ResourcesPath را در services.AddLocalization معرفی نکنید، مسیر پیش فرض یافتن فایلهای resx مربوط به کنترلرها، پوشهی ریشهی پروژه است و برای Viewها، همان پوشهی محل واقع شدن View متناظر خواهد بود.
- اینکه کدام فایل منبع در برنامه بارگذاری میشود، دقیقا مرتبط است با فرهنگ ترد جاری و این فرهنگ به صورت پیش فرض en-US است (چون همواره در هدر Accept-Language ارسالی توسط مرورگر وجود دارد). برای تغییر آن، از نکتهی اکشن متد public IActionResult SetFaLanguage ابتدای بحث استفاده کنید (در غیراینصورت در آزمایشات خود شاهد بارگذاری فایلهای منبع دیگری بجز en.resxها نخواهید بود).
- فایلهای منبع را به صورت کامپایل شده در پوشهی bin برنامه خواهید یافت:
خواندن اطلاعات منابع در کنترلرهای برنامه
فرض کنید کنترلری را به نام TestLocalController ایجاد کردهایم. بنابراین فایل منبع فارسی متناظر با آن Controllers.TestLocalController.fa.resx خواهد بود؛ با این محتوای نمونه:
محتوای این کنترلر نیز به صورت ذیل است:
using System; using System.Globalization; using Microsoft.AspNetCore.Http; using Microsoft.AspNetCore.Localization; using Microsoft.AspNetCore.Mvc; using Microsoft.AspNetCore.Mvc.Localization; using Microsoft.Extensions.Localization; namespace Core1RtmEmptyTest.Controllers { public class TestLocalController : Controller { private readonly IStringLocalizer<TestLocalController> _stringLocalizer; private readonly IHtmlLocalizer<TestLocalController> _htmlLocalizer; public TestLocalController( IStringLocalizer<TestLocalController> stringLocalizer, IHtmlLocalizer<TestLocalController> htmlLocalizer) { _stringLocalizer = stringLocalizer; _htmlLocalizer = htmlLocalizer; } public IActionResult Index() { var name = "DNT"; var message = _htmlLocalizer["<b>Hello</b><i> {0}</i>", name]; ViewData["Message"] = message; return View(); } [HttpGet] public string GetTitle() { var about = _stringLocalizer["About Title"]; return about; } public IActionResult SetFaLanguage() { Response.Cookies.Append( CookieRequestCultureProvider.DefaultCookieName, CookieRequestCultureProvider.MakeCookieValue(new RequestCulture(new CultureInfo("fa-IR"))), new CookieOptions { Expires = DateTimeOffset.UtcNow.AddYears(1) } ); return RedirectToAction("GetTitle"); } } }
اگر برنامه را در حالت معمولی اجرا کنید و سپس آدرس http://localhost:7742/testlocal/gettitle را درخواست کنید، عبارت About Title را مشاهده میکنید؛ به دو علت:
الف) هنوز فرهنگ پیش فرض ترد جاری همان en-US است که توسط مرورگر ارسال شدهاست.
ب) چون فایل resx متناظر با فرهنگ پیش فرض ترد جاری یافت نشدهاست، مقدار همان کلید درخواستی بازگشت داده میشود؛ یعنی همان About Title.
برای رفع این مشکل آدرس http://localhost:7742/testlocal/SetFaLanguage را درخواست کنید. به این صورت با تنظیم کوکی ردیابی فرهنگ ترد جاری به زبان فارسی، خروجی GetTile اینبار «درباره» خواهد بود.
خواندن اطلاعات منابع در Viewهای برنامه
فرض کنید فایل Views.TestLocal.Index.fa.resx (فایل منبع کنترلر TestLocal و ویوو Index آن به زبان فارسی) دقیقا همان محتوای فایل Controllers.TestLocalController.fa.resx فوق را دارد (اگر نام پوشهی Views را تغییر دادهاید، قسمت ابتدایی نام فایل Views را هم باید تغییر دهید). برای دسترسی به اطلاعات آن در یک ویوو، میتوان از سرویس IViewLocalizer به نحو ذیل استفاده کرد:
@using Microsoft.AspNetCore.Mvc.Localization @inject IViewLocalizer Localizer @{ } Message @ViewData["Message"] <br/> @Localizer["<b>Hello</b><i> {0}</i>", "DNT"] <br/> @Localizer["About Title"]
Localizer از طریق تزریق سرویس IViewLocalizer به View برنامه تامین میشود. این سرویس در پشت صحنه از همان IHtmlLocalizer استفاده میکند و در حین استفادهی از آن، اطلاعات تگها انکد (encoded) نخواهند شد (به همین جهت برای کار با کلیدها و مقادیر تگدار توصیه میشود).
استفاده از اطلاعات منابع در DataAnnotations
قسمت اول فعال سازی بومی سازی DataAnnotations با ذکر AddDataAnnotationsLocalization در متد ConfigureServices، در ابتدای بحث انجام شد و همانطور که پیشتر نیز عنوان گردید، در این نگارش از ASP.NET، برای تمام کلاسهای برنامه میتوان فایل منبع ایجاد کرد. برای مثال اگر کلاس RegisterViewModel در فضای نام ViewModels.Account قرار گرفتهاست، نام فایل منبع آن یکی از دو حالت / دار و یا نقطه دار ذیل میتواند باشد:
Resources/ViewModels.Account.RegisterViewModel.fr.resx
Resources/ViewModels/Account/RegisterViewModel.fr.resx
محتوای این کلاس را در ذیل مشاهده میکنید:
using System.ComponentModel.DataAnnotations; namespace Core1RtmEmptyTest.ViewModels.Account { public class RegisterViewModel { [Required(ErrorMessage = "EmailReq")] [EmailAddress(ErrorMessage = "EmailType")] [Display(Name = "Email")] public string Email { get; set; } } }
یک نکته: هیچ الزامی ندارد که کلیدها را به این شکل وارد کنید. از این جهت که اگر این کلید در فایل منبع یافت نشد و یا فرهنگ ترد جاری با فایلهای منبع مهیا تطابقی نداشت، عبارتی را که کاربر مشاهده میکند، دقیقا معادل «EmailReq» خواهد بود. بنابراین در اینجا میتوانید کلید را به صورت کامل، مثلا مساوی «The Email field is required» وارد کنید و همین عبارت را به عنوان کلید در فایل منبع ذکر کرده و مقدار آنرا مساوی ترجمهی آن قرار دهید. این نکته در تمام حالات کار با کنترلرها و ویووها نیز صادق است.
استفاده از یک منبع اشتراکی
اگر میخواهید تعدادی از منابع را در همهجا در اختیار داشته باشید، روش کار به این صورت است:
الف) یک کلاس خالی را به نام SharedResource دقیقا با فرمت ذیل در پوشهی Resources ایجاد کنید:
// Dummy class to group shared resources namespace Core1RtmEmptyTest { public class SharedResource { } }
SharedResource.fa.resx
SharedResource.en-US.resx
و امثال آن
ج) برای استفادهی از این منبع اشتراکی در کلاسهای مختلف برنامه تنها کافی است در حین تزریق وابستگیها، نوع آرگومان جنریک IStringLocalizer را به SharedResource تنظیم کنید:
IStringLocalizer<SharedResource> sharedLocalizer
@inject IHtmlLocalizer<SharedResource> SharedLocalizer
سوال اینجاست که صرف Open Source بودن اپلیکیشن شما و یا حتی سرور، دلیلی بر حفط حریم شخصی افراد هست؟
و آیا Release نهایی همان سورس ارائه شده است؟! و اصلا چند نفر از مردم ایران توان استفاده از این سورس را دارند؟
و جالب اینکه تلگرامهای فارسی با وجود اینکه مشخصا توسط توسعه دهندگان داخلی و مدیران داخلی ارائه شده و در معرض تمام ایراداتی که میتوان به پیامرسانهای داخلی گرفت، هستند به طور نسبتا گسترده استفاده میشوند!