عادی‌سازی شناسانه منبع یکسان

عادی سازی URI فرآیندی است که توسط آن URI (Uniform Resource Identifier)ها به شیوه ای ثابت اصلاح و استاندارد می‌شوند. هدف از فرایند عادی سازی تبدیل یک URI به یک URI نرمال شده‌است، بنابراین می‌توان تعیین کرد که آیا دو URI متفاوت از لحاظ نحوی ممکن است معادل باشند یا خیر.

موتورهای جستجو از عادی سازی URI استفاده می‌کنند تا صفحاتی را که ممکن است با URIهای متعدد یافت می‌شوند، به درستی رتبه‌بندی کنند و فهرست شدن صفحات تکراری را کاهش دهند. خزنده‌های وب برای جلوگیری از خزیدن بیش از یک بار در یک منبع، عادی سازی URI را انجام می‌دهند. مرورگرهای وب ممکن است برای تعیین اینکه آیا یک پیوند بازدید شده‌است یا برای تعیین اینکه آیا این صفحه قبلاً ذخیره شده‌است یا خیر، عادی سازی را انجام دهند. سرورهای وب همچنین ممکن است به دلایل زیادی نرمال سازی را انجام دهند (برای اینکه بتوانند به راحتی خطرات امنیتی ناشی از درخواست‌های مشتری را رهگیری کنند، برای هر منبع ذخیره شده در حافظه پنهان آن‌ها، نامگذاری شده در گزارش، فقط از یک نام فایل مطلق استفاده کنند.))

فرایند عادی سازی[ویرایش]

چندین نوع نرمال سازی وجود دارد که ممکن است انجام شود. برخی از آنها همیشه معناشناسی را حفظ می‌کنند و برخی ممکن است اینطور نباشند.

عادی سازی‌هایی که معمولاً معنایی را حفظ میکند[ویرایش]

نرمال سازی‌های زیر در RFC 3986^[۱] توضیح داده شده‌است تا به URIهای معادل منجر شود:
تبدیل سه قلوهای رمزگذاری شده درصد به حروف بزرگ. ارقام هگزا دسیمال در یک سه‌گانه رمزگذاری درصد از URI (مثلاً %3a در مقابل %3A) به حروف بزرگ و کوچک حساس نیستند و بنابراین باید برای استفاده از حروف بزرگ برای ارقام AF نرمال شوند.^[۲] مثال:

http://example.com/foo* → http://example.com/foo*

تبدیل طرح و میزبان به حروف کوچک. طرح و اجزای میزبان URI به حروف بزرگ و کوچک حساس هستند و بنابراین باید به حروف کوچک عادی شوند.^[۳] مثال:

http://user@Example.COM/Foo → http://user‌@example.com/Foo

رمزگشایی سه قلوهای رمزگذاری شده با درصد نویسه‌های رزرو نشده. سه درصد رمزنگاری شده از URI در محدوده ALPHA (%41 - %5A و %61 - %7A)، رقمی (%30 - %39)، خط تیره (%2D)، دوره (%2E)، زیرین (%5F)، یا tilde (%7E) نیازی به رمزگذاری درصد ندارند و باید به کاراکترهای ذخیره نشده مربوطه رمزگشایی شوند.^[۴] مثال:

http://example.com/~foo → http://example.com/~foo

حذف نقاط نقطه دات بخش . و .. در مسیر مولفه URI باید با اعمال الگوریتم remove_dot_segments^[۵] در مسیر توضیح داده شده در [rfc:3986 RFC 3986 حذف شود].^[۶] مثال:

http://example.com/foo/./bar/baz/../qux → http://example.com/foo/bar/qux

تبدیل یک مسیر خالی به مسیر "/". در حضور یک مؤلفه اقتدار، یک جزء مسیر خالی باید به مولفه مسیر «/» نرمال شود.^[۷] مثال:

http://example.com → http://example.com/

حذف پورت پیش فرض یک جزء پورت خالی یا پیش‌فرض از URI (درگاه ۸۰ برای http) با جداکننده ":" آن باید حذف شود.^[۸] مثال:

http://example.com:80/ → http://example.com/

عادی سازی‌هایی که معناشناسی را تغییر می‌دهد[ویرایش]

برای URIهای http و https، نرمال سازی‌های زیر که در RFC 3986 فهرست شده‌اند ممکن است منجر به URIهای معادل شوند، اما استانداردها تضمین نمی‌کنند:

افزودن یک "/" انتهایی به یک مسیر غیر خالی. دایرکتوری‌ها (پوشه‌ها) با اسلش انتهایی نشان داده می‌شوند و باید در URIها گنجانده شوند. مثال:

http://example.com/foo → http://example.com/foo/

با این حال، هیچ راهی برای دانستن اینکه آیا یک جزء مسیر URI یک دایرکتوری را نشان می‌دهد یا خیر وجود ندارد. RFC 3986 اشاره می‌کند که اگر URI قبلی به URI دوم هدایت شود، این نشانه‌ای است که آنها معادل هستند.

عادی سازی‌هایی که معناشناسی را تغییر می‌دهد[ویرایش]

اعمال نرمال‌سازی‌های زیر منجر به یک URI از نظر معنایی متفاوت می‌شود، اگرچه ممکن است به یک منبع اشاره کند:

حذف فهرست فهرست ایندکس‌های دایرکتوری پیش فرض معمولاً در URIها مورد نیاز نیستند. مثال‌ها:

http://example.com/default.asp → http://example.com/

http://example.com/a/index.html → http://example.com/a/

در حال برداشتن قطعه جزء قطعه یک URI هرگز توسط سرور دیده نمی‌شود و گاهی اوقات می‌توان آن را حذف کرد. مثال:

http://example.com/bar.html#section1 → http://example.com/bar.html

با این حال، برنامه‌های AJAX اغلب از مقدار موجود در قطعه استفاده می‌کنند.

جایگزینی IP با نام دامنه بررسی کنید که آیا آدرس IP با نام دامنه مطابقت دارد یا خیر. مثال:

http://208.77.188.166/ → http://example.com/

جایگزینی معکوس به دلیل وب سرورهای مجازی به ندرت ایمن است.

پروتکل‌های محدود کننده محدود کردن پروتکل‌های لایه کاربردی مختلف به عنوان مثال، طرح "https" را می‌توان با "http" جایگزین کرد. مثال:

https://example.com/ → http://example.com/

حذف اسلش‌های تکراری مسیرهایی که شامل دو اسلش مجاور هستند می‌توانند به یک تبدیل شوند. مثال:

http://example.com/foo//bar.html → http://example.com/foo/bar.html

حذف یا اضافه کردن "www" به عنوان اولین برچسب دامنه. برخی از وب‌سایت‌ها در دو حوزه اینترنتی به‌طور یکسان عمل می‌کنند: یکی که کمترین برچسب آن «www» است و دیگری که نام آن در نتیجه حذف کمترین برچسب از نام دامنهٔ اول است، که دومی به عنوان یک دامنه برهنه شناخته می‌شود. برای مثال، http://www.example.com/ و http://example.com/ ممکن است به یک وب سایت دسترسی داشته باشند. بسیاری از وب سایت‌ها کاربر را از www به آدرس غیر www یا برعکس هدایت می‌کنند. یک نرمال ساز ممکن است تعیین کند که آیا یکی از این URIها به دیگری هدایت می‌شود و همه URIها را به‌طور مناسب عادی می‌کند. مثال:

http://www.example.com/ → http://example.com/

مرتب‌سازی پارامترهای پرس و جو برخی از صفحات وب از بیش از یک پارامتر پرس و جو در URI استفاده می‌کنند. یک نرمال ساز می‌تواند پارامترها را به ترتیب حروف الفبا (با مقادیر آنها) مرتب کند و URI را دوباره جمع کند. مثال:

http://example.com/display?lang=en&article=fred → http://example.com/display?article=fred&lang=en

با این حال، ترتیب پارامترها در یک URI ممکن است قابل توجه باشد (این توسط استاندارد تعریف نشده‌است) و یک وب سرور ممکن است به یک متغیر اجازه دهد چندین بار ظاهر شود.^[۹]

حذف متغیرهای پرس و جو استفاده نشده یک صفحه ممکن است فقط انتظار داشته باشد که پارامترهای خاصی در پرس و جو ظاهر شوند. پارامترهای استفاده نشده را می‌توان حذف کرد. مثال:

http://example.com/display?id=123&fakefoo=fakebar → http://example.com/display?id=123

توجه داشته باشید که یک پارامتر بدون مقدار لزوماً یک پارامتر استفاده نشده نیست.

حذف پارامترهای پرس و جو پیش فرض یک مقدار پیش‌فرض در رشته پرس و جو ممکن است به صورت یکسان ارائه شود، خواه وجود داشته باشد یا نباشد. مثال:

http://example.com/display?id=&sort=ascending → http://example.com/display

حذف "?" وقتی پرس و جو خالی است وقتی پرس و جو خالی است، ممکن است نیازی به "?" نباشد. . مثال:

http://example.com/display? → http://example.com/display

عادی سازی بر اساس لیست‌های URI[ویرایش]

برخی از قوانین عادی سازی ممکن است برای وب سایت‌های خاص با بررسی لیست‌های URI به دست آمده از خزیدن‌های قبلی یا گزارش‌های وب سرور ایجاد شوند. به عنوان مثال، اگر URI

http://example.com/story?id=xyz

چندین بار در یک گزارش به صورت‌های مختلف از جمله شکل زیر ظاهر شود

http://example.com/story_xyz

ممکن است فرض کنیم که دو URI معادل هستند و می‌توانند به یکی از اشکال URI عادی سازی شوند.

شونفلد و همکارانش (۲۰۰۶) یک اکتشافی به نام DustBuster برای تشخیص قوانین DUST یا URIهای مختلف با متن مشابه ارائه داد که می‌تواند در لیست‌های URI اعمال شود. آنها نشان دادند که وقتی قوانین DUST یا (different URIs with similar text) صحیح پیاده و با یک الگوریتم عادی سازی اعمال شد، توانستند تا ۶۸٪ از URIهای اضافی را در یک لیست URI پیدا کنند.

جستارهای وابسته[ویرایش]

منابع[ویرایش]

RFC 3986 - شناسه منبع یکسان (URI): نحو عمومی

[1] RFC 3986, Section 6. Normalization and Comparison

[2] RFC 3986, Section 6.2.2.1. Case Normalization

[3] RFC 3986, Section 6.2.2.1. Case Normalization

[4] RFC 3986, Section 6.2.2.3. Path Segment Normalization

[5] RFC 3986, 5.2.4. Remove Dot Segments

[6] RFC 3986, 6.2.2.3. Path Segment Normalization

[7] RFC 3986, Section 6.2.3. Scheme-Based Normalization

[8] RFC 3986, Section 6.2.3. Scheme-Based Normalization

[9] "jQuery 1.4 $.param demystified". Ben Alman. 2009-12-20. Retrieved 2013-08-24.

[۱]

[۲]

[۳]

[۴]

[۵]

[۶]

[۷]

[۸]

[۹]