URLs and Hashing
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
このセクションでは、クライアントが URL を確認する方法の詳細な仕様について説明します。
URL の正規化
URL がチェックされる前に、クライアントがその URL に対して正規化を行うことが期待されます。
まず、クライアントが URL を解析し、RFC 2396 に従って有効にしていることを前提としています。URL で国際化ドメイン名（IDN）を使用している場合、クライアントは URL を ASCII Punycode 表記に変換する必要があります。URL にはパス コンポーネントを含める必要があります。つまり、ドメインの後にスラッシュを 1 つ以上含める必要があります（http://google.com ではなく http://google.com/）。
まず、URL からタブ（0x09）、CR（0x0d）、LF（0x0a）を削除します。これらの文字のエスケープ シーケンス（%0a など）は削除しないでください。
2 つ目は、URL の末尾がフラグメントになっている場合は、フラグメントを削除します。たとえば、http://google.com/#frag を http://google.com/ に短縮します。
3 つ目に、パーセント エスケープがなくなるまで繰り返して、URL からパーセント エスケープを削除します。（これにより、URL が無効になる可能性があります）。
ホスト名を正規化するには:
URL からホスト名を抽出し、次の操作を行います。
- 先頭と末尾のドットをすべて削除する。
- 連続するドットを 1 つのドットに置き換える。
- ホスト名を IPv4 アドレスとして解析できる場合は、4 つのドット区切りの 10 進数値に正規化する。クライアントは、8 進数、16 進数、4 つ未満のコンポーネントなど、有効な IP アドレス エンコードを処理する必要があります。
- ホスト名を角かっこ付きの IPv6 アドレスとして解析できる場合は、コンポーネントの先頭の不要なゼロを削除し、二重コロン構文を使用してゼロ コンポーネントを圧縮して正規化します。たとえば、
[2001:0db8:0000::1] は [2001:db8::1] に変換する必要があります。ホスト名が次の 2 つの特別な IPv6 アドレスタイプのいずれかである場合は、IPv4 に変換します。
- IPv4 にマッピングされた IPv6 アドレス（
[::ffff:1.2.3.4] など）。1.2.3.4 に変換する必要があります。
- well-known プレフィックス 64:ff9b::/96 を使用する NAT64 アドレス（
[64:ff9b::1.2.3.4] など）。1.2.3.4 に変換する必要があります。
- 文字列全体を小文字にする。
パスを正規化するには:
- パス内のシーケンス
/../ と /./ を解決するには、/./ を / に置き換え、/../ を前のパス コンポーネントとともに削除します。
- 連続するスラッシュの実行は単一のスラッシュ文字に置き換えます。
これらのパスの正規化をクエリ パラメータに適用しないでください。
URL 内で、ASCII 32 以下、127 以上、#、% のすべての文字をパーセント エスケープします。エスケープには大文字の 16 進数を使用する必要があります。
ホスト サフィックス パス プレフィックス式
URL が正規化されたら、次のステップはサフィックス/プレフィックス式の作成です。各サフィックス/プレフィックス式は、ホスト サフィックス（または完全なホスト）とパス プレフィックス（または完全なパス）で構成されます。
クライアントは、最大で 30 個の異なるホスト サフィックスとパス プレフィックスの組み合わせを形成します。これらの組み合わせでは、URL のホストとパス コンポーネントのみが使用されます。スキーム、ユーザー名、パスワード、ポートは破棄されます。URL にクエリ パラメータが含まれている場合、少なくとも 1 つの組み合わせに完全なパスとクエリ パラメータが含まれます。
ホストの場合、クライアントは最大で 5 つの異なる文字列を試行します。それらは次のとおりです。
- ホスト名が IPv4 または IPv6 リテラルでない場合は、eTLD+1 ドメインから始めて、先頭のコンポーネントを順番に追加して、最大 4 つのホスト名を作成できます。eTLD+1 の決定は、Public Suffix List に基づいて行う必要があります。たとえば、
a.b.example.com では、eTLD+1 ドメインが example.com になり、ホスト コンポーネントが b.example.com 1 つ追加されます。
- URL の正確なホスト名。前の例では、
a.b.example.com がチェックされます。
パスの場合、クライアントは最大で 6 つの異なる文字列を試行します。それらは次のとおりです。
- クエリ パラメータを含む URL の正確なパス。
- クエリ パラメータなしの URL の正確なパス。
- ルート（/）から始まり、末尾のスラッシュを含むパス コンポーネントを連続して追加することによって形成される 4 つのパス。
次の例では、チェックの動作を示します。
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 はスキップします。ホスト名の最後の 5 つのコンポーネントと完全なホスト名のみを取得するためです）。
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 バイトに切り捨てられます。
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 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."]]
