URLs and Hashing
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
이 섹션에는 클라이언트가 URL을 확인하는 방법에 관한 자세한 사양이 포함되어 있습니다.
URL 표준화
URL이 확인되기 전에 클라이언트는 해당 URL에 대해 일부 표준화를 실행해야 합니다.
먼저 클라이언트가 파싱한 URL이 RFC 2396에 따라 유효하다고 가정합니다. URL에서 국제화된 도메인 이름 (IDN)을 사용하는 경우 클라이언트는 URL을 ASCII 퓨니코드 표현으로 변환해야 합니다. URL에는 경로 구성요소가 포함되어야 합니다. 즉, 도메인 뒤에 슬래시 (http://google.com 대신 http://google.com/)가 하나 이상 있어야 합니다.
먼저 URL에서 탭 (0x09), CR (0x0d), LF (0x0a) 문자를 삭제합니다. 이러한 문자 (예: %0a)의 이스케이프 시퀀스는 삭제하지 마세요.
둘째, URL이 프래그먼트로 끝나면 프래그먼트를 제거합니다. 예를 들어 http://google.com/#frag를 http://google.com/로 줄입니다.
세 번째로, URL에서 더 이상 퍼센트 이스케이프 문자가 남지 않을 때까지 퍼센트 이스케이프 문자를 반복적으로 삭제합니다. 이렇게 하면 URL이 잘못될 수 있습니다.
호스트 이름을 표준화하려면 다음 안내를 따르세요.
URL에서 호스트 이름을 추출한 후 다음을 수행합니다.
- 모든 선행 및 후행 점은 삭제합니다.
- 연속된 점을 단일 점으로 바꿉니다.
- 호스트 이름을 IPv4 주소로 파싱할 수 있는 경우 4개의 점으로 구분된 십진수 값으로 정규화합니다. 클라이언트는 8진수, 16진수, 4개 미만의 구성 요소를 포함한 모든 법적 IP 주소 인코딩을 처리해야 합니다.
- 호스트 이름을 대괄호로 묶인 IPv6 주소로 파싱할 수 있는 경우 구성요소에서 불필요한 선행 0을 삭제하고 이중 콜론 구문을 사용하여 0 구성요소를 접어서 정규화합니다. 예를 들어
[2001:0db8:0000::1]은 [2001:db8::1]로 변환되어야 합니다. 호스트 이름이 다음 두 가지 특수 IPv6 주소 유형 중 하나인 경우 IPv4로 변환합니다.
[::ffff:1.2.3.4]와 같이 1.2.3.4로 변환해야 하는 IPv4 매핑 IPv6 주소[64:ff9b::1.2.3.4]와 같이 잘 알려진 접두사 64:ff9b::/96을 사용하는 NAT64 주소로, 1.2.3.4로 변환해야 합니다.
- 전체 문자열을 소문자로 표기합니다.
경로를 표준화하려면 다음 안내를 따르세요.
/./를 /로 바꾸고 이전 경로 구성요소와 함께 /../를 삭제하여 경로의 /../ 및 /./ 시퀀스를 확인합니다.- 연속된 슬래시 실행을 단일 슬래시 문자로 바꿉니다.
이러한 경로 표준화를 쿼리 매개변수에 적용하지 마세요.
URL에서 <= ASCII 32, >= 127, # 또는 %인 모든 문자를 퍼센트 문자로 이스케이프 처리합니다. 이스케이프는 대문자 16진수를 사용해야합니다.
호스트-서픽스 경로-프리픽스 표현식
URL이 표준화되면 다음 단계는 서픽스/프리픽스 표현식을 만드는 것입니다. 각 서픽스/프리픽스 표현식은 호스트 서픽스 (또는 전체 호스트)와 경로 프리픽스 (또는 전체 경로)로 구성됩니다.
클라이언트는 최대 30개의 서로 다른 호스트 서픽스와 경로 프리픽스 조합을 구성합니다. 이러한 조합은 URL의 호스트 및 경로 구성요소만 사용합니다. 스키마, 사용자 이름, 비밀번호, 포트는 삭제됩니다. URL에 쿼리 매개변수가 포함된 경우에는 하나 이상의 조합에 전체 경로 및 쿼리 매개변수가 포함됩니다.
호스트의 경우 클라이언트는 최대 5개의 다른 문자열을 시도합니다. 각 필터는 다음과 같습니다.
- 호스트 이름이 IPv4 또는 IPv6 리터럴이 아닌 경우 eTLD+1 도메인으로 시작하고 앞의 구성요소를 연속적으로 추가하여 최대 4개의 호스트 이름을 만듭니다. eTLD+1은 공개 접미사 목록을 기반으로 결정해야 합니다. 예를 들어
a.b.example.com는 example.com의 eTLD+1 도메인과 호스트 구성요소 b.example.com가 하나 추가된 호스트를 생성합니다.
- 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/
(참고: 마지막 5개 호스트 이름 구성요소와 전체 호스트 이름만 가져오므로 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/
해싱
Google 세이프 브라우징은 SHA256을 해시 함수로만 사용합니다. 이 해시 함수는 위의 표현식에 적용해야 합니다.
전체 32바이트 해시는 상황에 따라 4바이트, 8바이트 또는 16바이트로 자릅니다.
달리 명시되지 않는 한 이 페이지의 콘텐츠에는 Creative Commons Attribution 4.0 라이선스에 따라 라이선스가 부여되며, 코드 샘플에는 Apache 2.0 라이선스에 따라 라이선스가 부여됩니다. 자세한 내용은 Google Developers 사이트 정책을 참조하세요. 자바는 Oracle 및/또는 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."]]
