URLs and Hashing
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
این بخش شامل مشخصات دقیقی از نحوه چک کردن URL ها توسط مشتریان است.
متعارف سازی URL ها
قبل از اینکه هر URL بررسی شود، از مشتری انتظار می رود تا مقداری متعارف سازی را در آن URL انجام دهد.
برای شروع، فرض می کنیم که مشتری URL را تجزیه کرده و آن را مطابق RFC 2396 معتبر کرده است. اگر URL از یک نام دامنه بین المللی (IDN) استفاده می کند، مشتری باید URL را به نمایندگی ASCII Punycode تبدیل کند. URL باید شامل یک جزء مسیر باشد. یعنی باید حداقل یک اسلش پس از دامنه ( http://google.com/ به جای http://google.com ) داشته باشد.
ابتدا کاراکترهای تب (0x09)، CR (0x0d) و LF (0x0a) را از URL حذف کنید. دنباله های فرار را برای این کاراکترها حذف نکنید (مثلا %0a ).
دوم، اگر URL به یک قطعه ختم می شود، قطعه را حذف کنید. برای مثال، http://google.com/#frag به http://google.com/ کوتاه کنید.
سوم، به طور مکرر درصد از URL خارج شود تا زمانی که دیگر درصد فرار نداشته باشد. (این ممکن است URL را نامعتبر کند.)
برای متعارف کردن نام میزبان:
نام میزبان را از URL استخراج کنید و سپس:
- تمام نقاط پیشرو و انتهایی را حذف کنید.
- نقطه های متوالی را با یک نقطه جایگزین کنید.
- اگر نام میزبان را می توان به عنوان یک آدرس IPv4 تجزیه کرد، آن را به 4 مقدار اعشاری جدا شده با نقطه نرمال کنید. مشتری باید هر کدگذاری آدرس IP قانونی، از جمله اکتال، هگز و کمتر از چهار مؤلفه را کنترل کند.
- اگر می‌توان نام میزبان را به‌عنوان یک آدرس IPv6 پرانتزی تجزیه کرد، با حذف صفرهای غیرضروری ابتدایی در مؤلفه‌ها و جمع کردن مؤلفه‌های صفر با استفاده از نحو دو نقطه، آن را عادی کنید. برای مثال
[2001:0db8:0000::1] باید به [2001:db8::1] تبدیل شود. اگر نام میزبان یکی از دو نوع آدرس IPv6 ویژه زیر است، آنها را به IPv4 تبدیل کنید:- یک آدرس IPv6 با نقشه IPv4، مانند
[::ffff:1.2.3.4] ، که باید به 1.2.3.4 تبدیل شود. - یک آدرس NAT64 با استفاده از پیشوند معروف 64:ff9b::/96 ، مانند
[64:ff9b::1.2.3.4] ، که باید به 1.2.3.4 تبدیل شود.
- کل رشته را با حروف کوچک بنویسید.
برای متعارف کردن مسیر:
- دنباله های
/../ و /./ در مسیر را با جایگزین کردن /./ با / و حذف /../ به همراه مولفه مسیر قبلی حل کنید. - اجراهای اسلش های متوالی را با یک کاراکتر اسلش جایگزین کنید.
این متعارف سازی مسیرها را برای پارامترهای پرس و جو اعمال نکنید.
در URL، درصد فرار از همه کاراکترهایی که <= ASCII 32، >= 127، # یا % هستند. Escape ها باید از حروف هگز بزرگ استفاده کنند.
میزبان-پسوند مسیر- عبارات پیشوند
هنگامی که URL متعارف شد، گام بعدی ایجاد عبارات پسوند/پیشوند است. هر عبارت پسوند/پیشوند از یک پسوند میزبان (یا میزبان کامل) و یک پیشوند مسیر (یا مسیر کامل) تشکیل شده است.
مشتری حداکثر 30 ترکیب مختلف پسوند میزبان و پیشوند مسیر را تشکیل می دهد. این ترکیب ها فقط از اجزای میزبان و مسیر URL استفاده می کنند. طرح، نام کاربری، رمز عبور و پورت حذف می شوند. اگر URL شامل پارامترهای پرس و جو باشد، حداقل یک ترکیب شامل مسیر کامل و پارامترهای پرس و جو می شود.
برای میزبان ، مشتری حداکثر پنج رشته مختلف را امتحان خواهد کرد. آنها عبارتند از:
- اگر نام میزبان تحت اللفظی IPv4 یا IPv6 نباشد، حداکثر چهار نام میزبان با شروع با دامنه eTLD+1 و افزودن مؤلفه‌های اصلی متوالی تشکیل می‌شود. تعیین eTLD+1 باید بر اساس فهرست پسوند عمومی باشد. به عنوان مثال،
abexample.com منجر به ایجاد دامنه eTLD+1 از example.com و همچنین میزبانی با یک جزء میزبان اضافی b.example.com می شود. - نام دقیق میزبان در URL. به دنبال مثال قبلی،
abexample.com بررسی می شود.
برای مسیر ، مشتری حداکثر شش رشته مختلف را امتحان خواهد کرد. آنها عبارتند از:
- مسیر دقیق URL، از جمله پارامترهای پرس و جو.
- مسیر دقیق URL، بدون پارامترهای پرس و جو.
- چهار مسیر با شروع از ریشه (/) و پیوستن متوالی مؤلفه‌های مسیر، از جمله یک اسلش انتهایی، تشکیل می‌شوند.
مثال‌های زیر رفتار چک را نشان می‌دهند:
برای URL http://abcom/1/2.html?param=1 ، مشتری این رشته های ممکن را امتحان می کند:
a.b.com/1/2.html?param=1
a.b.com/1/2.html
a.b.com/
a.b.com/1/
b.com/1/2.html?param=1
b.com/1/2.html
b.com/
b.com/1/
برای URL http://abcdefcom/1.html ، مشتری این رشته های ممکن را امتحان می کند:
a.b.c.d.e.f.com/1.html
a.b.c.d.e.f.com/
c.d.e.f.com/1.html
c.d.e.f.com/
d.e.f.com/1.html
d.e.f.com/
e.f.com/1.html
e.f.com/
f.com/1.html
f.com/
(توجه: از bcdefcom رد شوید، زیرا ما فقط پنج جزء آخر نام میزبان و نام میزبان کامل را می گیریم.)
برای URL http://1.2.3.4/1/ ، مشتری این رشته های ممکن را امتحان می کند:
1.2.3.4/1/
1.2.3.4/
برای URL http://example.co.uk/1 ، مشتری این رشته های ممکن را امتحان می کند:
example.co.uk/1
example.co.uk/
هش کردن
مرور ایمن Google منحصراً از SHA256 به عنوان عملکرد هش استفاده می کند. این تابع هش باید برای عبارات بالا اعمال شود.
هش کامل 32 بایت، بسته به شرایط، به 4 بایت، 8 بایت یا 16 بایت کوتاه می شود:
هنگام استفاده از روش hashes.search ، در حال حاضر نیاز داریم که هش های موجود در درخواست دقیقاً به 4 بایت کوتاه شوند. ارسال بایت های اضافی در این درخواست حریم خصوصی کاربر را به خطر می اندازد.
هنگام دانلود لیست ها برای پایگاه داده محلی با استفاده از روش hashList.get یا روش hashLists.batchGet ، طول هش های ارسال شده توسط سرور در قرارداد نامگذاری لیست هایی که حاوی پسوند نشان دهنده طول هش هستند کدگذاری می شود. برای جزئیات بیشتر به بخش لیست های موجود مراجعه کنید.
جز در مواردی که غیر از این ذکر شده باشد،محتوای این صفحه تحت مجوز Creative Commons Attribution 4.0 License است. نمونه کدها نیز دارای مجوز Apache 2.0 License است. برای اطلاع از جزئیات، به خطمشیهای سایت Google Developers مراجعه کنید. جاوا علامت تجاری ثبتشده Oracle و/یا شرکتهای وابسته به آن است.
تاریخ آخرین بهروزرسانی 2025-07-24 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین بهروزرسانی 2025-07-24 بهوقت ساعت هماهنگ جهانی."],[],[],null,["# URLs and Hashing\n\nThis section contains detailed specifications of how clients check URLs.\n\n### Canonicalization of URLs\n\nBefore any URLs are checked, the client is expected to perform some canonicalization on that URL.\n\nTo begin, we assume that the client has parsed the URL and made it valid according to RFC 2396. If the URL uses an internationalized domain name (IDN), the client should convert the URL to the ASCII Punycode representation. The URL must include a path component; that is, it must have at least one slash following the domain (`http://google.com/` instead of `http://google.com`).\n\nFirst, remove tab (0x09), CR (0x0d), and LF (0x0a) characters from the URL. Do not remove escape sequences for these characters (e.g. `%0a`).\n\nSecond, if the URL ends in a fragment, remove the fragment. For example, shorten `http://google.com/#frag` to `http://google.com/`.\n\nThird, repeatedly percent-unescape the URL until it has no more percent-escapes. (This may render the URL invalid.)\n\n**To canonicalize the hostname:**\n\nExtract the hostname from the URL and then:\n\n1. Remove all leading and trailing dots.\n2. Replace consecutive dots with a single dot.\n3. If the hostname can be parsed as an IPv4 address, normalize it to 4 dot-separated decimal values. The client should handle any legal IP-address encoding, including octal, hex, and fewer than four components.\n4. If the hostname can be parsed as a bracketed IPv6 address, normalize it by removing unnecessary leading zeroes in the components and collapsing zero components by using the double-colon syntax. For example `[2001:0db8:0000::1]` should be transformed into `[2001:db8::1]`. If the hostname is one of the two following special IPv6 address types, transform them into IPv4:\n - An IPv4-mapped IPv6 address, such as `[::ffff:1.2.3.4]`, which should be transformed into `1.2.3.4`;\n - A NAT64 address using [the well-known prefix 64:ff9b::/96](https://datatracker.ietf.org/doc/html/rfc6052#section-2.1), such as `[64:ff9b::1.2.3.4]`, which should be transformed into `1.2.3.4`.\n5. Lowercase the whole string.\n\n**To canonicalize the path:**\n\n1. Resolve the sequences `/../` and `/./` in the path by replacing `/./` with `/`, and removing `/../` along with the preceding path component.\n2. Replace runs of consecutive slashes with a single slash character.\n\nDo not apply these path canonicalizations to the query parameters.\n\nIn the URL, percent-escape all characters that are \\\u003c= ASCII 32, \\\u003e= 127, `#`, or `%`. The escapes should use uppercase hex characters.\n\n### Host-Suffix Path-Prefix Expressions\n\nOnce the URL is canonicalized, the next step is to create the suffix/prefix expressions. Each suffix/prefix expression consists of a host suffix (or full host) and a path prefix (or full path).\n\nThe client will form up to 30 different possible host suffix and path prefix combinations. These combinations use only the host and path components of the URL. The scheme, username, password, and port are discarded. If the URL includes query parameters, then at least one combination will include the full path and query parameters.\n\n**For the host**, the client will try at most five different strings. They are:\n\n- If the hostname is not an IPv4 or IPv6 literal, up to four hostnames formed by starting with the eTLD+1 domain and adding successive leading components. The determination of eTLD+1 should be based on the [Public Suffix List](https://publicsuffix.org/). For example, `a.b.example.com` would result in the eTLD+1 domain of `example.com` as well as the host with one additional host component `b.example.com`.\n- The exact hostname in the URL. Following the previous example, `a.b.example.com` would be checked.\n\n**For the path**, the client will try at most six different strings. They are:\n\n- The exact path of the URL, including query parameters.\n- The exact path of the URL, without query parameters.\n- The four paths formed by starting at the root (/) and successively appending path components, including a trailing slash.\n\nThe following examples illustrate the check behavior:\n\nFor the URL `http://a.b.com/1/2.html?param=1`, the client will try these possible strings: \n\n a.b.com/1/2.html?param=1\n a.b.com/1/2.html\n a.b.com/\n a.b.com/1/\n b.com/1/2.html?param=1\n b.com/1/2.html\n b.com/\n b.com/1/\n\nFor the URL `http://a.b.c.d.e.f.com/1.html`, the client will try these possible strings: \n\n a.b.c.d.e.f.com/1.html\n a.b.c.d.e.f.com/\n c.d.e.f.com/1.html\n c.d.e.f.com/\n d.e.f.com/1.html\n d.e.f.com/\n e.f.com/1.html\n e.f.com/\n f.com/1.html\n f.com/\n\n(Note: skip `b.c.d.e.f.com`, since we'll take only the last five hostname components, and the full hostname.)\n\nFor the URL `http://1.2.3.4/1/`, the client will try these possible strings: \n\n 1.2.3.4/1/\n 1.2.3.4/\n\nFor the URL `http://example.co.uk/1`, the client will try these possible strings: \n\n example.co.uk/1\n example.co.uk/\n\n### Hashing\n\nGoogle Safe Browsing exclusively uses SHA256 as the hash function. This hash function should be applied to the above expressions.\n\nThe full 32-byte hash will, depending on the circumstances, be truncated to 4 bytes, 8 bytes, or 16 bytes:\n\n- When using the [hashes.search method](/safe-browsing/reference/rest/v5/hashes/search), we currently require the hashes in the request to be truncated to exactly 4 bytes. Sending additional bytes in this request will compromise user privacy.\n\n- When downloading the lists for the local database using the [hashList.get method](/safe-browsing/reference/rest/v5/hashList/get) or the [hashLists.batchGet method](/safe-browsing/reference/rest/v5/hashLists/batchGet), the length of the hashes sent by the server is encoded within the naming convention of the lists that contain suffix indicating hash length. See [Available Lists](/safe-browsing/reference/Local.Database#available-lists) section for more details."]]
