URLs and Hashing
Оптимизируйте свои подборки
Сохраняйте и классифицируйте контент в соответствии со своими настройками.
В этом разделе содержатся подробные сведения о том, как клиенты проверяют URL-адреса.
Канонизация URL-адресов
Прежде чем какие-либо URL-адреса будут проверены, ожидается, что клиент выполнит некоторую канонизацию этого URL-адреса.
Для начала мы предполагаем, что клиент проанализировал URL-адрес и сделал его действительным в соответствии с RFC 2396. Если URL-адрес использует интернационализированное доменное имя (IDN), клиент должен преобразовать URL-адрес в представление Punycode ASCII. URL-адрес должен включать компонент пути; то есть после домена должна быть хотя бы одна косая черта ( http://google.com/ вместо http://google.com ).
Сначала удалите символы табуляции (0x09), CR (0x0d) и LF (0x0a) из URL-адреса. Не удаляйте escape-последовательности для этих символов (например, %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 Safe Browsing использует исключительно SHA256 в качестве хэш-функции. Эту хеш-функцию следует применить к приведенным выше выражениям.
Полный 32-байтовый хеш будет, в зависимости от обстоятельств, сокращен до 4, 8 или 16 байт:
При использовании метода hashes.search мы в настоящее время требуем, чтобы хеши в запросе были усечены ровно до 4 байтов. Отправка дополнительных байтов в этом запросе поставит под угрозу конфиденциальность пользователя.
При загрузке списков для локальной базы данных с помощью метода hashList.get или метода hashLists.batchGet длина хешей, отправляемых сервером, кодируется в рамках соглашения об именах списков, содержащих суффикс, указывающий длину хеша. Дополнительную информацию см. в разделе «Доступные списки» .
Если не указано иное, контент на этой странице предоставляется по лицензии Creative Commons "С указанием авторства 4.0", а примеры кода – по лицензии Apache 2.0. Подробнее об этом написано в правилах сайта. Java – это зарегистрированный товарный знак корпорации Oracle и ее аффилированных лиц.
Последнее обновление: 2025-07-24 UTC.
[null,null,["Последнее обновление: 2025-07-24 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."]]
