URLs and Hashing
Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Phần này chứa thông số kỹ thuật chi tiết về cách ứng dụng kiểm tra URL.
Chuẩn hoá URL
Trước khi kiểm tra bất kỳ URL nào, ứng dụng dự kiến sẽ thực hiện một số hoạt động chuẩn hoá trên URL đó.
Để bắt đầu, chúng ta giả định rằng ứng dụng đã phân tích cú pháp URL và làm cho URL đó hợp lệ theo RFC 2396. Nếu URL sử dụng tên miền quốc tế hoá (IDN), thì ứng dụng phải chuyển đổi URL thành dạng trình bày ASCII Punycode. URL phải bao gồm một thành phần đường dẫn; tức là URL phải có ít nhất một dấu gạch chéo theo sau miền (http://google.com/ thay vì http://google.com).
Trước tiên, hãy xoá các ký tự tab (0x09), CR (0x0d) và LF (0x0a) khỏi URL. Không xoá các chuỗi thoát cho các ký tự này (ví dụ: %0a).
Thứ hai, nếu URL kết thúc bằng một mảnh, hãy xoá mảnh đó. Ví dụ: rút gọn http://google.com/#frag thành http://google.com/.
Thứ ba, liên tục thoát ký tự phần trăm khỏi URL cho đến khi không còn ký tự thoát phần trăm nào nữa. (Việc này có thể khiến URL không hợp lệ.)
Cách chuẩn hoá tên máy chủ:
Trích xuất tên máy chủ từ URL, sau đó:
- Xoá tất cả dấu chấm ở đầu và cuối.
- Thay thế các dấu chấm liên tiếp bằng một dấu chấm.
- Nếu có thể phân tích cú pháp tên máy chủ dưới dạng địa chỉ IPv4, hãy chuẩn hoá tên máy chủ thành 4 giá trị thập phân được phân tách bằng dấu chấm. Ứng dụng phải xử lý mọi phương thức mã hoá địa chỉ IP hợp pháp, bao gồm cả bát phân, thập lục phân và ít hơn 4 thành phần.
- Nếu tên máy chủ có thể được phân tích cú pháp dưới dạng địa chỉ IPv6 trong dấu ngoặc đơn, hãy chuẩn hoá tên máy chủ đó bằng cách xoá các số 0 ở đầu không cần thiết trong các thành phần và thu gọn các thành phần bằng số 0 bằng cách sử dụng cú pháp dấu hai chấm. Ví dụ:
[2001:0db8:0000::1] phải được chuyển đổi thành [2001:db8::1]. Nếu tên máy chủ là một trong hai loại địa chỉ IPv6 đặc biệt sau, hãy chuyển đổi các địa chỉ đó thành IPv4:
- Địa chỉ IPv6 được liên kết với IPv4, chẳng hạn như
[::ffff:1.2.3.4], sẽ được chuyển đổi thành 1.2.3.4;
- Địa chỉ NAT64 sử dụng tiền tố 64:ff9b::/96 đã biết, chẳng hạn như
[64:ff9b::1.2.3.4], sẽ được chuyển đổi thành 1.2.3.4.
- Đặt toàn bộ chuỗi ở dạng chữ thường.
Cách chuẩn hoá đường dẫn:
- Giải quyết các trình tự
/../ và /./ trong đường dẫn bằng cách thay thế /./ bằng / và xoá /../ cùng với thành phần đường dẫn trước đó.
- Thay thế các chuỗi dấu gạch chéo liên tiếp bằng một ký tự dấu gạch chéo.
Không áp dụng các quy tắc chuẩn hoá đường dẫn này cho các thông số truy vấn.
Trong URL, hãy thoát bằng ký tự phần trăm tất cả ký tự <= ASCII 32, >= 127, # hoặc %. Các ký tự thoát phải sử dụng ký tự hex viết hoa.
Biểu thức tiền tố đường dẫn hậu tố máy chủ
Sau khi URL được chuẩn hoá, bước tiếp theo là tạo biểu thức hậu tố/tiền tố. Mỗi biểu thức hậu tố/tiền tố bao gồm một hậu tố máy chủ (hoặc máy chủ đầy đủ) và một tiền tố đường dẫn (hoặc đường dẫn đầy đủ).
Ứng dụng khách sẽ tạo ra tối đa 30 tổ hợp hậu tố máy chủ lưu trữ và tiền tố đường dẫn có thể có. Các tổ hợp này chỉ sử dụng thành phần máy chủ lưu trữ và đường dẫn của URL. Lược đồ, tên người dùng, mật khẩu và cổng sẽ bị loại bỏ. Nếu URL có chứa tham số truy vấn, thì ít nhất một tổ hợp sẽ bao gồm đường dẫn đầy đủ và tham số truy vấn.
Đối với máy chủ, ứng dụng sẽ thử tối đa 5 chuỗi khác nhau. Các loại chiến dịch phụ đó là:
- Nếu tên máy chủ không phải là giá trị cố định IPv4 hoặc IPv6, thì tối đa 4 tên máy chủ được tạo bằng cách bắt đầu bằng miền eTLD+1 và thêm các thành phần dẫn đầu liên tiếp. Việc xác định eTLD+1 phải dựa trên Danh sách hậu tố công khai. Ví dụ:
a.b.example.com sẽ dẫn đến miền eTLD+1 của example.com cũng như máy chủ lưu trữ có thêm một thành phần máy chủ lưu trữ b.example.com.
- Tên máy chủ chính xác trong URL. Tiếp nối ví dụ trước,
a.b.example.com sẽ được kiểm tra.
Đối với đường dẫn, ứng dụng sẽ thử tối đa 6 chuỗi khác nhau. Các loại chiến dịch phụ đó là:
- Đường dẫn chính xác của URL, bao gồm cả tham số truy vấn.
- Đường dẫn chính xác của URL, không có tham số truy vấn.
- Bốn đường dẫn được tạo bằng cách bắt đầu từ thư mục gốc (/) và nối tiếp các thành phần đường dẫn, bao gồm cả dấu gạch chéo ở cuối.
Các ví dụ sau đây minh hoạ hành vi kiểm tra:
Đối với URL http://a.b.com/1/2.html?param=1, ứng dụng sẽ thử các chuỗi có thể có sau:
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/
Đối với URL http://a.b.c.d.e.f.com/1.html, ứng dụng sẽ thử các chuỗi có thể có sau:
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/
(Lưu ý: bỏ qua b.c.d.e.f.com vì chúng ta sẽ chỉ lấy 5 thành phần tên máy chủ cuối cùng và tên máy chủ đầy đủ.)
Đối với URL http://1.2.3.4/1/, ứng dụng sẽ thử các chuỗi có thể có sau:
1.2.3.4/1/
1.2.3.4/
Đối với URL http://example.co.uk/1, ứng dụng sẽ thử các chuỗi có thể có sau:
example.co.uk/1
example.co.uk/
Băm
Tính năng Duyệt web an toàn của Google chỉ sử dụng SHA256 làm hàm băm. Bạn nên áp dụng hàm băm này cho các biểu thức ở trên.
Tuỳ thuộc vào trường hợp, hàm băm đầy đủ 32 byte sẽ bị cắt bớt thành 4 byte, 8 byte hoặc 16 byte:
Khi sử dụng phương thức hashes.search, chúng tôi hiện yêu cầu các hàm băm trong yêu cầu phải được cắt bớt chính xác còn 4 byte. Việc gửi thêm byte trong yêu cầu này sẽ làm tổn hại đến quyền riêng tư của người dùng.
Khi tải danh sách xuống cho cơ sở dữ liệu cục bộ bằng phương thức hashList.get hoặc phương thức hashLists.batchGet, độ dài của hàm băm do máy chủ gửi được mã hoá theo quy ước đặt tên của các danh sách chứa hậu tố cho biết độ dài hàm băm. Hãy xem phần Danh sách có sẵn để biết thêm chi tiết.
Trừ phi có lưu ý khác, nội dung của trang này được cấp phép theo Giấy phép ghi nhận tác giả 4.0 của Creative Commons và các mẫu mã lập trình được cấp phép theo Giấy phép Apache 2.0. Để biết thông tin chi tiết, vui lòng tham khảo Chính sách trang web của Google Developers. Java là nhãn hiệu đã đăng ký của Oracle và/hoặc các đơn vị liên kết với Oracle.
Cập nhật lần gần đây nhất: 2025-07-25 UTC.
[null,null,["Cập nhật lần gần đây nhất: 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."]]
