URLs and Hashing
קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
בקטע הזה מפורטות המפרטות של האופן שבו לקוחות בודקים כתובות URL.
יצירת גרסה קנונית של כתובות URL
לפני שבודקים כתובות URL, הלקוח אמור לבצע קנוניזציה מסוימת של כתובת ה-URL הזו.
כדי להתחיל, נניח שהלקוח ניתח את כתובת ה-URL ועשה אותה תקינה בהתאם ל-RFC 2396. אם בכתובת ה-URL נעשה שימוש בשם דומיין בינלאומי (IDN), הלקוח צריך להמיר את כתובת ה-URL לייצוג ASCII Punycode. כתובת ה-URL חייבת לכלול רכיב נתיב. כלומר, חייב להיות בה לפחות קו נטוי אחד אחרי הדומיין (http://google.com/ במקום http://google.com).
קודם מסירים מתווית ה-URL את התווים Tab (0x09), CR (0x0d) ו-LF (0x0a). אין להסיר את רצפי הבריחה של התווים האלה (למשל %0a).
שנית, אם כתובת ה-URL מסתיימת בחלק, צריך להסיר את החלק. לדוגמה, לקצר את השם http://google.com/#frag ל-http://google.com/.
שלישית, מסירים את תווי ה-escape של האחוזים בכתובת ה-URL שוב ושוב עד שלא יהיו יותר תווי escape של אחוזים. (הדבר עלול לגרום לכך שכתובת ה-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, צריך להשתמש בבריחה (escape) של אחוזים לכל התווים שהם <= ASCII 32, >= 127, # או %. צריך להשתמש בתווים בינונייים (escape) של 16 ביט באותיות גדולות.
ביטויים של קידומת נתיב עם סיומת של מארח
אחרי שמבצעים קנוניזציה של כתובת ה-URL, השלב הבא הוא ליצור את הביטויים של הסיומת או התחילית. כל ביטוי של סיומת/תחילית מורכב מסיום של מארח (או מארח מלא) ומתחילית של נתיב (או נתיב מלא).
הלקוח ייצור עד 30 שילובים שונים של סיומת מארח וקידומת נתיב. השילובים האלה כוללים רק את רכיבי המארח והנתיב של כתובת ה-URL. המערכת תתעלם מהסכמה, שם המשתמש, הסיסמה והיציאה. אם כתובת ה-URL כוללת פרמטרים של שאילתה, לפחות שילוב אחד יכלול את הנתיב המלא ואת פרמטרים של השאילתה.
במארחים, הלקוח ינסה עד חמש מחרוזות שונות. סוגי המשנה הם:
- אם שם המארח הוא לא IPv4 או IPv6 מילולי, עד ארבעה שמות מארחים שנוצרים על ידי התחלה בדומיין eTLD+1 והוספת רכיבים מובילים עוקבים. הקביעה של eTLD+1 צריכה להתבסס על רשימת הסיומות הציבוריות. לדוגמה,
a.b.example.com יניב את הדומיין eTLD+1 של example.com, וגם את המארח עם רכיב מארח נוסף אחד, b.example.com.
- שם המארח המדויק בכתובת ה-URL. בהתאם לדוגמה הקודמת, הערך
a.b.example.com ייבדק.
בנתיב, הלקוח ינסה עד שש מחרוזות שונות. סוגי המשנה הם:
- הנתיב המדויק של כתובת ה-URL, כולל פרמטרים של שאילתה.
- הנתיב המדויק של כתובת ה-URL, ללא פרמטרים של שאילתה.
- ארבעת הנתיבים שנוצרים על ידי התחלה ברמה הבסיסית (/) והוספה של רכיבי נתיב ברצף, כולל קו נטוי בסוף.
הדוגמאות הבאות ממחישות את התנהגות הבדיקה:
עבור כתובת ה-URL http://a.b.com/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://a.b.c.d.e.f.com/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/
(הערה: מדלגים על b.c.d.e.f.com, כי נשתמש רק בחמישה הרכיבים האחרונים של שם המארח ובשם המארח המלא).
עבור כתובת ה-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/
גיבוב (hashing)
פונקציית הגיבוב (hash) של הגלישה הבטוחה של Google היא SHA256 בלבד. צריך להחיל את פונקציית הגיבוב הזו על הביטויים שלמעלה.
גיבוב המלא באורך 32 בייטים יקוצר ל-4 בייטים, ל-8 בייטים או ל-16 בייטים, בהתאם לנסיבות:
כשמשתמשים בשיטת hashes.search, אנחנו דורשים כרגע שהגיבוב בבקשה יהיה קטוץ ל-4 בייטים בדיוק. שליחת בייטים נוספים בבקשה הזו עלולה לפגוע בפרטיות המשתמשים.
כשמורידים את הרשימות למסד הנתונים המקומי באמצעות השיטה hashList.get או השיטה hashLists.batchGet, אורך הגיבוב שנשלח מהשרת מקודד במוסכמה למתן שמות לרשימות שמכילות סיומת שמציינת את אורך הגיבוב. פרטים נוספים זמינים בקטע רשימות זמינות.
אלא אם צוין אחרת, התוכן של דף זה הוא ברישיון Creative Commons Attribution 4.0 ודוגמאות הקוד הן ברישיון Apache 2.0. לפרטים, ניתן לעיין במדיניות האתר Google Developers. Java הוא סימן מסחרי רשום של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2025-07-25 (שעון UTC).
[null,null,["עדכון אחרון: 2025-07-25 (שעון UTC)."],[],[],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."]]
