URLs and Hashing
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Ta sekcja zawiera szczegółowe specyfikacje sposobu sprawdzania adresów URL przez klientów.
Wybór strony kanonicznej
Przed sprawdzeniem adresów URL klient musi przeprowadzić ich kanonizację.
Na początek zakładamy, że klient przeanalizował adres URL i uznał go za prawidłowy zgodnie ze standardem RFC 2396. Jeśli adres URL zawiera międzynarodową nazwę domeny (IDN), klient powinien przekonwertować adres URL do postaci Punycode ASCII. Adres URL musi zawierać element ścieżki, czyli musi mieć co najmniej 1 ukośnik po domenie (http://google.com/ zamiast http://google.com).
Najpierw usuń z adresu URL znaki tabulacji (0x09), CR (0x0d) i LF (0x0a). Nie usuwaj sekwencji znaków ucieczki (np. %0a).
Po drugie, jeśli adres URL kończy się fragmentem, usuń go. Na przykład skrócenie http://google.com/#frag do http://google.com/.
Po trzecie, powtarzaj odkodowywanie adresu URL, aż nie będzie już więcej znaków ucieczki. (może to spowodować, że adres URL stanie się nieprawidłowy).
Aby zmienić nazwę hosta na postać kanoniczną:
Wyodrębnij nazwę hosta z adresu URL, a potem:
- Usuń wszystkie kropki na początku i na końcu.
- Zastąp kolejne kropki jedną kropką.
- Jeśli nazwę hosta można przeanalizować jako adres IPv4, znormalizuj ją do 4 wartości dziesiętnych oddzielonych kropkami. Klient powinien obsługiwać dowolne legalne kodowanie adresów IP, w tym oktetowe, szesnastkowe i mniej niż 4 komponentów.
- Jeśli nazwę hosta można przeanalizować jako adres IPv6 w nawiasach, znormalizuj ją, usuwając zbędne zera na początku komponentów i upraszczając komponenty równe 0 za pomocą podwójnego dwukropka. Na przykład
[2001:0db8:0000::1] należy przekształcić w [2001:db8::1]. Jeśli nazwa hosta jest jednym z tych 2 specjalnych typów adresów IPv6, przekształc ją w adres IPv4:
- adres IPv6 mapowany na IPv4, np.
[::ffff:1.2.3.4], który powinien zostać przekształcony w 1.2.3.4;
- Adres NAT64 korzystający z znanego prefiksu 64:ff9b::/96, np.
[64:ff9b::1.2.3.4], który powinien zostać przekształcony w 1.2.3.4.
- Użyj małych liter w całym ciągu znaków.
Aby utworzyć ścieżkę kanoniczną:
- Rozwiń sekwencje
/../ i /./ w ścieżce, zastępując /./ przez / i usuń /../ wraz z poprzednim elementem ścieżki.
- Zastąp ciągi kolejnych ukośników pojedynczym znakiem ukośnika.
Nie stosuj kanonizacji ścieżek do parametrów zapytania.
W adresie URL zastosuj kody procentowe dla wszystkich znaków, które są ≤ ASCII 32, ≥ 127, # lub %. W przypadku znaków ucieczki należy używać wielkich liter.
Wyrażenia prefiksu ścieżki i sufiksu hosta
Po kanonizacji adresu URL kolejnym krokiem jest utworzenie wyrażeń prefiksu i sufiksa. Każde wyrażenie sufiksu/prefiksu składa się z sufiksa hosta (lub pełnego hosta) i prefiksu ścieżki (lub pełnej ścieżki).
Klient utworzy do 30 różnych możliwych kombinacji sufiksów hosta i prefiksów ścieżki. Te kombinacje używają tylko elementów hosta i ścieżki adresu URL. Schemat, nazwa użytkownika, hasło i port są ignorowane. Jeśli adres URL zawiera parametry zapytania, co najmniej 1 kombinacja będzie zawierać pełną ścieżkę i parametry zapytania.
W przypadku hosta klient spróbuje użyć maksymalnie 5 różnych ciągów znaków. Są to:
- Jeśli nazwa hosta nie jest dosłowną nazwą IPv4 ani IPv6, maksymalnie 4 nazwy hosta utworzone przez dodanie kolejnych komponentów domeny eTLD+1. Określanie domeny eTLD+1 powinno być oparte na liście domen publicznych. Na przykład
a.b.example.com spowoduje utworzenie domeny eTLD+1 example.com oraz hosta z jednym dodatkowym komponentem hosta b.example.com.
- Dokładna nazwa hosta w adresie URL. W przypadku poprzedniego przykładu sprawdzana będzie wartość
a.b.example.com.
W przypadku ścieżki klient spróbuje maksymalnie 6 różnych ciągów znaków. Są to:
- Dokładna ścieżka adresu URL, w tym parametry zapytania.
- Dokładna ścieżka adresu URL bez parametrów zapytania.
- Cztery ścieżki utworzone przez rozpoczęcie od ścieżki katalogu głównego (/) i kolejno dołączanie elementów ścieżki, w tym ukośnika końcowego.
Zachowanie sprawdzania ilustrują te przykłady:
W przypadku adresu URL http://a.b.com/1/2.html?param=1 klient spróbuje użyć tych ciągów znaków:
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/
W przypadku adresu URL http://a.b.c.d.e.f.com/1.html klient spróbuje użyć tych ciągów znaków:
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/
(Uwaga: pomiń b.c.d.e.f.com, ponieważ weźmiemy tylko 5 ostatnich elementów nazwy hosta i pełną nazwę hosta).
W przypadku adresu URL http://1.2.3.4/1/ klient spróbuje użyć tych ciągów znaków:
1.2.3.4/1/
1.2.3.4/
W przypadku adresu URL http://example.co.uk/1 klient spróbuje użyć tych ciągów znaków:
example.co.uk/1
example.co.uk/
Haszowanie
Bezpieczne przeglądanie Google używa wyłącznie funkcji szyfrowania SHA256. Funkcja szyfrowania powinna być zastosowana do powyższych wyrażeń.
W zależności od okoliczności pełny 32-bajtowy skrót zostanie obcięty do 4, 8 lub 16 bajtów:
Gdy używasz metody hashes.search, wymagamy, aby hasze w żądaniu były obcinane do dokładnie 4 bajtów. Wysyłanie dodatkowych bajtów w tym żądaniu spowoduje naruszenie prywatności użytkownika.
Podczas pobierania list do bazy danych lokalnej za pomocą metody hashList.get lub metody hashLists.batchGet długość haszy wysyłanych przez serwer jest zakodowana w konwencji nazewnictwa list, które zawierają sufiks wskazujący długość hasza. Więcej informacji znajdziesz w sekcji Dostępne listy.
O ile nie stwierdzono inaczej, treść tej strony jest objęta licencją Creative Commons – uznanie autorstwa 4.0, a fragmenty kodu są dostępne na licencji Apache 2.0. Szczegółowe informacje na ten temat zawierają zasady dotyczące witryny Google Developers. Java jest zastrzeżonym znakiem towarowym firmy Oracle i jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2025-07-25 UTC.
[null,null,["Ostatnia aktualizacja: 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."]]
